PHP: fallo crítico 9.2 amenaza al 69% de la web

PHP: el fallo crítico que obligó a apagar webs oficiales

Dos vulnerabilidades en PHP —registradas como CVE-2026-109618 y CVE-2026-109619 y valoradas con 9,2 sobre 10 en la escala CVSS v4.0— han llevado a administraciones de Países Bajos, Finlandia, Dinamarca y Francia a retirar temporalmente sus webs y servicios públicos de Internet. No es una caída accidental: es una decisión deliberada para dejar de estar expuestos mientras se aplican las correcciones.

Si tu producto corre sobre WordPress, WooCommerce, Laravel, Drupal o Joomla, tu infraestructura está dentro del radio de este incidente. Según W3Techs, PHP está presente en el 69,3% de las webs cuyo lenguaje del lado del servidor puede identificarse, y WordPress alimenta el 39,6% de todas las webs del mundo. Es uno de los fallos de infraestructura con mayor superficie de exposición de los últimos años, y afecta tanto a una startup de cinco personas como a un ministerio.

¿Qué hacen exactamente estas vulnerabilidades?

El NCSC británico explica que el problema está en cómo PHP gestiona los errores de memoria durante una petición. Una condición de falta de memoria puede interrumpir el proceso mientras los datos internos de la solicitud están apenas parcialmente inicializados: la limpieza posterior trata entonces datos inválidos como si fueran válidos.

• CVE-2026-109618: el manejo de una situación de memoria agotada interrumpe PHP con los datos internos de la petición a medio inicializar.
• CVE-2026-109619: el estado interno asociado a una petición sobrevive después de que su memoria se haya liberado, de modo que una petición posterior atendida por el mismo proceso puede reutilizar ese estado obsoleto.

La diferencia con un error que simplemente tumba una web es clave: aquí el riesgo no es que el sitio deje de responder, sino que el servidor acabe ejecutando instrucciones que nadie autorizó, sin necesidad de iniciar sesión previamente. Según CERT-EU, el fallo podría afectar a todas las versiones de PHP desde la 5 en adelante, lo que incluye instalaciones que llevan años sin soporte.

Cronología: de una filtración a un parche de emergencia

El detalle incómodo de este incidente es cómo se aceleró. Infosecurity Magazine reportó que los identificadores de ambas vulnerabilidades se filtraron el 20 de octubre en un foro, un día antes de la divulgación prevista, junto con la afirmación de que eran fallos de severidad máxima (CVSS 10.0). El equipo de seguridad de PHP había asignado finalmente 9,2, y advirtió que adelantaría los parches si los detalles se hacían públicos o aparecían señales de explotación real.

El equipo publicó las correcciones para las ramas 8.2, 8.3, 8.4 y 8.5. Según CyberScoop, los parches llegaron como las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El matiz importante: que la solución técnica exista no significa que ya esté aplicada en tu servidor.

¿Ya hay ataques explotando el fallo?

Sí, al menos intentos dirigidos. Dane Knecht, CTO de Cloudflare, confirmó que la compañía estaba viendo ataques tempranos y desplegó reglas de firewall para todos sus clientes, incluidos los planes gratuitos, aunque describió esa protección como un parche temporal. La firma watchTowr dijo haber reproducido uno de los fallos, y según CyberScoop circula código que dice explotarlos, sin verificar y en ocasiones con malware dentro.

Conviene separar dos escenarios que suelen mezclarse en redes: que existan intentos contra sistemas vulnerables no equivale a que las administraciones que apagaron sus webs hayan sido comprometidas. Por ahora no hay pruebas públicas de que esos apagados respondan a intrusiones confirmadas. Lo que sí está confirmado es la actividad de ataque y la cautela oficial.

¿Por qué la fragmentación es el verdadero problema?

Parchear sería sencillo si todo el mundo estuviera en una versión reciente. No es el caso. CyberScoop, citando datos de VirusTotal, señala que entre los servidores que declaran su versión, unos 758.000 corren ramas de la 5.4 a la 8.1, ya sin actualizaciones de seguridad, frente a 272.000 en ramas soportadas. Investigadores estimaron más de 1,3 millones de hosts expuestos a Internet potencialmente vulnerables, y una búsqueda en Shodan contó alrededor de 1,9 millones.

A eso se suma el segundo problema estructural: PHP no lo mantiene el dueño de la web, sino el administrador del servidor o el proveedor de hosting. Si tu sitio vive en un hosting compartido o gestionado, tú no decides cuándo se aplica el parche. Esa dependencia explica por qué varias organizaciones europeas siguieron retirando servicios incluso después de que la solución técnica estuviera disponible.

El historial tampoco ayuda: el catálogo de vulnerabilidades explotadas (KEV) de la CISA lista tres fallos en PHP, dos de ellos usados en campañas de ransomware, según CyberScoop.

Qué significa esto para tu startup

Si eres founder o CTO, esto no es una noticia de ciberseguridad ajena: es una tarea de infraestructura con reloj. Un RCE sin autenticación en el servidor que sirve tu producto es lo más parecido a entregar las llaves. Y si vendes a empresas, tus clientes empezarán a preguntar por tu exposición en las próximas horas.

Acciones concretas para hoy:

• Haz inventario, no supongas. El NCSC pide identificar todas las instalaciones de PHP en la infraestructura, priorizando las que están expuestas a Internet, y advierte de no limitar la búsqueda a versiones antiguas: cualquier versión puede estar afectada. Incluye también aparatos y servicios de terceros que empaquetan PHP como componente. La agencia neerlandesa NCSC-NL publicó una lista de productos con dependencia de PHP potencialmente afectados que sirve como punto de partida.
• Actualiza y verifica la versión real. No basta con pedir el parche a tu proveedor: confirma la versión que responde en producción, porque muchas instalaciones se actualizan sólo en el panel y no en el contenedor que atiende tráfico.
• Si no puedes parchear, aplica las mitigaciones temporales del equipo de PHP y, si tampoco alcanzan, valora sacar el servicio de línea. Es exactamente la recomendación del NCSC y la línea que siguió NSA Cyber: un servicio caído unas horas es mejor que un servidor tomado.
• Si parcheas tarde, revisa indicios de compromiso antes de subir la actualización. El propio NCSC lo advierte: busca puertas traseras que un atacante haya podido instalar, y si no tienes esa capacidad interna, recurre a un proveedor especializado en respuesta a incidentes.
• Usa el escudo temporal mientras cierras el hueco. Las reglas de firewall que Cloudflare desplegó a todos sus clientes, incluidos los gratuitos, bloquean vectores conocidos. Sirven de red de seguridad, no de solución.

Más allá del apagón, hay una lección de producto: si tu negocio depende de un lenguaje que corre en servidores que no controlas, tu plan de contingencia real es saber quién parchea y en cuánto tiempo se compromete por contrato. Para muchas startups hispanohablantes ese nombre está en un ticket de soporte de hosting, y ese es justo el eslabón que falla cuando llega una emergencia.

Conclusión

PHP sostiene la mayor parte de la web y ahora carga con dos fallos de severidad crítica que ya tienen parche, versiones corregidas identificadas y evidencias de intentos de explotación. La parte técnica está resuelta; la parte operativa, no. Entre la filtración del 20 de octubre y los parches publicados el 21 de octubre hubo una ventana en la que cualquiera con los detalles pudo preparar sus intentos.

La medida que más dice sobre la gravedad del asunto es también la menos habitual: gobiernos europeos eligiendo apagar webs públicas en lugar de arriesgarse. Si una administración con equipo de seguridad dedicado prefiere desconectar, una startup sin ese equipo debería revisar su inventario de PHP hoy, empezando por lo que está expuesto a Internet. Actualizar es rápido una vez que sabes dónde está el problema; el problema suele ser no saberlo.

Fuentes

• Xataka: Un fallo crítico en PHP pone en jaque a medio Internet (fuente original)
• NCSC: Critical security issue affecting PHP
• CyberScoop: PHP to release emergency fixes for 2 critical vulnerabilities
• Infosecurity Magazine: Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches
• Websites go offline after critical security glitch