Cloudflare lanza Zero Wire: fichas gratuitas para saber qué vulnerabilidad crítica te toca parchar primero

Cloudflare presentó el 3 de noviembre de 2026 Zero Wire, una sección nueva de Cloudflare Radar dedicada a vulnerabilidades críticas de Internet. No es otra base de datos de CVE: es un "servicio de cable" al estilo de las agencias de noticias, con fichas cortas que explican qué pasó, quién debe revisar, qué hacer ya y dónde está la evidencia. Es pública, gratuita y sirve aunque no seas cliente de Cloudflare. Importa porque el ritmo de vulnerabilidades graves no está bajando: en lo que va de octubre y noviembre ya tuvimos php2shell en PHP, un use-after-free en el TCP de Linux y node2shell en Brotli, y quien administra servidores necesita separar el ruido de lo urgente sin leerse diez avisos distintos antes del desayuno.

Por qué Cloudflare dice que hace falta

El anuncio, firmado por Daniele Molteni y Celso Martinho, arranca con una escena conocida para cualquiera que opere infraestructura: son las 7 de la mañana, sale una vulnerabilidad crítica y el equipo se pone a comparar avisos de fabricantes, leer investigaciones y revisar qué sistemas corren el software afectado, mientras la empresa pregunta lo de siempre: ¿nos pega y qué estamos haciendo? Y antes de terminar, llega otra.

Cloudflare atribuye parte de esa presión a la inteligencia artificial. Según el post, la IA está cambiando "el volumen y la velocidad" con que se descubren vulnerabilidades críticas, porque puede analizar bases de código enormes y encontrar fallas escondidas durante años. No es teoría: el propio php2shell fue divulgado de forma coordinada por Calif.io, Wiz, OpenAI y Quarkslab, de acuerdo con Cloudflare.

Qué es exactamente Zero Wire

Zero Wire vive dentro de Radar, en la sección de seguridad. Cloudflare aclara que no pretende catalogar todos los CVE, sino complementar los avisos de los fabricantes y las bases de datos de vulnerabilidades. Su foco son las fallas críticas en software expuesto a Internet: aplicaciones web, los runtimes y librerías de los que dependen, y servicios publicados, que es justo donde un proxy puede ayudar a frenar la explotación.

Un detalle que vale la pena: tener una regla del WAF de Cloudflare no es requisito para que una vulnerabilidad entre. Algunas fallas necesitan parches del fabricante o cambios que el tráfico web no deja ver, y aun así se documentan.

La portada separa las fichas en dos bandejas:

Needs attention: fallas con explotación conocida, investigación en curso o guía que todavía cambia.
Reference: fichas cuya guía ya se estabilizó. Cloudflare insiste en que pasar a esta bandeja no significa que todo el mundo ya haya parchado.

Cada tarjeta trae un estado y una fecha de última revisión. Al momento de escribir esto, la bandeja urgente tenía cinco fichas revisadas entre el 19 de octubre y el 2 de noviembre: el use-after-free del TCP de IPv4 en Linux (CVE-2026-98432), php2shell, el compromiso de certificados intermedios de eMudhra, node2shell (CVE-2026-111497, en el decodificador Brotli) y la ejecución de comandos en Citrix NetScaler (CVE-2026-88771). En referencia aparecía la inyección SQL y RCE de WordPress. También hay un feed RSS para seguir altas y cambios.

Diagrama: anatomía de un briefing de Zero Wire, con sus seis secciones (tarjeta y estado, overview, qué hacer ya, prompt para tu agente, cobertura de Cloudflare, evidencia y cronología) y las bandejas Needs attention y Reference

Cómo está armada cada ficha

La de php2shell sirve para ver cómo funciona en la práctica. La estructura es la misma en todas:

Sección	Qué responde
Overview	Qué pasó, por qué importa y qué equipos deben investigar
What to do now	Los siguientes pasos concretos
Prompt para un agente	Cómo evaluar tu propia infraestructura con IA, solo lectura
Cobertura de Cloudflare	Si existen reglas WAF y cómo se configuran
Evidencia y fuentes	Aviso del fabricante, registros CVE, CISA KEV, tráfico observado
Cronología	Qué cambió y cuándo

En el caso de php2shell, la ficha deja claro algo que muchos todavía confunden: son fallas del runtime de PHP (CVE-2026-109618 y CVE-2026-109619), así que actualizar WordPress, Magento o un plugin no arregla nada. Remite al aviso oficial de PHP, que pide actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y menciona como expuestas todas las instalaciones que atienden peticiones web: PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. La ficha también separa un tercer CVE relacionado, el CVE-2026-115560, que solo aplica con una configuración de sesiones poco común y para el que PHP recomienda desactivar session.upload_progress hasta su siguiente versión de mantenimiento.

La cronología resume en cinco renglones lo que pasó del 21 al 30 de octubre, incluido que CISA metió los dos CVE originales a su catálogo de vulnerabilidades explotadas el 26 de octubre. Para quien regresa a la ficha, eso ahorra reconstruir la historia desde cero.

El prompt para tu agente de IA

La parte más novedosa es un prompt listo para copiar en un agente con acceso a tu infraestructura. En la ficha de php2shell, el texto le pide al agente una evaluación de solo lectura: no mandar payloads de explotación, no provocar agotamiento de memoria y no cambiar nada. Le pide verificar los avisos vigentes, inventariar PHP en hosts, contenedores, Kubernetes e imágenes, revisar el runtime que de verdad atiende peticiones (no solo la versión de la CLI), evaluar cada CVE por separado y reportar el WAF aparte del estado del parche. El resultado esperado es una tabla por activo con lo afectado, lo corregido y lo desconocido.

Cloudflare aclara que copiar el prompt no escanea ni modifica nada por sí mismo. Mi lectura: es un buen molde aunque no uses agentes, porque obliga a separar tres preguntas que se mezclan en cada crisis: ¿estoy afectado?, ¿ya parché? y ¿me están atacando?

Lo que Zero Wire no hace

El anuncio es honesto con sus límites, y conviene tenerlos presentes:

El WAF no sustituye al parche. Cloudflare lo repite: una regla es un control compensatorio para el tráfico que cubre. Puede evitar que un dato expuesto llegue al atacante, pero no deshace lo que ya pasó en el servidor de origen.
Ver ataques no prueba compromisos. Las gráficas de peticiones que coinciden con reglas WAF no cuentan sistemas comprometidos ni exploits exitosos. Y que Cloudflare no vea intentos en su red no significa que no existan en otro lado.
El estado de la tarjeta no es un veredicto sobre tu entorno. Explotación conocida, investigación abierta y parche disponible describen cosas distintas.
Los enlaces al dashboard no activan nada. Llevan a la configuración de reglas para que revises si estás protegido; no habilitan reglas ni verifican despliegues.

Y uno que el post no dice pero hay que decir: es una selección editorial de Cloudflare, con su propia telemetría y sus propios productos en la sección de cobertura. No reemplaza suscribirte a los avisos de seguridad de tu distribución, de tu CMS y de tu runtime. Si usas Drupal, por ejemplo, los avisos de seguridad de Drupal siguen siendo la fuente que manda.

Qué hacer con esto

Si administras servidores web, Zero Wire sirve como filtro de primera línea: mete su RSS a tu lector o a tu canal de alertas, y cuando aparezca algo en "Needs attention" que toque tu stack, ve directo al aviso del fabricante que la ficha enlaza. Si tu sitio pasa por Cloudflare, revisa en Security > Security Rules que las reglas administradas estén en modo bloqueo, pero no confundas eso con estar parchado.

Mi lectura final: el valor no está en que Cloudflare descubra vulnerabilidades, sino en que las ordena con una disciplina que muchos equipos no tienen a las 7 de la mañana: qué está confirmado, qué no se sabe y quién tiene que moverse. Que sea gratis y público hace que no haya excusa para no tenerlo en el radar.