Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Presunto Attacco alla supply chain di SAP: pacchetti npm ufficiali trasformati in malware

Presunto Attacco alla supply chain di SAP: pacchetti npm ufficiali trasformati in malware

2 Maggio 2026 07:53
In sintesi

L’attacco supply chain a SAP, ha compromesso quattro pacchetti npm del Cloud Application Programming Model tra le 09:55 e le 12:14 UTC del 29 aprile 2026. Il malware, attribuito a TeamPCP, sfrutta un hook di installazione per attivare un credential stealer che esfiltra token GitHub, chiavi cloud e segreti CI/CD. I dati vengono pubblicati su repository GitHub. L’incidente è critico perché coinvolge ambienti enterprise e introduce persistenza tramite VS Code e agenti AI.

Nel pomeriggio del 29 aprile 2026 una grande quantità di post su X riportavano il presunto attacco alla supply chain di SAP tramite pacchetti ppm ufficiali. Subito l’attribuzione a TeamPCP era piuttosto verosimile. In serata diverse analisi tecniche confermano la compromissione.

In particolare il 29 Aprile 2026, tra le 09:55 e le 12:14 UTC, quattro pacchetti npm ufficiali dell’ecosistema SAP CAP sono stati compromessi e sostituiti con versioni malevole sul registro pubblico di npm.

I pacchetti coinvolti sono [email protected]@cap-js/[email protected]@cap-js/[email protected] e @cap-js/[email protected]— tutti parte del Cloud Application Programming Model di SAP, ampiamente utilizzato da team di sviluppo enterprise per costruire applicazioni su SAP BTP.

Advertising

Come funziona il payload

Le versioni compromesse introducono un hook preinstall nel file package.json che, al momento dell’installazione, esegue un file chiamato setup.mjs. Questo agisce da loader per il runtime Bun JavaScript e avvia il vero payload: execution.js, il credential stealer e framework di propagazione.

Come evidenziato da Socket nella propria analisi, le versioni compromesse introducono comportamenti in fase di installazione che non facevano parte della funzionalità attesa di questi pacchetti. Il payload da 11,6 MB è costruito per sopravvivere all’analisi: i dati esfiltrati vengono cifrati con AES-256-GCM, la chiave è incapsulata tramite RSA-4096 con la chiave pubblica embedded nel binario. Solo l’attaccante può decifrarli.

Cosa viene esfiltrato

I ricercatori di Aikido SecuritySocketSafeDepStepSecurity e Wiz hanno analizzato il payload in modo indipendente e concordano su cosa va a ricercare: credenziali developer locali, token GitHub e npm, GitHub Actions secrets, chiavi cloud AWS, Azure, GCP, Kubernetes.

I dati vengono caricati su repository GitHub pubblici creati direttamente sull’account della vittima, con la descrizione “A Mini Shai-Hulud has Appeared.” Al momento in cui scriviamo, sono già oltre 1.100 i repository con questa descrizione identificati su GitHub.

Il vettore di persistenza

Il malware inietta nei repository accessibili due file: .claude/settings.json e .vscode/tasks.json. Il primo abusa dell’hook SessionStartdi Claude Code, l’agente di coding AI di Anthropic. Il secondo sfrutta l’opzione "runOn": "folderOpen" di Visual Studio Code. Risultato: chiunque apra un repository infetto in VS Code o in Claude Code esegue automaticamente il payload.

Advertising

È il primo supply chain attack documentato a targettizzare configurazioni di agenti AI come vettore di persistenza e propagazione. StepSecurity lo ha definito esplicitamente taleWiz ricollega la campagna al threat actor TeamPCP, già responsabile delle precedenti ondate Shai-Hulud.

La cause

SafeDep ha ricostruito come è avvenuta la compromissione (che riporta nel dettaglio le cause), tuttavia si va dalla compromissione di account GitHub, ha configurazioni di sicurezza non corrette fino alla compromissione di token statitici.

Il malware esclude sistematicamente i sistemi con locale russa, comportamento tipico di threat actor di origine est-europea che si proteggono da potenziali coinvolgimenti domestici.

Versioni sicure disponibili

I maintainer SAP hanno reagito rapidamente. I rilasci sicuri sono disponibili sui repository ufficiali:

Chi ha installato le versioni compromesse tra le 09:55 e le 12:14 UTC del 29 aprile deve assumere come compromessi tutti i token presenti nell’ambiente di sviluppo e nella pipeline CI/CD e avviare una rotazione completa. È anche necessario ispezionare i repository per la presenza di file .claude/settings.json non autorizzati, di .vscode/tasks.json con runOn: folderOpen non riconosciuti, e di workflow GitHub Actions non attesi.

Ci aspettiamo che nei prossimi giorni emergano casi di organizzazioni colpite che non hanno ancora fatto l’audit. Il dato dei 1.100 repository pubblici con la firma della campagna non è trascurabile. Non è un incidente isolato di sviluppatori individuali: con tutta probabilità coinvolge anche ambienti enterprise.

Fonti:


📢 Resta aggiornatoTi è piaciuto questo articolo? Rimani sempre informato seguendoci su 🔔 Google News.
Ne stiamo anche discutendo sui nostri social: 💼 LinkedIn, 📘 Facebook e 📸 Instagram.
Hai una notizia o un approfondimento da segnalarci? ✉️ Scrivici


Luca Stivali 300x300
Cyber Security Enthusiast e imprenditore nel settore IT da 25 anni, esperto nella progettazione di reti e gestione di sistemi IT complessi. Passione per un approccio proattivo alla sicurezza informatica: capire come e da cosa proteggersi è fondamentale.
Aree di competenza: Cyber Threat Intelligence, Architectural Design, Divulgazione