Tu política de parcheo no contempla que no haya parche

Tu política de seguridad dice algo parecido a «las vulnerabilidades críticas se corrigen en 72 horas». Léela otra vez pensando en el caso en que el parche no existe. No es un supuesto de laboratorio: el 21 de septiembre entraron en la organización holandesa que se dedica a avisar a los demás de que parcheen, y once días después, el segundo de los dos fallos que usaron para entrar sigue sin corrección publicada. El fabricante dijo la noche del 1 de octubre que ya tiene los detalles y que está en ello. Esa frase, «estamos en ello», es la que tu política no sabe procesar.

Lo que pasó, con las fechas del que lo sufrió

El DIVD —Dutch Institute for Vulnerability Disclosure— es una fundación de voluntarios que rastrea internet buscando sistemas vulnerables y avisa a sus dueños. El 29 de septiembre publicaron el expediente del incidente que ellos mismos acababan de sufrir. Al expediente le pusieron un título que no es casual: «When, not if…», cuándo, no si.

La cronología es suya, no nuestra. 21 de septiembre: primer acceso del atacante. 22 de septiembre: se dan cuenta, bloquean el acceso a todos los sistemas del centro de datos y montan equipo de respuesta a incidentes con una empresa externa, Merlon Security. 24 de septiembre: reportan la vulnerabilidad al fabricante, avisan a socios y afectados y hacen la primera declaración pública. 26 de septiembre: abren un segundo expediente para escanear instancias vulnerables en internet y avisar a sus dueños. 29 de septiembre: publican el expediente. 30 de septiembre: explican que entraron por dos días cero. 1 de octubre: publican qué datos salieron.

La primera declaración empieza con dos palabras: «We got hacked». Y cierra con una regla de trabajo que merece la pena robar: «Until proven otherwise, we handle this as a worst case scenario and assume breach» —hasta que se demuestre lo contrario, lo tratamos como el peor escenario y asumimos que hubo brecha—. Notificaron a la autoridad de protección de datos holandesa, al NCSC-NL y hablaron con la policía. El 1 de octubre contaron la parte incómoda: salieron datos de voluntarios, direcciones de correo del DIVD y posiblemente datos de contacto. Y escribieron ellos mismos la consecuencia, que es la que de verdad importa: ahora es más fácil que alguien se haga pasar por un voluntario del DIVD.

El titular es «lo hizo una IA». No es lo que decide el resultado

Sobre ataques ejecutados por agentes de IA ya hemos escrito dos veces, incluida la primera brecha notificada en España con esa autoría, así que no vamos a repetir el asombro. Lo que merece la pena de este caso es que contradice el guion comercial. El DIVD describe el ataque así: «loud and very messy, with the agent working automated and deciding each next step itself at speed on sloppy logic», ruidoso y muy sucio, con el agente trabajando automatizado y decidiendo cada paso siguiente a toda velocidad sobre una lógica chapucera. Y añaden algo mejor: «its overexplaining comments have made our reverse engineering a lot easier», los comentarios en los que se explicaba de más les facilitaron mucho la ingeniería inversa.

El 26 de septiembre publicaron dos capturas censuradas de sus registros: los guiones del atacante llevaban notas donde el agente justificaba sus propias acciones, explicando por qué lo que hacía estaba bien y no era phishing de verdad. Lo dicen con sorna y con razón: es algo que un atacante humano no se molestaría en escribir. Para nosotros lo que cambió aquí no es el sigilo, es el tempo: de secuestrar una sesión a tener root «en segundos», dicen ellos. El ruido juega a favor del defensor, sí, pero solo si alguien lo lee. Entre el primer acceso y la detección pasó un día de calendario, según sus propias fechas —no publican horas, así que el intervalo real puede ser bastante menor—. Ese día no sale en ninguna política de parcheo, y es el que marca el techo de todo lo que viene después.

La cadena, y por qué la segunda mitad sigue abierta

El producto por el que entraron es Zammad, un sistema de tickets de soporte de código abierto, bastante común en departamentos de IT y en empresas de servicios. Son dos fallos encadenados, y conviene separarlos porque se comportan distinto:

• CVE-2026-102489 — secuestro de sesión que acaba en ejecución remota de código como el usuario zammad. Afecta a las versiones 6.3.0 a 6.5.4. El expediente precisa que también está presente en la 7.0.0 a la 7.1.3, pero ahí no es explotable por condiciones del entorno.
• CVE-2026-102490 — elevación de privilegios local: el usuario zammad de la máquina pasa a root. El expediente dice que está «en todas las versiones de Zammad, incluida la última alfa», y en la ficha de versiones acota el rango a la v1.5.0 hasta la v7.1.0-alpha.

La noche del 1 de octubre, en el foro oficial, el fabricante escribió la frase operativa de todo este asunto: «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». Es decir: el segundo fallo es el eslabón dos. Por sí solo no es una puerta desde internet; necesita que alguien ya esté dentro de la máquina. Y el eslabón uno sí tiene remedio hoy.

El campo dice «Available» y el párrafo dice «están trabajando en una corrección»

Hay un detalle del expediente del que nadie está hablando. El expediente de las dos vulnerabilidades tiene una cabecera con campos estructurados, de los que se pegan en una hoja de cálculo o se tragan por API. Dicen esto: Recommendation: Upgrade to Zammad version 7. Patch status: Available. Workaround: N/A. Unas líneas más abajo, en prosa, el mismo documento dice: «We have reported the vulnerability to Zammad who are working on a fix» —hemos reportado la vulnerabilidad a Zammad, que están trabajando en una corrección—.

El campo encaja con el primer fallo, que sí tiene versión a la que ir. El párrafo está escrito en singular, «the vulnerability», y no dice de cuál de los dos habla. Esa ambigüedad es justo el problema, y no nos toca a nosotros resolverla. Lo que sí decimos es que no es culpa de quien escribe el aviso, sino de la forma del aviso: no hay un sitio donde quepa «la mitad de esto está arreglada y la otra mitad no». Y si tu proceso de gestión de vulnerabilidades consume el campo y no el párrafo —que es exactamente lo que hace un proceso automatizado— esto entra como cerrado. Lo hemos contado antes con otro producto: cuando «mitigado» acababa significando apagar y encender, el estado del boletín y el estado de tu máquina tampoco eran la misma cosa.

Dos documentos públicos que no coinciden, y los dos son verdad

El 1 de octubre el fabricante publicó su propia versión. Sobre el primer fallo: lo recibieron en agosto de 2026, solo es explotable en la 6.5 y anteriores por el entorno de ejecución que usan esas versiones, la 7.0 y posteriores no están afectadas, y aun así endurecieron el código y el cambio va en la 7.2.0. Sobre el segundo: «Up to today, DIVD has not given us any technical details about this vulnerability. We cannot verify a claim we have not been shown» —hasta hoy, el DIVD no nos ha dado ningún detalle técnico; no podemos verificar una afirmación que no nos han enseñado—. Y añaden una queja de proceso que no esconden: se publicó un identificador CVE de una vulnerabilidad que no les habían contado, y concluyen que «We do not consider this a responsible way to handle vulnerabilities».

No vamos a arbitrar ese desacuerdo. Las dos partes han publicado con su nombre, con fechas y por escrito, que ya es más de lo que hace casi todo el mundo. Lo que nos interesa es lo que le pasa al que tiene un Zammad corriendo: el 1 de octubre tenía que decidir con dos documentos sobre la mesa que no decían lo mismo —y los dos días anteriores, con uno solo—. Uno le decía que actualizara a la versión 7 o lo apagara. El otro le decía que la versión 7 no está afectada por el fallo remoto y que del otro no se puede confirmar ni el alcance. Ninguno de los dos estaba mintiendo, y la decisión no se podía aplazar hasta que se pusieran de acuerdo. Eso no es un caso raro: es cómo llegan los avisos casi siempre, de uno en uno, con días de diferencia y escritos por gente con información distinta.

Lo que te queda cuando el parche no existe

El parche es una de las maneras de volver inservible una vulnerabilidad. Ni es la única ni, muchas veces, la más rápida. Las otras no dependen del fabricante, dependen de ti. Puedes romper la cadena por el otro eslabón, que es exactamente lo que ocurre aquí: si el remoto deja de funcionar, el local se queda sin manera de empezar. Puedes quitar exposición: sacar la instancia de internet, dejarla detrás de la VPN, limitarla a orígenes conocidos. Puedes reducir el radio de daño, que es lo que decidió el alcance de este incidente —el propio DIVD lo escribe: «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»—. Y puedes subir la vigilancia sobre ese sistema concreto mientras dure la excepción, en lugar de sobre todo a la vez.

Lo decimos siempre y aquí se ve con una claridad incómoda: el fallo es inevitable, la avería es una decisión de diseño. El DIVD tuvo el fallo el 21 de septiembre y no pudo evitarlo, porque no había parche que aplicar. Daño hubo, y conviene no maquillarlo: salieron datos de voluntarios y siguen investigando indicios de compromiso; ellos lo escriben así, «Unfortunately some of the damage was already done». Lo que no llegó a ocurrir es la avería entera, alguien paseándose por toda la red. Y la diferencia entre una cosa y la otra no la marcó un parche: la marcaron decisiones de arquitectura tomadas meses antes y un equipo que estaba mirando. Esa es la parte que se compra con tiempo y con dinero, no con prisa el día del aviso. Nosotros lo trabajamos ensayando el plan de continuidad en vez de archivarlo, que es la única manera de saber si la segmentación que dibujaste existe de verdad.

El párrafo que le falta a tu política

Casi todas las políticas de seguridad que leemos tienen plazos de parcheo por criticidad. Casi ninguna tiene redactado qué pasa cuando el parche no existe, y ese es el caso que de verdad te va a tocar. Así que, en vez de darte otra lista de preguntas, te damos el texto. Cópialo, cámbiale los plazos a los tuyos y mételo en el documento:

«Cuando una vulnerabilidad con explotación conocida afecte a un sistema para el que el fabricante no haya publicado corrección, el responsable de sistemas abrirá una excepción por escrito en un plazo de 24 horas desde que se tenga constancia. La excepción nombrará: el sistema afectado y su responsable de negocio; la medida de contención que se aplica mientras no haya corrección, elegida entre retirar el acceso desde internet, restringirlo a orígenes conocidos, aislar el sistema del resto de la red o apagarlo; el riesgo residual que se acepta y quién lo acepta, con nombre y cargo; la vigilancia adicional que se activa sobre ese sistema mientras dure; y la fecha de revisión, que no excederá de siete días naturales. La excepción caduca sola en esa fecha: si nadie la renueva por escrito, se aplica automáticamente la medida más restrictiva de las previstas.»

Las dos cláusulas que hacen el trabajo son las que parecen burocráticas. Que caduque sola impide lo que pasa siempre: la excepción se abre con la mejor intención en septiembre y sigue abierta en marzo porque nadie se acuerda de cerrarla; si el silencio aprieta en vez de aflojar, alguien revisa. Y el nombre y el cargo no están ahí para buscar culpables: están para que la decisión exista. Un riesgo que acepta «la empresa» no lo acepta nadie, y cuando el auditor —o el cliente que te mandó su cuestionario de proveedor— pregunte por qué ese sistema estuvo seis de los siete días que permite la cláusula con un fallo conocido, la diferencia entre un incidente de gobernanza y una anécdota bien gestionada es ese párrafo firmado.

Lo que no estamos diciendo

No es un argumento contra el software libre. Zammad es abierto, y nuestra propia infraestructura corre sobre Proxmox, Ceph, Zabbix y NetBox; si quisiéramos vender ese discurso tendríamos que empezar por desmontar nuestra casa. El software de pago tiene exactamente la misma avería con otro nombre: se llama fin de soporte, o «corregido en la siguiente versión mayor, que se factura aparte». La pregunta «¿qué hago mientras no hay corrección?» es neutral respecto a la licencia.

Tampoco te estamos diciendo que apagues tu sistema de tickets. Si estás en la 7.2.0 y la instancia no está publicada en internet, tu situación no se parece a la del titular —aunque la elevación local siga sin corrección publicada—, y actuar como si se pareciera también cuesta dinero. Y si tu empresa tiene quince personas, no te hace falta un comité de riesgos ni una herramienta: te hace falta un párrafo en un documento y una persona dispuesta a firmarlo. El conflicto de interés, por delante: no revendemos Zammad ni ninguna plataforma concreta, así que esta recomendación no nos la paga nadie; escribir la política, pasar el inventario y montar la segmentación sí lo facturamos.

Una última cosa, por honestidad con quien lo está pasando mal estos días. El DIVD publicó su propio desastre con fechas, con lo que sabía y con lo que no, y escribieron por qué: «We don't wait until we have every answer, because that doesn't make digital society any safer». Es muchísimo más de lo que hace la mayoría de las empresas a las que les pasa esto. Que el expediente que nos ha servido para escribir este artículo exista es, precisamente, mérito suyo.

Fuentes (verificadas el 2 de octubre de 2026): la cronología, las cinco declaraciones públicas y todas las citas del DIVD salen del expediente DIVD-2026-00014, «When, not if…» (última modificación 01-10-2026, 22:30 CEST). Los rangos de versiones, los campos Recommendation, Patch status: Available y Workaround: N/A y la frase «who are working on a fix», del expediente DIVD-2026-00015 (01-10-2026, 13:27 CEST). La posición del fabricante y sus citas, del comunicado oficial de Zammad en su comunidad (01-10-2026). La lectura del campo Patch status frente al párrafo en prosa, el argumento del tempo frente al sigilo y el párrafo de política con sus dos cláusulas son nuestros, no de esas fuentes.