El caso PHP2Shell, las dos vulnerabilidades críticas de PHP corregidas el 21 de octubre de 2026, deja una lección muy concreta para los administradores de sistemas: el tiempo de reacción no dependió solo de PHP, sino de quién empaqueta el intérprete en cada servidor y de si esa versión seguía teniendo soporte. La reconstrucción publicada por la PHP Foundation y por FOSS Pub, que Opensecurity resumió en su análisis de la auditoría alemana y el fallo estructural, muestra que el fallo se detectó en 2024 y que algunas instalaciones solo recibieron el parche por vías de pago.
Las claves de PHP2Shell para administradores de sistemas en 20 segundos
- PHP corrigió CVE-2026-109618 y CVE-2026-109619 el 21/10/2026, dos fallos de ejecución remota sin autenticación.
- Chainguard publicó sus paquetes más de seis horas antes que PHP.
- Debian 11 y Ubuntu antiguos solo recibieron el arreglo con soporte de pago.
- PHP 8.1 y anteriores solo tuvieron parches de código fuente.
Para un equipo de sistemas, el problema no fue solo instalar una actualización urgente. Fue saber, en cuestión de horas, de dónde venía cada PHP instalado, cuándo iba a llegar su paquete corregido y qué hacer con los servidores que no lo iban a recibir.
Quién empaqueta PHP en cada servidor marca cuándo llega el parche
Según la PHP Foundation, Chainguard, que vende compilaciones listas para usar de software libre, publicó sus versiones corregidas a las 07:41 UTC, más de seis horas antes que el proyecto. PHP publicó a las 13:33 UTC y Debian distribuyó su paquete doce minutos después, gracias al trabajo de Ondřej Surý, el voluntario que empaqueta PHP para Debian y Ubuntu. Entre una hora y otra, el código corregido ya era público y cualquiera podía compararlo con el anterior para localizar el fallo, mientras buena parte de los servidores esperaba a su distribución.
La PHP Foundation sostiene que Chainguard rompió el embargo; su consejero delegado, Dan Lorenc, defendió, según recoge Socket, que adelantó la publicación porque ya circulaban exploits. Para el administrador, la discusión deja una conclusión práctica: hay que saber qué fuente tiene cada máquina (paquetes de la distribución, el repositorio de Surý, el de Remi en sistemas Red Hat, imágenes de contenedores de terceros o compilaciones propias) y vigilar sus avisos de seguridad. Estas órdenes ayudan a comprobar el origen y si el paquete ya incluye la corrección:
# ¿De qué repositorio viene el PHP instalado? (Debian/Ubuntu)
apt-cache policy php8.3
# ¿Incluye el paquete la corrección? (Debian/Ubuntu)
apt changelog php8.3 | grep -E 'CVE-2026-10961(8|9)'
# Lo mismo en RHEL, Rocky, Alma o Fedora
dnf info php
rpm -q --changelog php | grep -E 'CVE-2026-10961(8|9)'Lenguaje del código: PHP (php)Que el changelog mencione las CVE no basta si los procesos siguen vivos con el binario antiguo: hay que reiniciar PHP-FPM o Apache, y reconstruir y desplegar de nuevo los contenedores sobre la imagen corregida.
Las versiones sin soporte, el punto débil
Según FOSS Pub, Debian 11 solo recibió el arreglo a través del soporte extendido de pago de Freexian, las versiones antiguas de Ubuntu a través de Ubuntu Pro, y PHP 8.1 y anteriores solo tuvieron parches de código fuente. Quien mantenía PHP 7.x instalado a mano o imágenes antiguas se quedó sin paquete oficial y con dos salidas: compilar con el parche o migrar. La tabla de versiones con soporte de PHP es la referencia para saber qué ramas reciben correcciones de seguridad.
La respuesta del BSI, la oficina federal alemana de seguridad de la información, muestra la alternativa cuando no se puede parchear: elevó su alerta al nivel naranja y recomendó separar temporalmente de internet los servidores web sin corregir. Administraciones como la oficina federal de policía criminal (BKA) y varios gobiernos regionales lo hicieron. Es una medida drástica, pero para un servicio expuesto con una vulnerabilidad de ejecución remota y sin parche disponible, desconectarlo o limitar su acceso por VPN o lista de direcciones IP puede ser la opción menos mala.
El origen del fallo también tiene lectura para quien gestiona infraestructura. Según la PHP Foundation, un desarrollador vio las primeras señales en 2024, al corregir hallazgos de una auditoría de Quarkslab financiada por la Sovereign Tech Agency alemana, pero el arreglo se atascó por falta de consenso y de personas hasta que la firma Calif reportó un ataque funcional el 11 de agosto de 2026. La Foundation ha anunciado que su equipo de seguridad decidirá por mayoría y escalará antes los casos difíciles. Para los equipos de sistemas, la tarea pendiente es tener un inventario de versiones de PHP, saber quién las empaqueta y retirar las que ya no tienen soporte antes de la próxima alerta.
Preguntas frecuentes
¿Qué es PHP2Shell?
El nombre de dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código en un servidor web sin iniciar sesión. Se corrigieron el 21 de octubre de 2026.
¿Cómo sé si mi PHP tiene ya el parche?
Comprobando el changelog del paquete instalado (apt changelog o rpm -q –changelog) y buscando las dos CVE. Después hay que reiniciar PHP-FPM o Apache.
¿Qué pasa con PHP 8.1 o PHP 7?
PHP 8.1 y anteriores solo recibieron parches de código fuente. En distribuciones sin soporte, como Debian 11, el arreglo llegó a través de servicios de pago.
¿Por qué unos proveedores tuvieron el parche antes que otros?
Chainguard publicó sus paquetes más de seis horas antes que PHP, lo que la PHP Foundation considera una ruptura del embargo, y las distribuciones lo publicaron después del proyecto.
Fuentes:
- Opensecurity: PHP2Shell, la auditoría alemana de 2024 y el fallo estructural
- PHP Foundation: Today’s PHP security release and how we’re strengthening PHP security
- FOSS Pub: Germany Paid for the Audit That Spotted PHP’s Bug, Then Took Its Police Websites Offline
- Socket: PHP Foundation Says Chainguard Broke Security Embargo Ahead of Emergency Patches
- PHP: Supported versions
