PHP publica los parches de PHP2Shell para las ramas 8.2 a 8.5

PHP publicó el 21 de octubre cuatro actualizaciones de seguridad para corregir CVE-2026-109618 y CVE-2026-109619, dos fallos críticos en el núcleo del lenguaje que pueden permitir ejecución remota de código (RCE) sin autenticación. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. La recomendación urgente no depende de usar un CMS concreto: el componente vulnerable es el runtime PHP que ejecuta la aplicación.

El NHS England describe dos rutas técnicas distintas: una relacionada con errores de memoria agotada y otra con estado global obsoleto que puede seguir apuntando a memoria de una petición ya liberada. Sus investigadores dicen haber demostrado explotación con ejecución de código en productos que integran PHP, incluidos WordPress, Drupal y Joomla. La organización puntúa ambos fallos en 9,2 con CVSS v4; eso expresa gravedad, pero por sí solo no demuestra que haya ataques extendidos en producción.

-InfraCrew dice: Una aplicación puede estar impecable y aun así heredar el riesgo de un runtime que nadie incluyó en el inventario de activos.-

El parche va en el runtime

El alcance práctico depende de qué versión ejecuta cada proceso PHP, no del nombre que aparezca en el gestor del CMS. La misma aplicación puede convivir con varias ramas en producción, workers separados, contenedores antiguos y tareas programadas que usan otro intérprete. PHP mantiene ramas distintas en paralelo, de modo que la corrección debe corresponder a la rama desplegada; instalar una actualización para otra línea no resuelve el fallo.

El proceso vulnerable suele atender peticiones con los permisos del usuario de servicio, por ejemplo a través de PHP-FPM, el gestor que mantiene workers PHP y habla con servidores web como Nginx. Una RCE no convierte automáticamente al atacante en administrador del sistema: el efecto inicial queda limitado por los permisos, secretos montados y rutas accesibles desde ese proceso. Pero en una aplicación web esos permisos pueden incluir credenciales de base de datos, claves de API o escritura sobre archivos que después ejecuta la propia aplicación.

La numeración de rama importa: PHP 8.2 queda corregido en 8.2.35; 8.3 en 8.3.36; 8.4 en 8.4.27; y 8.5 en 8.5.12. PHP 8.1 y anteriores también están afectados según la alerta del NHS, pero ya han llegado al fin de vida y no reciben correcciones upstream. Ahí la decisión no es buscar una compilación oficial inexistente: hay que migrar a una rama mantenida o comprobar si el proveedor del sistema operativo ofrece un backport, una corrección aplicada a su paquete mantenido.

-InfraCrew dice: “El CMS ya está al día” no sirve como prueba si su contenedor sigue arrancando un PHP anterior.-

Qué revisar hoy

Empieza por inventariar los runtimes reales de cada entorno, incluidos pods, imágenes base, servidores de integración y jobs fuera del tráfico web. Contrasta la rama y el paquete instalado con los avisos del proveedor que mantiene ese sistema; si distribuye PHP con numeración propia, una comparación literal con el número upstream puede dar un falso positivo o, peor, tranquilidad falsa. PHP indica que actualizar es la única corrección completa.

Después, despliega la actualización por el procedimiento habitual del entorno y verifica qué binario quedó activo en cada worker. Una imagen corregida que aún no se ha vuelto a desplegar no cambia los procesos que siguen vivos; tampoco basta con parchear el nodo si la aplicación usa una imagen inmutable que contiene la versión antigua. Registra el artefacto o paquete exacto que se validó para que el siguiente ciclo de construcción no lo vuelva a introducir.

Si no puedes actualizar de inmediato, el NHS recomienda retirar de Internet temporalmente los dispositivos vulnerables después de evaluar el riesgo local. Es una medida de contención, no una solución permanente: reduce la exposición externa, pero no corrige el runtime ni descarta que el sistema haya recibido peticiones antes de quedar aislado. La alerta describe pruebas de explotación; no afirma que cada servidor afectado haya sido comprometido.

Conviene priorizar los registros y los secretos accesibles desde el worker durante el periodo de exposición. Si aparecen indicios de ejecución no autorizada, trata el host como posible incidente y sigue el proceso de respuesta de la organización; no conviertas una búsqueda de cadenas en una prueba de limpieza. La prioridad operativa está clara: localizar las ramas antiguas, corregirlas y confirmar el despliegue efectivo.

-InfraCrew dice: El parche puede caber en una línea de cambio; encontrar las cinco imágenes base que alguien dejó copiadas en un registry suele ocupar el resto de la mañana.-

Diccionario de la Crew

RCE — Ejecución de código en un sistema remoto a través de una vulnerabilidad; aquí, desde el proceso PHP que atiende la aplicación.
PHP-FPM — Gestor FastCGI que mantiene procesos PHP disponibles para atender peticiones de un servidor web.
CVSS v4 — Sistema de puntuación que estima la gravedad técnica de una vulnerabilidad; no mide por sí solo la explotación real ni el impacto en una organización concreta.
backport — Corrección de seguridad trasladada a la versión de un paquete que mantiene una distribución, sin tener que actualizar a la numeración upstream más reciente.

Fuentes

PHP.net — archivo de versiones 2026 | https://www.php.net/archive/2026.php
NHS England Digital — alerta PHP2Shell | https://digital.nhs.uk/cyber-alerts/2026/cc-4875