Dos fallos de PHP sin autenticación: 70% de la web contrarreloj

Alrededor del 70 por ciento de la web necesitó esta mañana un cambio de motor, y la mayoría ni sabía que era suya el coche. PHP publicó correcciones de emergencia para dos fallos críticos en el propio runtime del lenguaje —CVE-2026-109618 y CVE-2026-109619, apodados colectivamente PHP2Shell— que permiten a un atacante sin cuenta, sin credenciales y sin necesidad de un correo de phishing ejecutar código en un servidor vulnerable. Ya existen exploits funcionales y los sensores ya registran intentos de explotación. Y como los fallos están en PHP y no en WordPress, Drupal, Joomla o Magento, una aplicación totalmente parcheada que corre sobre un runtime sin parchear sigue siendo presa fácil.

La clave está en el alcance. Según Krebs on Security, Censys contabilizó recientemente unos 2,58 millones de hosts expuestos a internet y 54,9 millones de propiedades web que ejecutan PHP, y los investigadores de Wiz afirman que todas las versiones de PHP publicadas en la última década se ven afectadas por al menos uno de los dos fallos. Las ramas vulnerables se remontan a PHP 5.4. Las correcciones son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Todo lo demás es una decisión sobre cuánto riesgo estás dispuesto a financiar.

Una década dormidos, un día en llamas: la cronología

Empecemos por la parte incómoda: los fallos son antiguos. Los investigadores de Wiz escribieron que los errores de fondo llevaban décadas presentes y que demostrar su explotabilidad requería una cadena de pasos excepcionalmente compleja, hasta que, en sus palabras, los modelos de IA de frontera redujeron esa barrera, «convirtiendo un fallo de larga data en un exploit». Léelo dos veces. El coste de convertir errores antiguos en armas acaba de abaratarse, y de forma permanente. Opines lo que opines sobre el bombo de la IA, la curva de costes del lado atacante se ha movido y no va a volver atrás. Ya hemos visto cómo son los errores latentes cuando por fin salen a la luz: el error de memoria compartida de OpenBSD, de 37 años, enseñó la misma lección con un radio de impacto menor.

El mérito del descubrimiento corresponde a investigadores de Wiz, Calif y OpenAI, que reportaron los fallos y coordinaron con el equipo de PHP la verificación del parche y la divulgación antes de la publicación. OpenAI lo calificó como uno de los problemas de seguridad con mayor impacto en tiempos recientes, dado el alcance de PHP. Luego se rompió el calendario: según The Hacker News, los detalles se filtraron el 20 de octubre, un día antes de la divulgación prevista para el 22 de octubre. Si alguna vez has coordinado una divulgación responsable, sabes lo que una filtración hace con una ventana de parcheo: convierte días en horas y entrega el cronómetro a cualquiera que esté mirando.

A las 3:02 a. m. UTC del 21 de octubre, Cloudflare había desplegado reglas de su firewall de aplicaciones web para bloquear el tráfico de ataque, y dijo que ya había detectado intentos de explotación contra estos fallos, que pueden provocar denegación de servicio, ejecución remota de código y exposición de datos. Alrededor de las 14:00 UTC de ese mismo día, PHP publicó las versiones corregidas y su aviso, dejando claro que solo una actualización completa protege totalmente un servidor. También el 21 de octubre, los gobiernos empezaron a desenchufar: los servicios gubernamentales finlandeses quedaron fuera de línea, como también los sitios del parlamento neerlandés, de las autoridades de ciberseguridad de los Países Bajos y del regulador neerlandés de protección de datos; el grupo de privacidad noyb también retiró temporalmente su web, según informó The Register. Reuters, a través de Krebs, señaló que webs gubernamentales de Europa y de otros lugares se cayeron como medida de precaución.

Mientras tanto, el lado ofensivo ya estaba trabajando. Jake Knott, responsable de inteligencia de amenazas en watchTowr, dijo a The Register que sus sensores ya detectaban intentos de explotación en libertad con lo que describió como pruebas de concepto hechas con IA de «vibecoding» que llevaban diversos User-Agent 'php2shell'. Su valoración: «Aunque nadie ha tenido éxito hasta ahora, no esperamos que eso dure mucho». Wiz prevé que el final sea una explotación masiva que instale web shells: habitaciones alquiladas dentro de tu servidor, con las cerraduras cambiadas.

¿Qué nos dice la secuencia a los defensores? Tres cosas. La filtración comprimió tu ventana, así que ayer era el momento adecuado para parchear. Los proveedores de WAF se movieron antes de que existieran los parches, lo que indica dónde están las horas baratas. Y los gobiernos que se apagaron hicieron las cuentas que haré más abajo: en algunos parques, el tiempo de inactividad sale más barato que la alternativa.

Por qué los servidores mod_php van primero en la cola

No todos los despliegues de PHP tienen el mismo riesgo, y fingir que sí desperdicia tu recurso más caro esta noche: la atención. El proyecto PHP afirma que cualquier instalación que sirva peticiones web es potencialmente afectada —PHP-FPM, mod_php de Apache, php-cgi, FrankenPHP, LiteSpeed—, pero señala a mod_php como el de mayor riesgo, con un exploit demostrado en el que una sola petición sin autenticar dispara el ataque antes de que se ejecute cualquier código de la aplicación. Tu WAF, tu página de inicio de sesión, tu costosa pasarela de confianza cero: todo queda aguas abajo de un fallo que se activa aguas arriba de todos ellos.

PHP-FPM está en mejor forma, pero no en forma segura. El propio análisis de PHP indica que FPM es susceptible a uno de los fallos, mientras que no se ha demostrado ningún exploit completo de FPM para él; el segundo fallo llegó a ejecución de código tanto en mod_php como en FPM, aunque la ruta de FPM depende de una operación dentro de la aplicación en ejecución. Y aquí está el coste latente que nadie está valorando: un atacante puede leer memoria del proceso worker de PHP —contraseñas, tokens de autenticación, claves de API, certificados de otras peticiones— sin llegar siquiera a ejecutar código, y los investigadores lo demostraron contra aplicaciones que no controlaban. Incluso un ataque «fallido» puede salir con tus secretos. Presupuesta la rotación de credenciales en consecuencia.

El WAF compra horas. Los ajustes de configuración compran menos. El parche compra la solución.

Ahora la pregunta de dinero que el consejo de administración preguntará de verdad: ¿qué nos dan las opciones más baratas? La regla de Cloudflare de las 3:02 a. m. es realmente valiosa: es un torniquete que frena a la multitud mientras arreglas la puerta. Pero el aviso de PHP es tajante: solo actualizar es una solución completa, y todo lo demás reduce la exposición a rutas de ataque concretas sin hacer seguro un servidor. Las mitigaciones parciales merecen desplegarse esta noche si no puedes parchear esta noche, siempre que nadie de tu organización las archive bajo «hecho»:

; Stopgap for CVE-2026-109618 — reduces exposure, does NOT fix
memory_limit = -1          ; set centrally so applications can't override it
post_max_size = 8M         ; keep low; also enforce request-size limits at the web server/proxy
; Do NOT rely on RLIMIT_AS or RLIMIT_DATA — PHP warns they can trigger the same vulnerable path
; Stopgap for CVE-2026-109619 — blocks confirmed session paths only
session.upload_progress.enabled = 0   ; then restart every worker
; On PHP 8.5 additionally:
fatal_error_backtraces = 0

El progreso de subida de sesión está activado por defecto y puede llegar al manejo de sesiones antes de que PHP termine de preparar una petición, por eso figura en una ruta de ataque confirmada para CVE-2026-109619 —y por qué ese ajuste, que circuló como «la solución alternativa» antes del lanzamiento, no hace absolutamente nada contra CVE-2026-109618. La desarrolladora principal de PHP, Gina Peter Banyard, lo resumió con más economía que cualquier analista:

«Lo único que puedo decir es que la única mitigación es parchear o actualizar PHP. Por desgracia, sé demasiado», escribió la desarrolladora principal de PHP Gina Peter Banyard, en respuesta a una sugerencia de que un ajuste de configuración podría bastar.

Así que la jerarquía honesta es: primero, actualización completa; después, reglas de WAF como cinturón de seguridad mientras llevas el coche al taller; las medidas de configuración como una plegaria; y el aislamiento para todo lo que no puedas parchear y no puedas permitirte perder. CERT-EU, que valoró ambos fallos con 9,2 en la escala CVSS, lo dijo antes de que llegaran los parches: cuando no sea viable parchear de inmediato, aísla las aplicaciones expuestas a internet de las redes públicas. Esa es la jugada de los gobiernos, y para un portal fiscal o la web de un parlamento sin contador de ingresos, es racional. Para una tienda online un jueves, la aritmética es más desagradable, y precisamente por eso haces esas cuentas ahora y no durante la respuesta a incidentes.

Dónde se esconde el coste real: el inventario, no el parche

El parche en sí es casi gratis. Las distribuciones de Linux y los proveedores de soporte a largo plazo recibieron las correcciones por adelantado —Ubuntu ya ha publicado paquetes actualizados, según el registro del SANS Internet Storm Center citado por Krebs—, y un paquete de distribución puede incluir la corrección bajo un número de versión que parece antiguo. Como aconseja Debian, revisa el changelog del paquete buscando el CVE, no la cadena de versión, antes de entrar en pánico o, peor, antes de relajarte. El proyecto PHP también ha publicado backports de código fuente para PHP 7.4, 8.0 y 8.1, que ya no reciben actualizaciones, para quienes compilan desde el código o esperan a un proveedor. PHP 8.2 llega al fin de su vida útil el 31 de diciembre, así que si este simulacro te ha dolido, has tenido un adelanto de tu próxima conversación presupuestaria.

Lo caro es encontrarlo todo. John Hammond, investigador principal de seguridad de Huntress, lo clavó: «El número de sitios donde tienes que buscar para identificar versiones vulnerables de PHP crece muy deprisa». PHP se esconde en plataformas de hosting compartido, paneles de control, appliances y software que no anuncia su runtime. Actualizar WordPress o Laravel no hace nada por el motor que hay debajo: el runtime viene del paquete del servidor, del host o de la imagen del contenedor. Y tras actualizar, debes reiniciar Apache, PHP-FPM y todos los workers de larga duración, y luego revisar tus ajustes de memoria: la corrección introduce un nuevo límite estricto de memoria que, al alcanzarse, termina el proceso sin ejecutar los manejadores de cierre. Pruébalo contra lo que realmente necesitan tus aplicaciones antes de que lo descubra producción por ti.

Wiz comparó el par con Log4Shell, y por una vez voy a permitir la comparación: no porque la explotación sea idéntica, sino porque el problema de la incrustación lo es. PHP funciona en nubes, proveedores de hosting, CDN y millones de servidores gestionados de forma independiente, y Wiz espera que las organizaciones tarden bastante en parchearlo. Traducido para el CFO: esto no es un martes de parches, es un trimestre de inventario de activos que no presupuestaste.

Mi valoración

Actúa ahora, y gasta en este orden: localiza cada runtime de PHP que tengas, parchea primero mod_php, reinicia todo y luego persigue los rezagados de FPM y de contenedores con reglas de WAF y los ajustes ini como cobertura, nunca como sustitutos. Si ejecutas algo realmente imposible de parchear y con mucho en juego, el parlamento neerlandés acaba de mostrarte la respuesta honesta. Y cuando el consejo pregunte si el ángulo de la IA cambia algo, dile la verdad: cambia el futuro, no esta noche. Esta noche es noche de parches.