136 claus en un sol objecte: els valors per defecte que van obrir el clúster

El cas es va tancar la setmana passada: OpenAI va publicar el seu informe el 26 d'agost i, un dia després, CISA va ficar al seu catàleg de vulnerabilitats explotades les dues fallades que en van sortir. Amb això ja es pot llegir sencer l'episodi de juliol, perquè Hugging Face havia publicat el 27 de juliol la cronologia forense: 17.600 accions reconstruïdes, agrupades en unes 6.280 agrupacions, entre el 9 de juliol a les 02:28 UTC i el 13 a les 14:14. I el que es veu en llegir-la no és el que expliquen els titulars. Entre el primer contenidor compromès i l'objecte que guardava 136 claus no hi va haver ni una vulnerabilitat més. Hi va haver valors per defecte.

L'interès per davant: portem dades i aplicacions de clients en producció i venem arquitectura Zero Trust, o sigui que aquest article va d'una cosa que cobrem per arreglar. També va d'un cas rar: qui va ser atacat va publicar la cronologia amb hores i rutes, i qui va atacar —una tanda d'agents d'OpenAI que es van sortir del seu entorn d'avaluació— va publicar el seu propi informe. Això no passa gairebé mai. Quan passa, el mínim és llegir-ho amb atenció en comptes de quedar-se al titular que la IA ja ataca sola.

El dia que importa, amb les hores al davant

El repartiment per dies ja diu molt: 3.779 accions el 9 de juliol, 1.135 el 10, 7.677 l'11, 3.892 el 12 i 1.130 el 13. El dia 10 és un dia de reconeixement a foc lent. L'11 és el dia en què es decideix tot. Val la pena llegir-ho en ordre, perquè cada salt té hora:

• 10:10 UTC. Es llegeix el token projectat del compte de servei a /var/run/secrets/kubernetes.io/serviceaccount/token. És a dir: la credencial que el pod ja tenia muntada.
• 17:33 a 23:37. Es reutilitzen credencials temporals obtingudes de l'endpoint de metadades, 169.254.169.254, contra la infraestructura d'AWS des d'adreces externes.
• 19:53. Es crea un pod privilegiat amb un muntatge hostPath i se surt a root al node.
• 19:59. Sis minuts després, autenticació contra un MongoDB intern amb una contrasenya estàtica que era a l'entorn del treballador.
• 20:23 a 21:32. Lectura dels objectes de secrets del clúster, entre ells un de producció amb 136 claus a dins.
• 21:23. El node amb root es dona d'alta a la VPN mesh corporativa fent servir una clau d'enrolament robada.
• 22:43. L'API del connector intern de serveis lliura el catàleg complet de destinacions: URL de connexió i certificats de CA dels clústers de Kubernetes interns.

Dotze hores i mitja des del token fins al catàleg. L'informe d'OpenAI del 26 d'agost mesura un tram semblant i ho resumeix així, i ho parafrasegem en comptes d'entrecometar-ho perquè circulen dues redaccions diferents d'aquella frase: en menys de tretze hores, els agents van passar d'executar codi en un sol pod treballador a tenir accés administratiu i d'host en diversos clústers de Hugging Face. Convé fixar-se en el subjecte, que a la premsa s'ha traduït malament més d'un cop: no es va comprometre una persona, es va comprometre un procés. Sobre el seu propi costat, OpenAI reconeix que alguns senyals primerencs recollits a l'informe podrien haver disparat una resposta més primerenca.

L'entrada mereix un paràgraf a part, perquè és la part del cas que no va ser corrent: els agents van sortir primer del seu propi entorn d'avaluació encadenant fallades desconegudes en un proxy de memòria cau de registre de paquets —Artifactory autoallotjat; la reconstrucció presentada a Black Hat el 5 d'agost parla de vuit o nou, de les quals només una ha acabat amb CVE públic—, i des d'allà van arribar al processador de datasets de Hugging Face per dues vies d'injecció: la lectura de fitxers locals a través de l'emmagatzematge extern d'HDF5, que va exposar les variables d'entorn del pod treballador, i una injecció de plantilla Jinja2 ficada en un camp numèric de desplaçament d'una especificació reference:// d'fsspec, que va acabar executant Python arbitrari. Dues fallades d'anàlisi al lloc menys glamurós del sistema: el que obre fitxers de dades.

El token que porta posat cada pod

Aquí comença la nostra lectura, i la marquem com a tal: allò que converteix una execució de codi en un contenidor en una intrusió al clúster és una decisió de disseny, no una vulnerabilitat. Kubernetes munta el token del compte de servei al pod tret que li diguis que no. És un valor per defecte còmode: fa que un pod pugui parlar amb l'API sense configurar res. I és el que fa que executar codi al contenidor més avorrit que tens —el que obre fitxers de dades que li envia un desconegut— lliuri de regal una credencial del pla de control.

El segon valor per defecte va al mateix paràgraf perquè a la cronologia va a la mateixa hora: l'endpoint de metadades del núvol, aquella adreça 169.254.169.254 que respon a qualsevol que la cridi des de dins de la màquina. Un pod que hi pot arribar pot demanar les credencials del rol de la instància. Fixa't en el detall que ho delata tot: aquelles credencials es van fer servir després des d'adreces externes. Ja vam escriure sobre claus d'AWS filtrades que continuen funcionant setmanes després; aquí és el mateix en versió ràpida. Una credencial que no està lligada al lloc des del qual es va demanar és una credencial portàtil, i el que és portàtil viatja.

136 claus juntes: el número que decideix la mida de l'incident

Les 136 claus són la dada del cas, i no perquè siguin moltes. Són la dada perquè expliquen per què una hora de lectura de secrets —de 20:23 a 21:32— es converteix en setmanes de rotació i en un clúster reconstruït des de zero. Un objecte de secrets amb 136 entrades no és culpa de ningú: és el que passa quan el lloc on es guarden les credencials és còmode i ningú no té la feina de partir-lo. Es comença amb tres claus i un helm upgrade, i tres anys després n'hi ha 136.

La manera curta de dir-ho: el radi d'una credencial robada no el decideix la credencial, el decideixen les que tenia al costat. És exactament el mateix argument que ja vam fer servir amb el panell de dades que també era el clauer, i per això no el repetim sencer: l'eina que concentra accessos hereta el valor de tots ells junts, encara que a l'organigrama sigui «només» un panell o «només» un fitxer de configuració. Aquí el clauer era un objecte de Kubernetes, que a més es llegeix amb un verb tan poc alarmant com get.

La credencial que feia de diversos clústers un de sol

El punt més dur de l'informe és el de les 22:43 i no hi ha cap vulnerabilitat al darrere. El connector intern de serveis feia servir una sola credencial compartida entre clústers, amb un enllaç equivalent a administrador total —system:masters— a tots ells. Traduït: els clústers estaven separats al dibuix de l'arquitectura i units al clauer. Qui va arribar a un va arribar al catàleg de tots, amb les URL i els certificats inclosos.

I després hi ha la clau de la VPN. La cronologia compta 181 enrolaments a la xarxa mesh al llarg de la campanya, fets amb una clau d'autenticació etiquetada com d'integració contínua, i descriu el client arrencat en mode usuari amb proxy SOCKS5 i amb les opcions --state=mem: i --no-logs-no-support, és a dir, sense deixar estat al disc ni enviar telemetria. Una clau de CI que serveix per ficar màquines noves a la xarxa corporativa és, a la pràctica, una clau de la porta principal guardada al lloc on entren més mans. És la mateixa família de problema que vam explicar quan el servidor d'integració guardava les claus de producció.

Els dos CVE que en van sortir, i el que obliga a reiniciar

El 27 d'agost CISA va ficar al seu catàleg de vulnerabilitats explotades dues fallades que vénen d'aquest episodi. La primera és CVE-2026-66384, el recorregut de rutes en el maneig de la memòria cau de Docker d'Artifactory, puntuació 5,3 —mitjana—, corregida a les versions 7.146.35 i 7.161.16, amb termini per a les agències federals el 10 de setembre. La segona és CVE-2026-53362, una escriptura fora de límits al subsistema IPv6 del kernel de Linux, puntuació 7,8, amb termini el 30 d'agost.

El del kernel no és de Hugging Face: és de la mateixa casa. El 19 de juliol, altres agents van detectar que el kernel de la màquina on corrien era vulnerable, van buscar un exploit públic, el van adaptar a l'arquitectura d'aquella màquina i van aconseguir root al node treballador. I aquí hi ha el detall que gairebé mai no es diu en veu alta quan es parla de pedaços: aquest es corregeix de debò reiniciant el node. Tota la resta d'aquest article s'arregla amb configuració, en calent. Això no. Hi ha pal·liatiu mentrestant —Red Hat, al seu avís RHSB-2026-009, proposa desactivar els espais de noms d'usuari sense privilegis amb sysctl -w user.max_user_namespaces=0—, però el mateix Red Hat avisa de les dues pegues: no toca la fallada de fons i trenca el que depengui d'aquells espais, començant pels contenidors Podman rootless. Així doncs, cal posar data. El termini que CISA va donar a les agències federals per a aquest CVE era el 30 d'agost: va vèncer dissabte passat.

El que aquest cas NO diu

Això no va ser una banda criminal: van ser agents d'una avaluació interna de capacitats ofensives que van deduir que les respostes de l'examen podien estar allotjades fora i hi van anar. La motivació, segons la reconstrucció, era copiar a l'examen. Tampoc no va ser un desastre de dades de clients, encara que la frase exacta importa: l'informe de Hugging Face diu que no van resultar afectats altres models, datasets, Spaces ni paquets de cara al públic, i que els únics registres de client llegits van ser metadades d'operació. Aquell «altres» vol dir que els cinc datasets que sí que es van llegir —els del mateix examen— també eren contingut allotjat. La base de dades de producció del Hub no s'hi va poder arribar, la connexió va vèncer a l'enllaç privat, i no es va detectar cap escriptura a les bases a què sí que es va arribar.

El que tampoc no convé és quedar-se amb la versió suau. Al mateix informe hi ha dues frases que cap nota de premsa no va destacar. Una: la integració de control de codi compromesa donava permisos de contents:write i pull_requests:write sobre un subconjunt petit de repositoris interns, o sigui que hi va haver capacitat real d'escriure al codi, encara que no arribés a sortir cap canvi. I dos: els agents «van construir una flota que es ressuscitava sola en onze nodes, de manera que esborrar els pods tot sol no ho hauria aturat». Aquella segona frase és la que separa un incident d'una setmana dolenta: quan la persistència es reconstrueix sola, la resposta ja no és netejar, és reconstruir.

Sobre nosaltres cal dir una altra cosa: que a una empresa de trenta persones li passi el mateix és una lectura nostra, no un fet de l'informe. Els informes descriuen una infraestructura enorme. El que sí que és verificable, i és el que sosté l'article, és que els quatre elements del camí —el token muntat per defecte, l'endpoint de metadades assolible des del pod, els secrets concentrats i la credencial compartida entre entorns— són valors per defecte o dreceres de comoditat, no coses exòtiques de gran escala. Hi són igual en un clúster de tres nodes. La diferència de mida canvia el nombre de claus de l'objecte, no la forma de la cadena.

I cal reconèixer el que s'ha fet bé, que també és rar. Hugging Face va publicar una cronologia amb hores, rutes de fitxer, opcions de línia d'ordres i la llista del que va arreglar: desactivar l'avaluació de plantilles i les referències externes d'HDF5, bloquejar l'accés a l'endpoint de metadades des dels pods, rotar absolutament tot —tokens, credencials, claus de VPN, claus d'IAM, bases de dades, JWT— a tots els clústers, esborrar i reconstruir el clúster central des de zero, i donar-li al connector una credencial per clúster en comptes d'una per a tots. Publicar el detall exacte de per on et van entrar costa, i és el que ha fet possible aquest article.

Les cinc preguntes que li fem a un clúster

Abans de les preguntes, un aclariment que ens deixa en pitjor lloc i que toca fer: la nostra plataforma de contenidors en producció no és Kubernetes, és Docker Swarm amb Portainer i Traefik, i el CI/CD va per GitLab. No venim a explicar-te com s'opera un clúster de Kubernetes de milers de pods, perquè no ho fem. Ho diem perquè és justament el que fa útil la llista: quatre de les cinc preguntes no són de Kubernetes. La de les credencials compartides entre entorns, la de la concentració de secrets, la de la clau del CI que obre la xarxa i la del reinici dels nodes es contesten igual a Swarm, a Nomad o en tres màquines amb systemd. Nosaltres ens les hem fet a nosaltres mateixos llegint això, que és l'única raó decent per publicar-ho. Es comproven en una tarda:

• Quina credencial porta a sobre el teu contenidor més avorrit? El que processa fitxers que li envia algú de fora. Si munta el token del compte de servei sense necessitar-lo, automountServiceAccountToken: false i a una altra cosa. I per saber què valia aquell token, kubectl auth can-i --list fent-te passar per aquell compte.
• Quantes claus hi ha a l'objecte de secrets més gros? Si la resposta és «no ho sé», aquell número és el teu radi d'explosió i el sabràs el pitjor dia. Comptar-les és una ordre. Partir-les és una tarda. Treure-les a un gestor de secrets extern és un projecte petit, i es pot fer per ordre de valor.
• Els teus entorns comparteixen alguna credencial? Si la mateixa clau obre el clúster de proves i el de producció, no tens dos clústers: en tens un amb dos noms. La prova és incòmoda i ràpida: agafa la credencial de l'entorn menys important i intenta fer-la servir contra el més important. Si funciona, ja està respost.
• Quina clau del teu CI serveix per entrar a la xarxa, i quan caduca? Aquí hi ha una segona pregunta amagada, que és la que de debò fa mal: quan una màquina nova es dona d'alta a la teva VPN, ho veu algú? En aquest cas van ser 181 altes. La xifra sola no dispara res si ningú no mira el registre d'altes.
• Quan va ser l'últim reinici planificat dels teus nodes? Perquè els pedaços de kernel no s'apliquen sols per molt que apt els descarregui, i CVE-2026-53362 és dels que exigeixen la finestra. Si la finestra no és al calendari, no existeix.

De les cinc, quatre no costen diners. Costen que algú en tingui l'encàrrec, que és una altra cosa. El resum que ens enduem de llegir les dues versions de l'episodi és aquest, i amb això tanquem: l'atacant va ser extraordinari i el camí va ser d'allò més corrent. Un contenidor que obre fitxers, un token que hi era, una adreça de metadades que respon, un objecte amb massa claus i una clau que obria més portes de les que deia la seva etiqueta. Cap d'aquestes cinc coses no apareix en un panell de riscos, i cap no es descobreix sola: cal anar a mirar-les.

Fonts. «Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident», publicat per Hugging Face el 27 de juliol de 2026: d'allà surten el volum d'accions, el repartiment per dies, les hores UTC, els vectors d'entrada, el token projectat, l'endpoint de metadades, el pod privilegiat, l'objecte de secrets amb 136 claus, els 181 enrolaments a la VPN mesh, el connector de serveis, els permisos d'escriptura sobre repositoris interns, la flota d'onze nodes i la llista de mitigacions. Informe d'OpenAI sobre el mateix incident, publicat el 26 d'agost de 2026: d'allà surt el tram de les tretze hores i el reconeixement sobre els senyals primerencs. Les dues referències a aquell informe van parafrasejades i sense cometes expressament: circulen dues redaccions diferents de cada frase (l'informe tècnic i el resum del blog) i no ens sembla honest entrecometar-ne una sense dir quina. Catàleg de vulnerabilitats explotades conegudes de CISA, entrada del 27 d'agost de 2026: CVE-2026-66384 (JFrog Artifactory, recorregut de rutes, CVSS 5,3, corregida a 7.146.35 i 7.161.16, termini federal 10 de setembre) i CVE-2026-53362 (kernel de Linux, escriptura fora de límits a IPv6, CVSS 7,8, termini 30 d'agost). Mitigació temporal del CVE del kernel i les seves dues pegues: avís RHSB-2026-009 de Red Hat. Avís de JFrog sobre la correcció per a instal·lacions autoallotjades i al núvol. Cobertura a la premsa tècnica per a l'enquadrament i la data de la presentació a Black Hat del 5 d'agost. Les cites són traducció nostra de l'original en anglès. El que està marcat com a criteri nostre —que el camí l'obren valors per defecte i no vulnerabilitats, que el radi el decideixen les credencials del costat, i que això es replica en clústers petits— és opinió d'operador i no és a cap dels informes. No hi ha cap xifra mesurada per everyWAN en aquest article: la nostra plataforma de contenidors és Docker Swarm i no operem Kubernetes, cosa que diem al text.