L’atac a Laravel-Lang que va comprometre centenars de versions

Un atac a diversos paquets comunitaris de Laravel va demostrar que PHP no està al marge de la crisi de seguretat de les dependències. Midudev repassa dues campanyes diferents: la reescriptura massiva d’etiquetes de Laravel-Lang i la inserció de scripts maliciosos en projectes distribuïts a través de Packagist. Després amplia el focus a npm, PyPI i Crates.io.

El missatge central és correcte: el risc no pertany a un llenguatge, sinó al procés que converteix un paquet de tercers en codi executat dins l’ordinador d’un desenvolupador o un sistema d’integració contínua. Alguns detalls del vídeo, però, se superposen i convé ordenar-los.

1. Què va passar amb Laravel-Lang

A 00:00, Midudev presenta l’incident com l’atac a PHP que ningú no esperava. Els objectius van ser laravel-lang/lang, http-statuses, attributes i actions: projectes de la comunitat, no components oficials del nucli de Laravel.

La investigació tècnica de StepSecurity situa l’activitat entre el 22 i el 23 de maig de 2026. Algú amb accés d’escriptura a l’organització va moure centenars d’etiquetes històriques perquè apuntessin a commits maliciosos. Això és especialment perillós perquè una versió aparentment antiga i coneguda podia deixar de correspondre al codi que els usuaris havien auditat.

El codi afegia src/helpers.php a autoload.files de Composer. Aquesta modalitat carrega el fitxer tan bon punt l’aplicació inclou vendor/autoload.php; no cal cridar cap classe infectada. En una prova aïllada, StepSecurity va observar la descàrrega d’una segona fase, l’intent d’exfiltrar secrets del procés i l’eliminació ràpida dels fitxers temporals.

El vídeo parla de més de 700 versions afectades. La xifra varia segons el moment i la font perquè es van comptar etiquetes i paquets diferents, però l’ordre de magnitud és real. L’important no és el número exacte: l’atacant va alterar l’historial publicat, no només una versió nova fàcil d’evitar.

2. Packagist, Composer i els scripts de Node

A 01:35, Midudev passa a una altra campanya que afectava vuit paquets PHP. En repositoris aparentment normals s’havia introduït un package.json amb un postinstall que descarregava i executava programari maliciós.

Cal distingir les eines. Composer resol les dependències PHP i Packagist n’és el registre principal; package.json i postinstall pertanyen a l’ecosistema de Node. Composer no executa per defecte un postinstall de npm. El perill apareix quan un projecte PHP inclou també una fase de construcció frontal i el desenvolupador o el CI executa npm install al repositori compromès.

Al vídeo, Midudev obre un exemple que descarrega un binari de Linux, el desa com un fals servei i l’executa en segon pla. La descripció de l’incident coincideix amb aquest mecanisme. Les dues campanyes comparteixen l’objectiu —executar codi de confiança aparent—, però utilitzen activadors diferents: l’autoload de Composer en Laravel-Lang i els scripts de cicle de vida de npm en els altres repositoris.

3. Per què instal·lar dependències és un punt crític

A 03:00, el vídeo celebra una proposta perquè npm deixi d’executar automàticament scripts d’instal·lació. La direcció es va concretar després: el canvi anunciat per a npm 12 bloqueja per defecte scripts de dependències i exigeix autoritzar explícitament els paquets que els necessiten.

És una millora important perquè converteix l’execució silenciosa en una decisió visible. També pot trencar compilacions natives o paquets legítims que depenen de install, postinstall o node-gyp. Els equips han de preparar una llista d’autoritzacions, no limitar-se a actualitzar el gestor i esperar que tot funcioni.

Composer té una superfície diferent. Els plugins i scripts es poden restringir, però Laravel-Lang va abusar del mecanisme d’autocàrrega que una aplicació necessita per funcionar. Per això cap única opció elimina tot el risc: el lockfile, els hashes immutables, la revisió de canvis i el control de xarxa continuen sent necessaris.

4. No és un problema exclusiu de JavaScript

A 04:00, Midudev recorda campanyes contra npm, PyPI i Crates.io. Els atacants poden comprometre el compte d’un mantenidor, robar un token de publicació, moure una etiqueta Git o crear un nom gairebé idèntic al d’una biblioteca popular.

El premi és molt gran. Un procés de desenvolupament pot veure claus SSH, tokens de GitHub, credencials d’AWS, variables d’entorn, carteres de criptomonedes i permisos del clúster on s’executa. Si el paquet infecta un runner de CI, pot intentar robar credencials de publicació i convertir una víctima en el següent esglaó de la campanya.

La popularitat tampoc no és una garantia. Un paquet desconegut facilita el typosquatting, però una biblioteca legítima amb milions de descàrregues és encara més atractiva si se’n compromet el mantenidor. La confiança s’ha de basar en identitat, procedència i integritat del codi concret, no només en el nom.

5. Mesures pràctiques i resposta a una possible infecció

A 05:00, el vídeo recull recomanacions atribuïdes al grup atacant TeamPCP: fixar dependències a un hash, usar tokens de privilegi mínim i restringir extensions de l’IDE. Són consells útils, encara que no cal esperar que els atacants els formulin.

En un projecte PHP, s’ha de conservar composer.lock, revisar qualsevol regeneració i verificar si conté els quatre paquets afectats amb commits del període maliciós. En Node, npm ci, el lockfile i la desactivació de scripts redueixen sorpreses, però el lockfile només protegeix si la referència és immutable i el registre no en pot canviar el contingut.

Els tokens de CI haurien de tenir abast i durada mínims. També convé separar compilació i desplegament, impedir sortides de xarxa inesperades i registrar DNS, processos i connexions. Un escàner de dependències pot avisar, però no substitueix aquestes barreres.

Si un entorn va carregar una versió afectada de Laravel-Lang, StepSecurity recomana tractar com a exposat qualsevol secret accessible, rotar credencials i buscar connexions al domini de comandament documentat. Reinstal·lar el paquet sense canviar les claus no repara una filtració anterior.

Conclusions

L’atac no demostra que PHP sigui insegur ni que npm sigui l’únic culpable. Demostra que una cadena de subministrament moderna connecta repositoris, etiquetes, registres, gestors, scripts, runners i credencials. Comprometre un sol punt pot donar execució en centenars de projectes.

La defensa més efectiva és acumulativa: dependències immutables, permisos mínims, aprovació d’scripts, procedència verificable, xarxa restringida i capacitat de rotar secrets ràpidament. L’actualització automàtica continua sent útil, però ja no pot ser confiança automàtica.