A les 13:58 UTC del 30 d'octubre del 2026, la plataforma de desplegament Northflank va moure el seu incident d'«Investigating» a «Identified» i al buit de la descripció hi va escriure això: «Assume all environment variables have been decrypted. Disable/rotate all keys.» Dues frases. Cap no matisa l'altra.
Comença pel cronòmetre, no per la notícia
Abans de mirar si fas servir Northflank, fes l'exercici que converteix aquella frase en un número teu. Agafa un sol secret de producció, el que menys por faci, i rota'l de principi a fi: emet la credencial nova al proveïdor que l'expedeix, desplega-la, verifica que el servei continua viu i revoca l'antiga. Amb un cronòmetre corrent.
En surten tres xifres. La primera és el temps: multiplica'l pel total de secrets vius i ja saps quant dura el teu propi «roteu-ho tot». La segona apareix en intentar multiplicar, i és on s'encalla gairebé tothom: l'inventari. Si ningú no sap quants secrets hi ha ni qui els va emetre, llavors no hi ha pla de rotació, hi ha una bona intenció i un dijous lliure. La tercera és el radi: apunta què es va trencar en canviar aquella única clau i quines altres coses la feien servir sense que ningú ho recordés. El consumidor oblidat és el que converteix una rotació d'emergència en una caiguda.
I l'ordre importa més del que sembla quan hi ha pressa: rotar la credencial a la teva plataforma no la invalida davant el proveïdor que la va emetre. Mentre no la revoquis a l'origen, la clau vella continua servint a qui la tingui. Hi ha una excepció honesta que convé anotar abans de començar: alguns serveis només admeten una credencial activa alhora, i aquí el pas de verificació cau dins d'una finestra de tall. Aquests són justament els que no vols descobrir durant un incident.
Per què aquest número importa aquesta setmana
El rellotge de Northflank és curt. A les 11:43 UTC l'empresa de seguretat cloud Wiz els va avisar; els seus enginyers van revisar l'avís un minut després. A les 12:02, 12:50 i 13:05 van desplegar pedaços de política de xarxa. A les 13:40 ja demanaven públicament rotar les variables d'entorn, i a les 13:58 va arribar la frase del titular. Poc més de dues hores des d'un avís extern fins a una instrucció pública inequívoca és una resposta ràpida, i dir «assumeix que tot» en lloc d'administrar el pànic a terminis és més honest del que s'acostuma.
El que va venir després explica per què aquest article comença pel cronòmetre. A les 15:12 van habilitar la rotació de secrets per a Postgres i MongoDB i van recollir que diversos usuaris estan confirmant que les seves claus d'IA s'han fet servir. Northflank no va confirmar res pel seu compte aquell dia: a les 19:28 continuava dient «Our investigation is ongoing. We have no further confirmed findings to share at this time», i fins a les 23:38 no va publicar que els usuaris havien reportat ús no autoritzat de claus d'API d'IA. L'endemà van habilitar rotació també per a MySQL, Redis, Minio i RabbitMQ, i van activar registres d'auditoria per a tots els clients, inclosos els comptes gratuïts. A data de publicació continuaven sense comunicar com es va produir l'accés, quants clients van resultar afectats ni si es va abusar de credencials diferents de les d'IA.
Dit d'una altra manera: durant gairebé deu hores, l'única informació accionable que va tenir un client va ser «assumeix-ho tot». Si la teva resposta a això depèn d'un inventari que no existeix, la finestra se te'n va a construir-lo.
Com a mínim nou plataformes en trenta-un dies
L'informe Black October de Wiz recull com a mínim nou incidents revelats durant l'octubre del 2026 en plataformes de desenvolupament i IA. Entre els anomenats: Fireworks AI, Zeabur, Lightning AI, OpenCode, Railway —que va publicar el seu informe preliminar el 21 d'octubre—, Warp, CommandCode i el mateix Northflank.
Convé no estirar aquesta dada més del que dona. Wiz diu expressament que no atribueix els nou a un mateix actor i que no va trobar cap vulnerabilitat ni cap dependència compartida que els connecti; ho tracta com una concentració d'incidents. El denominador comú que sí que descriu és més modest i més útil: tots els informes públics descriuen cerca dirigida de variables d'entorn emmagatzemades, amb preferència per les que donen accés a serveis d'IA. Que nou plataformes del mateix tipus apareguin el mateix mes buscant el mateix, a nosaltres ens sembla selecció d'objectiu; aquesta lectura és nostra, i Wiz es queda a dir-ne concentració.
La raó per la qual les claus d'IA encapçalen la llista és econòmica i no necessita teories. Una contrasenya de base de dades robada cal saber-la fer servir: demana accés a la xarxa, alguna cosa de valor a dins i algú que ho compri. Una clau d'API d'un proveïdor d'IA es gasta directament, perquè el consum es factura a qui la va emetre. L'informe de Wiz, en la cobertura que hem pogut consultar, posa números al fenomen —en diuen LLMJacking—: un cas d'unes 800.000 peticions a Amazon Bedrock en 30 hores, amb al voltant del 90 % completades, i un altre de prop d'1,7 milions de peticions en 13 hores, de les quals més d'un milió van prosperar. El cost combinat que estima l'informe supera els 100.000 dòlars a preu de tarifa.
1,7 milions de peticions en 13 hores és, literalment, «la mateixa tarda». Per això, si fas servir claus d'API de proveïdors d'IA, afegeix a l'exercici una quarta tasca, i aquesta la signa l'administrador abans que el de seguretat: comprova que tens límit de despesa i alerta de consum a cada proveïdor. És l'únic control que acota el dany quan la clau ja és fora, i continua treballant mentre dorms. És la versió amb IA d'el canari de la despesa que ja vam explicar a propòsit de les claus d'AWS filtrades, i la conclusió no ha canviat: el sostre el poses abans, o no el poses.
El sistema que et protegeix és el que ha de desxifrar
La primera reacció de molta gent en llegir la notícia és preguntar si la plataforma xifrava els secrets. Northflank no ha explicat com es van desxifrar, i no ho deduirem del verb que va triar. Qui sí que ho va documentar és Railway, a l'informe preliminar del 21 d'octubre: l'atacant es va endur els secrets xifrats i al principi no els va poder obrir; després va obtenir credencials de l'entorn d'integració contínua i, amb elles, «an unauthorized query of encrypted environment variables, of which a subset were decrypted utilizing a combination of the compromised credentials».
Aquí hi ha el mecanisme, per escrit i signat pel proveïdor. Qualsevol plataforma que executi el teu codi ha de poder desxifrar les teves variables d'entorn en el moment d'arrencar el procés. Si no, la teva aplicació no arrenca. El xifratge en repòs protegeix del robatori del disc; no et protegeix si algú compromet precisament el sistema la feina del qual és desxifrar.
Pregunta a qualsevol proveïdor si xifra i et dirà que sí. La pregunta que ningú no contesta per escrit és quants llocs diferents poden desxifrar avui els teus secrets, i si aquesta llista existeix en algun lloc. En una empresa de programari mitjana la resposta sol incloure el proveïdor de desplegament, el sistema d'integració contínua, el gestor de secrets, dues o tres eines SaaS amb integració, el portàtil d'algú i un repositori privat amb un fitxer d'exemple que va deixar de ser d'exemple. És la mateixa qüestió que plantejàvem quan vam explicar que al registre no hi surt l'agent, hi surt qui li va deixar el token, un pis més avall: allà era l'agent que fa servir la credencial, aquí la plataforma que la desa.
On ens deixa això a nosaltres
Seria fàcil tancar això amb un «per això, infraestructura pròpia», i no és veritat. Nosaltres també tenim secrets en llocs que executen el nostre codi. Fem servir n8n autoallotjat per a automatitzacions internes, i desa credencials com les desa qualsevol; el que fem amb ell és tractar-lo com un servei de producció i no com una eina d'anar per casa: està inventariat, té un responsable i té finestra d'actualització. Això no evita un incident del proveïdor. El que aconsegueix és que, el dia que arribi una frase com la de Northflank, la llista ja existeixi.
La decisió que sí que és arquitectònica, i la que discutim amb els clients quan muntem infraestructura i cloud, resulta bastant més avorrida que triar proveïdor: quantes plataformes diferents necessiten de debò poder desxifrar les teves credencials, i si cadascuna aporta prou com per justificar que hi sigui. Escurçar aquesta llista rendeix més que endurir cada element, i és el primer que mirem en una revisió de ciberseguretat.
Si fas la prova del cronòmetre i el número que en surt t'incomoda, o si t'encalles abans, a l'inventari, escriu-nos. Mitja tarda de feina i una xifra pròpia valen més que qualsevol informe sobre l'incident d'un altre.
Nota de fonts. La cronologia de l'incident (avís de Wiz a les 11:43 UTC del 30-10-2026, pedaços de política de xarxa a les 12:02, 12:50 i 13:05, avís de rotació a les 13:40, canvi a «Identified» amb la frase citada a les 13:58, rotació per a Postgres i MongoDB més els reports d'usuaris a les 15:12, la nota de les 19:28 i la publicació dels reports d'ús no autoritzat a les 23:38) prové de la pàgina d'estat de Northflank, complementada amb la cobertura de BleepingComputer del 31-10-2026. Les frases entre cometes de Northflank i de Railway són literals de les seves publicacions respectives; la de Railway, del seu informe preliminar del 21-10-2026. El recompte de com a mínim nou incidents d'octubre, els noms de les plataformes, el denominador comú, el terme LLMJacking i les xifres de peticions a Amazon Bedrock i de cost estimat provenen de l'informe Black October de Wiz a través de la cobertura que hem pogut consultar; no hem llegit l'informe directament, i ho assenyalem perquè les xifres de cost són estimacions a preu de tarifa, no factures verificades. La lectura que això és selecció d'objectiu és nostra i està marcada com a tal al text. No som clients de cap de les plataformes citades ni hem participat en la resposta a cap d'aquests incidents.
Microsoft 365
ES 
CAT 
EN