El equipo de PHP ha publicado actualizaciones de emergencia que reparan dos vulnerabilidades críticas en el propio lenguaje, capaces de permitir que un atacante sin cuenta ejecute código en un servidor web. Las versiones que incorporan las correcciones son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y sus responsables subrayan que únicamente la actualización protege de forma plena al servidor.
Los fallos, agrupados bajo el nombre PHP2Shell, afectan al entorno de ejecución de PHP y no al código de ninguna aplicación concreta, por lo que un sitio queda expuesto aunque su propio software esté bien programado. El riesgo es máximo en servidores que usan mod_php de Apache, donde un exploit funcional desencadena el ataque antes de que se ejecute código de la aplicación.
Ambos fallos tienen una puntuación de 9,2 en la escala CVSS v4.0 y están identificados como CVE-2026-109618 y CVE-2026-109619. PHP los hizo públicos en torno a las 14:00 UTC del 21 de octubre, un día después de que se filtraran detalles antes de la divulgación prevista para el 22 de octubre.
Los investigadores de Wiz (California) y de OpenAI descubrieron y notificaron los fallos, que afectan a prácticamente todas las versiones de PHP desde la 5.4.
Quién está afectado
Toda instalación de PHP que atienda peticiones web está en riesgo, incluidos PHP-FPM, mod_php de Apache, php-cgi, FrankenPHP y LiteSpeed, según el aviso de seguridad de PHP.
Dado que los fallos residen en el motor y no en el código de ningún sitio, incluso una página sencilla de «Hello World» sobre una versión vulnerable de PHP puede ser atacada.
El aviso señala a mod_php como el escenario de mayor riesgo, con un exploit demostrado en el que una sola petición no autenticada desencadena el ataque antes de que se ejecute código de la aplicación. PHP-FPM se comporta de forma distinta, porque cierra el proceso trabajador cuando una petición falla en las primeras fases de configuración.
En uno de los dos fallos, el propio análisis de PHP confirma que FPM es susceptible, pero sostiene que no se ha demostrado un exploit completo contra FPM; el segundo fallo sí alcanzó ejecución de código tanto en mod_php como en PHP-FPM, si bien en FPM esa ruta depende de una operación dentro de la aplicación en ejecución.
Un atacante también puede leer la memoria del proceso trabajador de PHP, que puede contener contraseñas, tokens de autenticación, claves de API y certificados pertenecientes a otras peticiones, sin necesidad de obtener primero ejecución de código.
Los investigadores demostraron esa lectura de memoria activa de procesos trabajadores contra aplicaciones que no controlaban, lo que la hace independiente de la aplicación que se ejecute sobre PHP.
Qué hay que instalar
Hay que actualizar el entorno de ejecución de PHP que atiende las peticiones web y después reiniciar Apache, PHP-FPM y cualquier proceso trabajador de PHP de larga duración. Actualizar una aplicación como WordPress o Laravel no actualiza el entorno de PHP que hay debajo; eso depende del paquete del servidor, del proveedor de alojamiento o de la imagen de contenedor.
PHP 8.1 y versiones anteriores ya no reciben actualizaciones del proyecto PHP, y PHP 8.2 alcanzará su fin de vida el 31 de diciembre de 2026. Para las ramas más antiguas, el equipo de seguridad de PHP ha publicado retroportes del código fuente para PHP 7.4, 8.0 y 8.1, destinados a quienes compilan desde el código fuente o esperan a un proveedor.
Las distribuciones de Linux y los proveedores de soporte a largo plazo recibieron los parches por anticipado, de modo que un paquete de distribución puede incluir la corrección bajo un número de versión que parezca antiguo; conviene revisar el registro de cambios del paquete en busca del CVE, como recomienda Debian, y no guiarse por la cadena de versión.
Si aún no puedes actualizar
Solo la actualización constituye una corrección completa. Las medidas que siguen reducen la exposición a determinadas rutas de ataque y no hacen seguro un servidor, según el aviso.
Para CVE-2026-109618, hay que fijar memory_limit=-1 para que las aplicaciones no puedan sobrescribirlo, mantener post_max_size bajo y aplicar límites de tamaño de petición en el servidor web o en el proxy. No deben usarse RLIMIT_AS ni RLIMIT_DATA como sustituto, porque PHP advierte de que pueden activar la misma ruta vulnerable.
Para CVE-2026-109619, hay que establecer session.upload_progress.enabled=0 y reiniciar todos los procesos trabajadores; además, en PHP 8.5 hay que fijar fatal_error_backtraces=0. Desactivar el progreso de subida de sesión bloquea las rutas de sesión confirmadas, pero no otras variantes, y ningún cambio de configuración mitiga por completo este fallo salvo la actualización.
Ese ajuste es el que circuló como solución provisional antes del parche, y la publicación confirma que nunca fue una corrección completa. El progreso de subida de sesión está activado por defecto y puede llegar al manejo de sesiones antes de que PHP termine de configurar una petición, lo que explica su papel en una ruta de ataque confirmada para CVE-2026-109619 y por qué desactivarlo no sirve de nada frente a CVE-2026-109618.
«Lo único que puedo decir es que la única mitigación es parchear o actualizar PHP. Por desgracia sé demasiado», escribió la desarrolladora del núcleo de PHP Gina Peter Banyard antes de la publicación, en respuesta a alguien que sugirió que ese ajuste podría bastar.
Tras actualizar, conviene revisar la configuración de memoria. La corrección añade un nuevo límite estricto de memoria cuyo alcance termina el proceso e impide que se ejecuten los manejadores de apagado, por lo que hay que comprobar memory_limit y post_max_size frente a lo que necesita la aplicación.
Si ya se ha aplicado el parche pero se sospecha de una intrusión anterior, los investigadores sugieren vigilar peticiones multipart inusuales seguidas de errores de límite de memoria o respuestas HTTP 500 repetidas, cookies de respuesta PHPSESSID anormalmente grandes y reinicios inexplicables de procesos trabajadores de PHP.
¿Se está atacando?
Antes de que el parche se publicara, Cloudflare afirmó que estaba observando intentos tempranos de explotar los fallos. «Estamos viendo ataques incipientes y actualizamos las mitigaciones a medida que aparecen nuevos vectores», dijo el director de tecnología de Cloudflare, Dane Knecht, quien calificó de medida provisional las reglas de cortafuegos desplegadas por la empresa y urgió a los administradores a aplicar el parche.
Ninguna fuente ha confirmado una intrusión exitosa. watchTowr, que reprodujo CVE-2026-109618, informó de que no había explotación en la naturaleza a las 11:26 UTC del 21 de octubre, y en ese momento ninguno de los dos fallos figuraba en el catálogo de vulnerabilidades explotadas conocidas de CISA.
Algunas organizaciones retiraron servicios como precaución y no en respuesta a ninguna intrusión. BambooHR dejó su servicio fuera de línea en Estados Unidos, Canadá e Irlanda, advirtió de que la nómina se vería interrumpida y afirmó que aún no tenía un plazo de restablecimiento.
En los Países Bajos, MijnOverheid, DigiD, la web de la cámara baja del parlamento, el centro nacional de ciberseguridad y varios sistemas educativos quedaron fuera de servicio, según informó la cadena NOS; el centro afirmó que no había visto explotado el fallo, pero instó a todos a aplicar el parche.
Cómo salió a la luz
Una filtración adelantó la publicación. El 20 de octubre, según informó The Hacker News, una publicación en Hacker News afirmaba, basándose en un simple aviso de confianza, que dos fallos de ejecución remota de código de PHP, con los dos identificadores CVE, se divulgarían el 22 de octubre.
PHP publicó esa misma tarde un aviso previo y adelantó la publicación al 21 de octubre. La puntuación CVSS 10,0 que atribuía la filtración no era la de PHP; PHP califica ambos fallos con 9,2.
Los fallos fueron descubiertos por Wiz Research (California) y el equipo Codex Security de OpenAI, en colaboración con el equipo de seguridad de PHP y el equipo Gemini de Google para la corrección. El código subyacente llevaba más de una década en PHP.
Los investigadores sostienen que los modelos de inteligencia artificial ayudaron a convertir estos fallos de larga data en exploits funcionales, permitiendo que un solo investigador hiciera en aproximadamente una semana lo que, según ellos, habría requerido meses a un equipo.
Calif, que remontó el linaje del error a una investigación sobre PHP de 2004, afirma que conocer la historia del objetivo siguió siendo relevante y que los modelos actuales no parten de forma fiable de primitivas oscuras de hace veinte años por sí solos.
Actualización: watchTowr informa de intentos de explotación, aún sin intrusión confirmada
watchTowr, que antes en el día había informado de que no había visto ninguno, señaló en un nuevo aviso a las 14:19 UTC del 21 de octubre que está observando «intentos activos de explotación» de CVE-2026-109618 y CVE-2026-109619. Cloudflare dijo que vio tráfico de ataque contra sus clientes y observó a los atacantes cambiar sus cargas útiles para sortear sus reglas de cortafuegos, que había activado por defecto a las 03:02 UTC, antes del parche. Ninguna fuente ha informado de una intrusión confirmada en un servidor concreto hasta esta actualización.
La Fundación PHP afirmó que la divulgación coordinada se desmoronó antes de la publicación. En torno a las 20:00 UTC del 20 de octubre, la firma de investigación Calif publicó por error un vídeo de su prueba de concepto funcional, y a las 07:41 UTC del 21 de octubre, unas seis horas antes de que se distribuyera la corrección, el proveedor Chainguard publicó imágenes ya compiladas con el parche, lo que permitió a cualquiera estudiar la corrección mientras otros usuarios esperaban para actualizar.
Actualización: la Fundación PHP afirma que una auditoría de 2024 detectó los primeros indicios del fallo
En la misma publicación, la Fundación PHP indicó que un desarrollador del núcleo detectó por primera vez indicios del fallo de agotamiento de memoria que hay detrás de CVE-2026-109618 durante la auditoría externa de PHP en 2024, pero entonces solo se teorizó un ataque funcional y no se encontró ninguna ruta concreta hacia la ejecución de código.
Las soluciones en competencia corrían el riesgo de romper la compatibilidad, abrir rutas de denegación de servicio o forzar cambios en extensiones de terceros, y un equipo reducido tuvo dificultades para llegar a un acuerdo, por lo que el trabajo en la corrección se estancó durante meses. La Fundación calificó el retraso de «fallo estructural» de su proceso de decisión y de sus recursos.
Los informes de 2026 de Calif, OpenAI y Wiz, que emplearon herramientas de inteligencia artificial, establecieron el exploit funcional que dejó claro el impacto total del fallo e impulsaron la corrección al primer puesto de la cola. La Fundación afirma que desde entonces ha cambiado su forma de tomar decisiones de seguridad y ha incorporado personal y herramientas para detectar antes problemas similares.
（La noticia se actualizó tras su publicación el 21 de octubre de 2026 para añadir los informes posteriores sobre intentos de explotación y el relato de la Fundación PHP acerca de la historia del fallo.）
Deja una respuesta