El pasado 21 de octubre de 2026 el equipo de PHP publicó actualizaciones de seguridad de emergencia para corregir dos vulnerabilidades críticas en el intérprete del lenguaje: CVE-2026-109618 y CVE-2026-109619. Conocidas en conjunto como PHP2Shell, permiten a un atacante ejecutar código de forma remota sin autenticación en cualquier servidor que procese peticiones web con PHP.
Si tomamos en cuenta que PHP está detrás de WordPress, Drupal, Magento, Laravel y la mayor parte del hosting compartido del mundo, hablamos de uno de los incidentes de seguridad más importantes de los últimos años.
¿Qué es exactamente PHP2Shell?
Se trata de dos fallos distintos pero relacionados, ambos con una puntuación CVSS v4.0 de 9.2 sobre 10:
- CVE-2026-109618: cuando PHP se queda sin memoria durante una petición, el proceso puede interrumpirse mientras los datos internos están solo parcialmente inicializados. La limpieza posterior trata esos datos inválidos como si fueran válidos, lo que abre la puerta a la ejecución de código arbitrario.
- CVE-2026-109619: parte del estado interno de una petición puede sobrevivir después de que su memoria ya fue liberada (un use-after-free), lo que permite fugas de memoria y, combinado con el primer fallo, facilita el ataque.
Lo más preocupante es el alcance: las vulnerabilidades están presentes en todas las versiones de PHP desde la 5.4 hasta la 8.5.11. Es decir, código que llevaba más de una década en el núcleo del lenguaje.
¿Cómo se descubrió?
Los fallos fueron identificados por el equipo de investigación de Wiz utilizando una combinación de modelos de inteligencia artificial, y reportados de forma responsable a la Fundación PHP. La corrección se trabajó bajo embargo durante semanas, involucró cerca de 200 archivos modificados y más de 10,000 líneas de código.
Sin embargo, parte de los detalles se filtraron antes de la fecha de publicación prevista, lo que obligó a adelantar el lanzamiento de los parches. Pocos días después ya existían pruebas de concepto públicas capaces de ejecutar comandos en servidores vulnerables, por lo que el riesgo de explotación activa es real.
Versiones afectadas y versiones corregidas
| Rama de PHP | Estado | Versión segura |
|---|---|---|
| PHP 8.5 | Soportada | 8.5.12 o superior |
| PHP 8.4 | Soportada | 8.4.27 o superior |
| PHP 8.3 | Soportada | 8.3.36 o superior |
| PHP 8.2 | Soporte de seguridad (fin: 31/12/2026) | 8.2.35 o superior |
| PHP 8.1 y anteriores | Fin de vida (EOL) | Sin parche oficial: migrar urgentemente |
¿Qué debes hacer ahora mismo?
El propio equipo de PHP lo dijo con claridad: no existen mitigaciones completas, actualizar es la única opción segura. Estos son los pasos recomendados:
- Haz un inventario de todo lo que ejecuta PHP. No solo tus sitios principales: incluye paneles de hosting (cPanel, Plesk), aplicaciones internas, contenedores Docker, appliances y binarios independientes como
php-cgi. - Actualiza a la versión corregida. Si usas el gestor de paquetes de tu sistema operativo (apt, yum, dnf), aplica los paquetes actualizados de tu distribución. Si compilas desde código fuente o usas imágenes Docker, descarga la versión parcheada desde php.net.
- Verifica la versión instalada ejecutando
php -ven cada servidor y confirmando que coincide con una versión segura de la tabla anterior. - Reinicia los servicios (php-fpm, Apache, Nginx) para que la nueva versión entre en efecto.
- Si estás en PHP 8.1 o anterior, planifica una migración inmediata. Esas ramas no recibirán parche oficial.
Cómo detectar si ya fuiste comprometido
La explotación de PHP2Shell suele manifestarse como procesos hijos anómalos lanzados directamente por los workers de PHP (php-fpm, php-cgi, httpd, apache2). Revisa tus logs y herramientas de monitoreo buscando que estos procesos hayan ejecutado comandos de sistema como sh, bash, curl, wget o python, especialmente desde el 20 de octubre en adelante.
Si encuentras actividad sospechosa, aísla el servidor, conserva los logs y considera restaurar desde un respaldo limpio anterior a la fecha de exposición.
Lecciones que nos deja este incidente
PHP2Shell nos recuerda tres cosas fundamentales:
- Las versiones sin soporte (EOL) son una bomba de tiempo. Si todavía corres PHP 7.x u 8.0, hoy no tienes forma de protegerte sin migrar.
- La inteligencia artificial ya es una herramienta activa en la búsqueda de vulnerabilidades, tanto para investigadores como para atacantes. El tiempo entre divulgación y explotación se acorta cada vez más.
- Tener un inventario actualizado de tus sistemas y un proceso de parcheo ágil ya no es opcional: es la diferencia entre actualizar en horas o enterarte por un incidente.
Si necesitas ayuda para auditar tus servidores o planificar la migración de versiones antiguas de PHP, contáctanos. Nuestro equipo puede acompañarte en el proceso.
