Le dipendenze sono come i componenti di una vecchia macchina CNC che hai recuperato in un garage: finché tutto gira fluido, ti senti un dio, ma basta un bullone difettoso per far saltare in aria l’intero setup.
Se siete tra quelli che non si fanno problemi a installare pacchetti npm sperando nel miracolo, oggi c’è un motivo serio per controllare i log. Recentemente, l’ecosistema TanStack è stato colpito da un attacco alla supply chain che farebbe invidia a un hacker di serie B. Non parliamo della solita password debole o di un pacchetto con un nome simile a un altro; qui siamo di fronte a un exploit multi-livello che ha sfruttato la fiducia cieca in GitHub Actions e la cache dei workflow per iniettando codice malevolo in ben 84 versioni di 42 pacchetti diversi.
Il ‘pwn’ è avvenuto in modo quasi chirurgico. L’attaccante ha usato un pattern chiamato ‘Pwn Request’ tramite `pull_request_target`. In pratica, hanno creato un fork, hanno sporcato la cache di GitHub Actions e hanno aspettato che un merge legittimo attivasse il workflow. Quando il workflow è partito, ha eseguito il codice malevolo che era già nascosto nella cache. Il risultato? Una script di circa 2.3 MB, tutto offuscato, che girava durante l’installazione e faceva il lavoro sporco: rubare token AWS, chiavi SSH, credenziali GitHub e persino token di Kubernetes, per poi spararli fuori tramite una rete di messaggistica criptata.
Da smanettone, la cosa che mi fa salire il nervoso non è solo l’attacco in sé, ma quanto sia elegante e distruttiva la logica. Non hanno rubato le chiavi di npm direttamente; hanno usato i permessi OIDC (quelli che servono per far comunicare GitHub con il cloud senza password) per pubblicare i pacchetti infetti. È un attacco che colpisce proprio dove ci sentiamo più sicuri: l’automazione del CI/CD.
Cosa significa per noi che viviamo tra codice, circuiti e automazione? Che la fiducia nel ‘già pronto’ è un lusso che non possiamo più permetterci. Se avete installato pacchetti TanStack nelle date indicate (11 maggio 2026), non fate i pigri: ruotate tutte le vostre chiavi. AWS, GCP, Vault, SSH… cambiate tutto. E se gestite progetti critici, date un’occhiata a come configurate i vostri workflow. Il `pull_request_target` è una lama affilatissima: usatela con estrema cautela.
In un mondo dove l’hype tecnologico ci spinge a tutto, l’unica difesa è il sano scetticismo di chi sa che, sotto il cofano di ogni ‘magia’ software, c’è sempre un punto vulnerabile che aspetta solo di essere smontato.