PHP2Shell: dos fallos críticos de PHP y cómo actuar

Qué se ha publicado y por qué requiere atención

Actualizado el 22 de octubre de 2026. El proyecto PHP publicó el 21 de octubre actualizaciones de seguridad para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas conjuntamente como PHP2Shell. No se trata únicamente de un plugin de un gestor de contenidos: el problema está en el motor PHP utilizado para atender solicitudes web. La explotación puede permitir ejecutar código en un servidor vulnerable sin autenticación. Es un motivo para actuar con urgencia, no una prueba de que cualquier web concreta ya haya sido comprometida.

El aviso oficial incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed entre las instalaciones que deben revisarse. PHP considera mayor el riesgo en mod_php y documenta una explotación demostrada antes de ejecutar el código de la aplicación. Por tanto, no basta con decir que la web es pequeña, que no tiene formularios de acceso o que sus plugins están actualizados. Hay que identificar el PHP que realmente atiende las peticiones y comprobar la corrección correspondiente. El alcance exacto de una instalación depende de su versión, proveedor y configuración; este artículo no determina el estado de ningún servidor particular.

Los dos fallos y las versiones corregidas

A grandes rasgos, CVE-2026-109618 está relacionada con corrupción de memoria durante el manejo de falta de memoria. CVE-2026-109619 afecta a estado interno que puede sobrevivir a la memoria que lo respaldaba y reutilizarse en otra solicitud del mismo trabajador. La PHP Foundation explica ambos problemas y su proceso de corrección. Entender esa diferencia ayuda a no reducir el incidente a una receta de configuración única. No necesitas reproducir un ataque para decidir actualizar, y esta guía no incluye pruebas de explotación contra servicios públicos ni comandos que provoquen fallos deliberados.

Las publicaciones del 21 de octubre identifican PHP 8.5.12,8.4.27,8.3.36 y 8.2.35 como versiones corregidas de las ramas correspondientes. Revisa el aviso vigente antes de intervenir, porque pueden aparecer revisiones posteriores. Un paquete de una distribución puede incorporar el parche mediante un backport sin adoptar exactamente esos números base: Ubuntu publica paquetes concretos en USN-8948-1. No compares solo la cadena de versión del intérprete con una lista de Internet. Confirma el paquete y el aviso del proveedor. PHP 8.1 y anteriores están fuera del soporte oficial del proyecto; una corrección de un distribuidor no devuelve por sí sola esa rama al soporte de PHP.

CVE-2026-109618 / CVE-2026-109619
PHP 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12

Qué pedir al alojamiento y qué debe verificar el administrador

Si utilizas alojamiento gestionado, solicita confirmación para ambos CVE: paquete instalado, servicio afectado y comprobación de que los procesos activos usan la corrección. Pregunta por todos los dominios, pools, contenedores y productos que incluyan PHP, no solo por la consola principal. Una versión mostrada por una herramienta de línea de comandos no demuestra necesariamente la que sirve la web. Si administras el sistema, utiliza el canal de actualización documentado por tu distribución o proveedor y conserva acceso de recuperación y una copia de seguridad adecuada antes de los cambios. No descargues supuestos parches de mensajes o repositorios no verificados.

Después de instalar la actualización, renueva los procesos según las instrucciones del proveedor y verifica qué versión o paquete está ejecutándose. Prueba las funciones esenciales de la aplicación y registra cuándo se aplicó la corrección. Actualizar solo el CMS o vaciar la caché no sustituye actualizar el runtime. Si hay indicios de intrusión, conserva evidencias y activa la respuesta a incidentes: parchear no revierte por sí mismo cambios ya realizados por un atacante. Estas son comprobaciones operativas de cierre, no un diagnóstico remoto. Un servidor que vuelve a mostrar la portada todavía necesita confirmación de parche y validación funcional.

Si no puedes actualizar y qué puede comprobar WikiURL

El equipo PHP advierte que solo actualizar ofrece una solución completa. Sus mitigaciones temporales reducen rutas concretas de ataque, pero no vuelven segura una instalación. No copies cambios de memoria o sesiones sin entender efectos y alcance en tu entorno. ENISA recomienda priorizar sistemas expuestos y considerar aislar aplicaciones de redes públicas cuando no sea posible corregir inmediatamente. Coordina esa decisión con el administrador para mantener un canal de gestión seguro y comunicar cualquier interrupción. Una regla WAF o una aplicación que parece funcionar no reemplazan el parche ni constituyen garantía de protección integral.

Comprobar URL de WikiURL puede ayudarte a revisar la respuesta HTTP y el destino detectado de una dirección pública después del mantenimiento. No identifica la versión real de PHP ni demuestra que estos CVE estén corregidos; un 200 o un candado HTTPS no equivalen a un análisis de vulnerabilidades. No envíes secretos ni publiques archivos phpinfo para acreditar una actualización. Conserva la confirmación técnica del proveedor, la comprobación de los procesos y las pruebas de servicio como evidencias distintas. La noticia exige actualizar con urgencia y verificar el resultado, evitando tanto el alarmismo sin pruebas como la falsa tranquilidad de una página que simplemente abre.