La teva política de pedaços no contempla que no hi hagi pedaç

La teva política de seguretat diu alguna cosa semblant a «les vulnerabilitats crítiques es corregeixen en 72 hores». Llegeix-la un altre cop pensant en el cas en què el pedaç no existeix. No és un supòsit de laboratori: el 21 de setembre van entrar a l'organització neerlandesa que es dedica a avisar els altres que apedacin, i onze dies després, el segon dels dos errors que van fer servir per entrar continua sense correcció publicada. El fabricant va dir la nit de l'1 d'octubre que ja té els detalls i que hi està treballant. Aquesta frase, «hi estem treballant», és la que la teva política no sap processar.

El que va passar, amb les dates del qui ho va patir

El DIVD —Dutch Institute for Vulnerability Disclosure— és una fundació de voluntaris que rastreja internet buscant sistemes vulnerables i n'avisa els propietaris. El 29 de setembre van publicar l'expedient de l'incident que ells mateixos acabaven de patir. A l'expedient li van posar un títol que no és casual: «When, not if…», quan, no si.

La cronologia és seva, no nostra. 21 de setembre: primer accés de l'atacant. 22 de setembre: se n'adonen, bloquegen l'accés a tots els sistemes del centre de dades i munten equip de resposta a incidents amb una empresa externa, Merlon Security. 24 de setembre: reporten la vulnerabilitat al fabricant, avisen socis i afectats i fan la primera declaració pública. 26 de setembre: obren un segon expedient per escanejar instàncies vulnerables a internet i avisar-ne els propietaris. 29 de setembre: publiquen l'expedient. 30 de setembre: expliquen que van entrar per dos dies zero. 1 d'octubre: publiquen quines dades van sortir.

La primera declaració comença amb dues paraules: «We got hacked». I tanca amb una regla de treball que val la pena robar: «Until proven otherwise, we handle this as a worst case scenario and assume breach» —fins que es demostri el contrari, ho tractem com el pitjor escenari i assumim que hi va haver bretxa—. Van notificar-ho a l'autoritat de protecció de dades neerlandesa, al NCSC-NL i van parlar amb la policia. L'1 d'octubre van explicar la part incòmoda: van sortir dades de voluntaris, adreces de correu del DIVD i possiblement dades de contacte. I van escriure ells mateixos la conseqüència, que és la que de debò importa: ara és més fàcil que algú es faci passar per un voluntari del DIVD.

El titular és «ho va fer una IA». No és el que decideix el resultat

Sobre atacs executats per agents d'IA ja n'hem escrit dues vegades, inclosa la primera bretxa notificada a Espanya amb aquesta autoria, així que no repetirem l'astorament. El que val la pena d'aquest cas és que contradiu el guió comercial. El DIVD descriu l'atac així: «loud and very messy, with the agent working automated and deciding each next step itself at speed on sloppy logic», sorollós i molt brut, amb l'agent treballant automatitzat i decidint cada pas següent a tota velocitat sobre una lògica barroera. I hi afegeixen una cosa millor: «its overexplaining comments have made our reverse engineering a lot easier», els comentaris en què s'explicava de més els van facilitar molt l'enginyeria inversa.

El 26 de setembre van publicar dues captures censurades dels seus registres: els guions de l'atacant duien notes on l'agent justificava les seves pròpies accions, explicant per què el que feia estava bé i no era phishing de debò. Ho diuen amb sorna i amb raó: és una cosa que un atacant humà no es molestaria a escriure. Per a nosaltres el que va canviar aquí no és el sigil, és el tempo: de segrestar una sessió a tenir root «en segons», diuen ells. El soroll juga a favor del defensor, sí, però només si algú el llegeix. Entre el primer accés i la detecció va passar un dia de calendari, segons les seves pròpies dates —no publiquen hores, així que l'interval real pot ser força menor—. Aquell dia no surt en cap política de pedaços, i és el que marca el sostre de tot el que ve després.

La cadena, i per què la segona meitat continua oberta

El producte pel qual van entrar és Zammad, un sistema de tiquets de suport de codi obert, força comú en departaments d'IT i en empreses de serveis. Són dos errors encadenats, i convé separar-los perquè es comporten diferent:

• CVE-2026-102489 — segrest de sessió que acaba en execució remota de codi com l'usuari zammad. Afecta les versions 6.3.0 a 6.5.4. L'expedient precisa que també hi és a la 7.0.0 fins a la 7.1.3, però allà no és explotable per condicions de l'entorn.
• CVE-2026-102490 — elevació de privilegis local: l'usuari zammad de la màquina passa a root. L'expedient diu que hi és «a totes les versions de Zammad, inclosa l'última alfa», i a la fitxa de versions acota el rang a la v1.5.0 fins a la v7.1.0-alpha.

La nit de l'1 d'octubre, al fòrum oficial, el fabricant va escriure la frase operativa de tot aquest afer: «We have now received the details of CVE-2026-102490 from DIVD, and we are working on it. This issue cannot be exploited remotely on its own. An attacker would already need access to your server». És a dir: el segon error és l'anell dos. Per si sol no és una porta des d'internet; necessita que algú ja sigui dins de la màquina. I l'anell u sí que té remei avui.

El camp diu «Available» i el paràgraf diu «estan treballant en una correcció»

Hi ha un detall de l'expedient del qual ningú no està parlant. L'expedient de les dues vulnerabilitats té una capçalera amb camps estructurats, dels que s'enganxen en un full de càlcul o s'empassen per API. Diuen això: Recommendation: Upgrade to Zammad version 7. Patch status: Available. Workaround: N/A. Unes línies més avall, en prosa, el mateix document diu: «We have reported the vulnerability to Zammad who are working on a fix» —hem reportat la vulnerabilitat a Zammad, que estan treballant en una correcció—.

El camp encaixa amb el primer error, que sí que té versió on anar. El paràgraf està escrit en singular, «the vulnerability», i no diu de quin dels dos parla. Aquesta ambigüitat és just el problema, i no ens toca a nosaltres resoldre-la. El que sí que diem és que no és culpa de qui escriu l'avís, sinó de la forma de l'avís: no hi ha un lloc on càpiga «la meitat d'això està arreglada i l'altra meitat no». I si el teu procés de gestió de vulnerabilitats consumeix el camp i no el paràgraf —que és exactament el que fa un procés automatitzat— això entra com a tancat. Ho hem explicat abans amb un altre producte: quan «mitigat» acabava significant apagar i encendre, l'estat del butlletí i l'estat de la teva màquina tampoc no eren la mateixa cosa.

Dos documents públics que no coincideixen, i tots dos són veritat

L'1 d'octubre el fabricant va publicar la seva pròpia versió. Sobre el primer error: el van rebre l'agost del 2026, només és explotable a la 6.5 i anteriors per l'entorn d'execució que fan servir aquestes versions, la 7.0 i posteriors no estan afectades, i tot i així van endurir el codi i el canvi va a la 7.2.0. Sobre el segon: «Up to today, DIVD has not given us any technical details about this vulnerability. We cannot verify a claim we have not been shown» —fins avui, el DIVD no ens ha donat cap detall tècnic; no podem verificar una afirmació que no ens han ensenyat—. I hi afegeixen una queixa de procés que no amaguen: es va publicar un identificador CVE d'una vulnerabilitat que no els havien explicat, i conclouen que «We do not consider this a responsible way to handle vulnerabilities».

No arbitrarem aquest desacord. Les dues parts han publicat amb el seu nom, amb dates i per escrit, que ja és més del que fa gairebé tothom. El que ens interessa és el que li passa a qui té un Zammad funcionant: l'1 d'octubre havia de decidir amb dos documents sobre la taula que no deien el mateix —i els dos dies anteriors, amb un de sol—. Un li deia que actualitzés a la versió 7 o que l'apagués. L'altre li deia que la versió 7 no està afectada per l'error remot i que de l'altre no se'n pot confirmar ni l'abast. Cap dels dos no mentia, i la decisió no es podia ajornar fins que es posessin d'acord. Això no és un cas rar: és com arriben els avisos gairebé sempre, d'un en un, amb dies de diferència i escrits per gent amb informació diferent.

El que et queda quan el pedaç no existeix

El pedaç és una de les maneres de tornar inservible una vulnerabilitat. Ni és l'única ni, moltes vegades, la més ràpida. Les altres no depenen del fabricant, depenen de tu. Pots trencar la cadena per l'altre anell, que és exactament el que passa aquí: si el remot deixa de funcionar, el local es queda sense manera de començar. Pots treure exposició: treure la instància d'internet, deixar-la darrere la VPN, limitar-la a orígens coneguts. Pots reduir el radi de dany, que és el que va decidir l'abast d'aquest incident —el mateix DIVD ho escriu: «Thanks to proper network segmentation and the actions of our IT and Incident Response Team after detection, we were able to stop the attackers from going deeper into our systems and network»—. I pots pujar la vigilància sobre aquell sistema concret mentre duri l'excepció, en lloc de sobre tot alhora.

Ho diem sempre i aquí es veu amb una claredat incòmoda: la fallada és inevitable, l'avaria és una decisió de disseny. El DIVD va tenir la fallada el 21 de setembre i no la va poder evitar, perquè no hi havia pedaç per aplicar. Dany n'hi va haver, i convé no maquillar-ho: van sortir dades de voluntaris i continuen investigant indicis de compromís; ells ho escriuen així, «Unfortunately some of the damage was already done». El que no va arribar a passar és l'avaria sencera, algú passejant-se per tota la xarxa. I la diferència entre una cosa i l'altra no la va marcar un pedaç: la van marcar decisions d'arquitectura preses mesos abans i un equip que estava mirant. Aquesta és la part que es compra amb temps i amb diners, no amb pressa el dia de l'avís. Nosaltres hi treballem assajant el pla de continuïtat en comptes d'arxivar-lo, que és l'única manera de saber si la segmentació que vas dibuixar existeix de debò.

El paràgraf que li falta a la teva política

Gairebé totes les polítiques de seguretat que llegim tenen terminis de pedaç per criticitat. Gairebé cap no té redactat què passa quan el pedaç no existeix, i aquest és el cas que de debò et tocarà. Així doncs, en comptes de donar-te una altra llista de preguntes, et donem el text. Copia'l, canvia-li els terminis pels teus i fica'l al document:

«Quan una vulnerabilitat amb explotació coneguda afecti un sistema per al qual el fabricant no hagi publicat correcció, el responsable de sistemes obrirà una excepció per escrit en un termini de 24 hores des que se'n tingui constància. L'excepció anomenarà: el sistema afectat i el seu responsable de negoci; la mesura de contenció que s'aplica mentre no hi hagi correcció, triada entre retirar l'accés des d'internet, restringir-lo a orígens coneguts, aïllar el sistema de la resta de la xarxa o apagar-lo; el risc residual que s'accepta i qui l'accepta, amb nom i càrrec; la vigilància addicional que s'activa sobre aquell sistema mentre duri; i la data de revisió, que no excedirà els set dies naturals. L'excepció caduca sola en aquella data: si ningú no la renova per escrit, s'aplica automàticament la mesura més restrictiva de les previstes.»

Les dues clàusules que fan la feina són les que semblen burocràtiques. Que caduqui sola impedeix el que passa sempre: l'excepció s'obre amb la millor intenció al setembre i continua oberta al març perquè ningú no se'n recorda de tancar-la; si el silenci estreny en comptes d'afluixar, algú ho revisa. I el nom i el càrrec no hi són per buscar culpables: hi són perquè la decisió existeixi. Un risc que accepta «l'empresa» no l'accepta ningú, i quan l'auditor —o el client que et va enviar el seu qüestionari de proveïdor— pregunti per què aquell sistema va estar sis dels set dies que permet la clàusula amb un error conegut, la diferència entre un incident de governança i una anècdota ben gestionada és aquell paràgraf signat.

El que no estem dient

No és un argument contra el programari lliure. Zammad és obert, i la nostra pròpia infraestructura corre sobre Proxmox, Ceph, Zabbix i NetBox; si volguéssim vendre aquest discurs hauríem de començar per desmuntar casa nostra. El programari de pagament té exactament la mateixa avaria amb un altre nom: es diu fi de suport, o «corregit a la següent versió major, que es factura a part». La pregunta «què faig mentre no hi ha correcció?» és neutral respecte a la llicència.

Tampoc no et diem que apaguis el teu sistema de tiquets. Si ets a la 7.2.0 i la instància no està publicada a internet, la teva situació no s'assembla a la del titular —encara que l'elevació local continuï sense correcció publicada—, i actuar com si s'hi assemblés també costa diners. I si la teva empresa té quinze persones, no et cal un comitè de riscos ni una eina: et cal un paràgraf en un document i una persona disposada a signar-lo. El conflicte d'interès, per davant: no revenem Zammad ni cap plataforma concreta, així que aquesta recomanació no ens la paga ningú; escriure la política, passar l'inventari i muntar la segmentació sí que ho facturem.

Una última cosa, per honestedat amb qui ho està passant malament aquests dies. El DIVD va publicar el seu propi desastre amb dates, amb el que sabia i amb el que no, i van escriure per què: «We don't wait until we have every answer, because that doesn't make digital society any safer». És moltíssim més del que fa la majoria d'empreses a qui els passa això. Que l'expedient que ens ha servit per escriure aquest article existeixi és, precisament, mèrit seu.

Fonts (verificades el 2 d’octubre del 2026): la cronologia, les cinc declaracions públiques i totes les cites del DIVD surten de l’expedient DIVD-2026-00014, «When, not if…» (última modificació 01-10-2026, 22:30 CEST). Els rangs de versions, els camps Recommendation, Patch status: Available i Workaround: N/A i la frase «who are working on a fix», de l’expedient DIVD-2026-00015 (01-10-2026, 13:27 CEST). La posició del fabricant i les seves cites, del comunicat oficial de Zammad a la seva comunitat (01-10-2026). La lectura del camp Patch status enfront del paràgraf en prosa, l’argument del tempo enfront del sigil i el paràgraf de política amb les seves dues clàusules són nostres, no d’aquelles fonts.