El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones urgentes para dos vulnerabilidades críticas del núcleo del lenguaje: CVE-2026-109618 y CVE-2026-109619. Los dos fallos, conocidos conjuntamente como PHP2Shell, pueden permitir ejecución remota de código sin autenticación en instalaciones afectadas.
No se trata de un problema limitado a un framework o a un CMS. El aviso oficial incluye instalaciones que sirven peticiones web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera que el riesgo es mayor en mod_php, donde se ha demostrado un ataque capaz de activarse antes de que se ejecute el código de la aplicación.
Este artículo resume la información publicada por las fuentes oficiales y explica qué debe revisar una empresa responsable de aplicaciones PHP.
Fuentes primarias: aviso de seguridad del proyecto PHP, aviso de CVE-2026-109618 y aviso de CVE-2026-109619.
Conviene hablar de vulnerabilidades divulgadas y corregidas el 21 de octubre. La fecha exacta del descubrimiento interno puede ser anterior por el proceso de comunicación coordinada.
CVE-2026-109618 afecta al manejo de una situación de falta de memoria mientras PHP está procesando datos de una petición. Parte del estado interno puede quedar inicializado de forma incompleta. Más tarde, las operaciones de limpieza pueden tratar esos datos inválidos como si fueran correctos.
El resultado posible es corrupción de memoria y ejecución de código con los permisos del proceso web. El aviso confirma ejecución remota sin autenticación a través de HTTP contra mod_php. La fiabilidad del ataque depende de la compilación, las extensiones, el servidor y la disposición de memoria.
CVE-2026-109619 aparece cuando un proceso persistente conserva referencias a datos de una petición anterior después de que su memoria haya sido liberada. Una petición posterior atendida por el mismo proceso puede utilizar ese estado antes de que la inicialización normal lo sustituya.
Los investigadores validaron rutas relacionadas con el progreso de subida de sesiones y con ciertos estados de error. El problema afecta a distintas configuraciones de forma diferente, pero no existe una mitigación genérica que sustituya a la actualización.
La recomendación directa del proyecto PHP es actualizar inmediatamente a una de estas versiones corregidas:
| Rama | Primera versión corregida |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
PHP 8.1 y las ramas anteriores ya no reciben mantenimiento ordinario del proyecto. Algunos proveedores de distribuciones o soporte LTS pueden ofrecer correcciones retroportadas, pero deben verificarse con el proveedor concreto. Para una aplicación que necesita continuidad, la solución sostenible es migrar a una rama con soporte.
La revisión no debe limitarse al resultado de php -v en una consola. Un servidor puede tener varios intérpretes instalados y usar uno diferente para cada alojamiento, pool de PHP-FPM, contenedor o tarea programada.
El inventario debe comprobar:
También conviene revisar registros del servidor web, PHP, autenticación y sistema. Procesos inesperados, archivos recientes no explicados, cuentas nuevas, comandos anómalos o conexiones salientes desconocidas requieren investigación.
Los avisos oficiales describen ajustes que reducen rutas concretas de explotación, como desactivar session.upload_progress.enabled y reiniciar los procesos. Para PHP 8.5 también se documenta la desactivación de fatal_error_backtraces como medida parcial.
Estas acciones no cubren todas las variantes. Tampoco basta con ocultar errores, cambiar error_reporting o instalar una regla genérica en el cortafuegos. Si la aplicación no puede actualizarse de inmediato, las medidas de contención deben considerarse temporales y documentarse con una fecha de retirada.
Un orden razonable para reducir el riesgo es:
Cuando una actualización provoca errores, el problema suele estar en el código heredado, las extensiones o las dependencias. Mantener una versión vulnerable para evitar incompatibilidades traslada el problema y aumenta el coste del siguiente incidente.
La alternativa es preparar una migración controlada: inventario, análisis de compatibilidad, actualización por etapas, pruebas y despliegue reversible. En Hanka ofrecemos un servicio de actualización de aplicaciones PHP para llevar proyectos antiguos a versiones soportadas sin improvisar sobre producción.
También puedes consultar nuestra guía sobre cómo migrar una aplicación PHP antigua y el servicio de auditoría web técnica.
CVE-2026-109618 y CVE-2026-109619 recuerdan que la versión de PHP forma parte de la superficie de ataque, incluso cuando el código de la aplicación no ha cambiado. La respuesta correcta es conocer qué ejecuta realmente cada servicio, aplicar una versión corregida y retirar las ramas sin soporte mediante una migración planificada.
Últimas noticias y artículos en el Blog
