Perché le aziende devono proteggere sviluppo, CI/CD e componenti open source prima che diventino il punto d’ingresso degli attaccanti
Negli ultimi giorni la community PHP e Laravel è stata colpita da un nuovo caso di compromissione della software supply chain: alcuni pacchetti della famiglia Laravel-Lang, usati per la localizzazione e le traduzioni nelle applicazioni Laravel, sono stati manipolati per distribuire un credential stealer cross-platform. Secondo quanto riportato da The Hacker News, i pacchetti coinvolti includono laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes e laravel-lang/actions.
L’aspetto più preoccupante non è soltanto la presenza di codice malevolo, ma il modo in cui l’attacco è stato realizzato. I ricercatori hanno osservato la pubblicazione o riscrittura rapida di centinaia di tag tra il 22 e il 23 maggio 2026, un comportamento compatibile con una compromissione del processo di rilascio dell’organizzazione Laravel-Lang, più che con una singola versione malevola isolata.
In pratica, un componente che gli sviluppatori potevano considerare “normale” e “affidabile” è diventato un veicolo per eseguire codice non autorizzato all’interno di ambienti di sviluppo, pipeline CI/CD, container, server e workstation.
Il vero problema: non serve bucare il perimetro, basta entrare nel processo di sviluppo
Gli attacchi moderni non cercano sempre la porta principale. Sempre più spesso puntano agli strumenti usati ogni giorno dagli sviluppatori: librerie open source, package manager, token di accesso, script di build, repository Git, sistemi di deploy e ambienti cloud.
Nel caso Laravel-Lang, il codice malevolo è stato inserito in un file src/helpers.php e agganciato alla sezione autoload.files di Composer. Questo dettaglio è fondamentale: i file dichiarati in autoload.files vengono caricati automaticamente quando l’applicazione avvia l’autoloader di Composer. Di conseguenza, non era necessario che uno sviluppatore invocasse esplicitamente una funzione compromessa: il payload poteva attivarsi semplicemente all’avvio dell’applicazione o durante l’esecuzione di comandi e processi collegati.
Il malware contattava il dominio flipboxstudio[.]info, scaricava un secondo payload ed era progettato per operare su Windows, Linux e macOS. Le analisi pubblicate indicano capacità di raccolta di credenziali cloud, token CI/CD, chiavi SSH, segreti Kubernetes, file .env, credenziali Git, password manager, dati browser, configurazioni VPN e altri dati sensibili.
Questo significa che l’impatto potenziale non riguarda soltanto il sito Laravel in sé. Un attacco di questo tipo può aprire la strada a compromissioni molto più ampie: accesso al cloud, movimento laterale, furto di codice sorgente, manipolazione delle pipeline, compromissione di ambienti di produzione e perdita di dati riservati.
“Abbiamo aggiornato i pacchetti” non basta più
Uno degli errori più comuni dopo un incidente di supply chain è trattarlo come una normale vulnerabilità: si aggiorna la libreria, si chiude il ticket e si considera risolto il problema.
In questo caso, però, l’approccio deve essere diverso. Snyk raccomanda di trattare come potenzialmente compromesso ogni ambiente che abbia installato uno dei pacchetti coinvolti nella finestra dell’attacco, perché le versioni compromesse sono state successivamente rimappate e il solo numero di versione potrebbe non bastare a stabilire se un sistema sia stato esposto.
Le attività minime da considerare includono il controllo di composer.lock e composer.json, la verifica della presenza di src/helpers.php nei pacchetti laravel-lang/*, la ricerca di cartelle temporanee come .laravel_locale, l’analisi dei log DNS e firewall verso flipboxstudio[.]info, la rotazione dei segreti e la ricostruzione degli ambienti coinvolti da immagini pulite.
Il punto è chiaro: quando un malware ha avuto accesso a un processo PHP, a una pipeline o a un runner CI/CD, bisogna presumere che tutto ciò che quel processo poteva leggere sia stato potenzialmente esfiltrato.
La supply chain software è ormai parte del perimetro aziendale
Per anni la cybersecurity aziendale si è concentrata soprattutto su firewall, antivirus, backup e protezione degli endpoint. Sono ancora elementi importanti, ma non bastano più.
Oggi il perimetro include anche:
- le dipendenze open source;
- i repository Git;
- i token usati da sviluppatori e pipeline;
- i file
.env; - le immagini container;
- i runner CI/CD;
- le configurazioni cloud;
- i fornitori software e i componenti terzi.
Anche il quadro normativo europeo va in questa direzione. La Direttiva NIS2 include tra le misure di gestione del rischio anche la sicurezza della catena di approvvigionamento, comprese le relazioni tra organizzazioni e fornitori o prestatori di servizi.