El 21 de octubre de 2026, el proyecto PHP publicó fuera de ciclo un parche para dos
vulnerabilidades críticas de ejecución remota de código sin autenticación, identificadas como
CVE-2026-109618 y CVE-2026-109619, con una puntuación de 9,2 sobre la escala CVSS v4.0. Los
investigadores que las descubrieron las apodaron «PHP2Shell». Las versiones corregidas,
8.5.12, 8.4.27, 8.3.36 y 8.2.35, están disponibles desde el 22 de octubre.
Dos fallos sin autenticación, ya explotados
Ambas vulnerabilidades afectan al procesamiento de solicitudes en instalaciones PHP
expuestas, sin necesidad de autenticación previa. Cloudflare y la firma de seguridad watchTowr
informan de intentos de explotación activa pocas horas después de la divulgación, lo que llevó
a la agencia estadounidense CISA a publicar una alerta el 21 de octubre instando a actualizar
de inmediato. Un proveedor de seguridad calcula que casi dos millones de servidores PHP siguen
potencialmente expuestos.
Ningún ajuste de configuración basta
El proyecto PHP precisa que ningún ajuste de configuración neutraliza por completo ambos
fallos: la actualización binaria es la única protección completa. Es necesario reiniciar los
procesos PHP-FPM o el servidor de aplicaciones tras instalar el parche; de lo contrario, el
código vulnerable antiguo sigue ejecutándose en memoria.
| Rama | Versión corregida | Estado del parche |
|---|---|---|
| PHP 8.5 | 8.5.12 | Rama activa, corrección completa |
| PHP 8.4 | 8.4.27 | Rama activa, corrección completa |
| PHP 8.3 | 8.3.36 | Solo seguridad, corrección completa |
| PHP 8.2 | 8.2.35 | Solo seguridad, corrección completa |
| PHP 8.1 y anteriores | Sin versión oficial | Fuera de soporte, algunos proveedores ofrecen parches de fuente |
Actualizar un servidor en producción
En una distribución Debian o Ubuntu con los repositorios oficiales de PHP, el procedimiento
se reduce a actualizar el paquete y reiniciar los servicios implicados:
php -v
sudo apt update
sudo apt install --only-upgrade php8.4 php8.4-fpm
sudo systemctl restart php8.4-fpm nginx
Los proveedores de alojamiento compartido y paneles como Plesk han publicado sus propias
compilaciones corregidas; los equipos que gestionan un
servidor autoalojado
deben comprobar la versión que muestra php -v antes de dar el incidente por
cerrado, incluso en instancias donde PHP se ejecuta discretamente detrás de un CMS.
Ningún ajuste de configuración neutraliza por completo ambos fallos: solo la actualización binaria, seguida de un reinicio de los procesos PHP, cierra la ventana de exposición.
Un patrón ya visto en el ecosistema WordPress
La velocidad de la explotación recuerda a un patrón ya documentado en este medio: un
fallo crítico de WordPress atacado activamente cinco días después de su parche.
Los sitios cuya base PHP no está reforzada siguen siendo los primeros objetivos en cuanto el
exploit se hace público, sea cual sea el CMS instalado encima; las bases de un
hardening mínimo de WordPress
reducen la superficie de ataque, pero no sustituyen la actualización del propio intérprete.
PHP. Los sitios que aún las usan permanecen expuestos mientras no migren a una rama mantenida.
Lo que hay que recordar
Dos vulnerabilidades críticas, explotables sin autenticación y ya bajo ataque activo,
afectan a todas las ramas de PHP mantenidas. La corrección pasa por actualizar a 8.5.12,
8.4.27, 8.3.36 u 8.2.35 según la rama utilizada, seguido de un reinicio de los procesos PHP.
Las versiones anteriores a la 8.2, ya fuera de soporte, no tienen parche oficial y deben
considerarse prioritarias para la migración.
En los proyectos donde gestiono la infraestructura, este tipo de alerta fuera de ciclo es
uno de los pocos casos en los que detengo la cola de despliegues del día para aplicar el
parche antes que cualquier otra tarea. La experiencia de las explotaciones relámpago en
WordPress de los últimos meses muestra que el plazo entre divulgación y ataque automatizado se
mide ahora en horas, no en días. Un simple cron que verifique la versión de PHP, junto con una
alerta, cuesta mucho menos que un servidor comprometido un domingo por la noche. —
Simon Janvier
Para saber más: el changelog oficial de PHP 8.x.
