¿Qué ha ocurrido con PHP2Shell?
El 21 de octubre de 2026, PHP publicó actualizaciones de seguridad para CVE-2026-109618 y CVE-2026-109619. Bajo determinadas condiciones, ambas vulnerabilidades pueden permitir la ejecución remota de código sin autenticación. Cada una tiene una puntuación CVSS v4.0 de 9,2. Esta cifra expresa la gravedad técnica, no la probabilidad de que una empresa concreta ya haya sido atacada.
La PHP Foundation describe retrasos en la corrección del problema de memoria y dificultades en la divulgación coordinada. La difusión anticipada de información llevó a adelantar la publicación un día. Para los responsables de los sistemas, la prioridad es saber qué instancias en ejecución han recibido realmente el parche. [1] [3] [4]
¿Qué versiones de PHP incluyen los parches?
La tabla recoge las primeras versiones corregidas del proyecto PHP para las dos vulnerabilidades del 21 de octubre. No permite descartar CVE-2026-115560, el problema adicional anunciado el día 23. Consulte también los avisos posteriores del proveedor.
Las distribuciones Linux y los paquetes de hosting gestionado pueden incorporar un parche adaptado y conservar un número de versión anterior de PHP. En ese caso, compruebe la versión completa del paquete y el boletín de seguridad del proveedor. PHP 8.1 y las ramas anteriores ya no reciben actualizaciones regulares del proyecto PHP; los parches adaptados por proveedores y los parches mínimos disponibles como código fuente necesitan una verificación independiente. No sustituyen una migración planificada a una rama con soporte. [1] [4]
Deslice la tabla horizontalmente para leerla.
| Rama PHP | Versión corregida | Prueba necesaria |
|---|---|---|
| 8.2 | 8.2.35 | Paquete web activo o parche adaptado y documentado por el proveedor |
| 8.3 | 8.3.36 | Paquete web activo o parche adaptado y documentado por el proveedor |
| 8.4 | 8.4.27 | Paquete web activo o parche adaptado y documentado por el proveedor |
| 8.5 | 8.5.12 | Paquete web activo o parche adaptado y documentado por el proveedor |
Revise también el aviso sobre sesiones del 23 de octubre
PHP recomienda establecer temporalmente session.upload_progress.enabled=0 hasta la próxima versión regular de corrección de errores. El aviso se refiere a CVE-2026-115560 y a una combinación poco habitual de configuración y código de la aplicación. Debe tratarse por separado de las dos vulnerabilidades ya corregidas.
La condición descrita es concreta: session.serialize_handler está configurado inicialmente como php_binary o php_serialize. Durante la petición, la aplicación lo cambia a php mediante ini_set(), antes de llamar a session_start(), mientras sigue habilitado el seguimiento del progreso de subida en las sesiones. Según PHP, las aplicaciones que nunca cambian el gestor durante la ejecución pueden mantener esta función habilitada.
Pida al administrador que compruebe la configuración efectiva. Una desactivación preventiva debe aplicarse en la configuración del servidor o de PHP antes de analizar las peticiones; hay que reiniciar los procesos afectados. Un ini_set() posterior en el código de la aplicación no lo sustituye. Si el ajuste ya está aplicado, manténgalo. El aviso aún no indica una fecha ni nuevas versiones para la corrección regular. Estado comprobado el 24 de octubre de 2026. [1] [2]
Por qué no basta con actualizar WordPress
El CMS y el entorno PHP que lo ejecuta son componentes distintos. Tener WordPress, Drupal o Joomla actualizado no demuestra que el servidor web esté ejecutando una versión corregida de PHP. Que la web cargue con normalidad tampoco confirma su estado de parcheado.
Incluya tiendas, portales de clientes, subdominios e instalaciones antiguas, además de la web principal. Identifique el entorno que realmente procesa las peticiones web de cada sistema. PHP-FPM no está excluido de forma automática; PHP también menciona mod_php, CGI, FrankenPHP y LiteSpeed. La línea de comandos puede utilizar una instalación de PHP distinta de la del servidor web. No publique una página phpinfo() accesible a cualquiera para hacer esta comprobación. [1] [5]
Más información: por qué siguen abiertas vulnerabilidades conocidas aunque haya parches
Identificar el sistema
Registre el dominio, la aplicación, el responsable del hosting y el entorno PHP que atiende las peticiones.
Activar el parche
Instale el paquete adecuado, reinicie los procesos afectados y revise la configuración de sesiones por separado.
Verificar el funcionamiento
Registre el paquete activo, las pruebas funcionales y la fecha. Mantenga pendientes los sistemas sin verificar.
Un resultado verificable, más allá de un ticket de actualización
Cada sistema necesita un responsable, una referencia del proveedor y una comprobación de la instancia en ejecución. La versión mostrada en la línea de comandos no basta.
Esquema original. Estas comprobaciones documentan el estado operativo; no demuestran que el sistema no haya sufrido una intrusión previa.
Qué debe confirmar su proveedor de hosting
Una respuesta genérica como «nuestros servidores están actualizados» deja preguntas importantes sin resolver. Solicite una confirmación específica para sus sistemas. Puede utilizar este texto:
Por favor, confirmen el entorno PHP web y la versión completa del paquete utilizados por nuestra web, el estado de los parches para CVE-2026-109618 y CVE-2026-109619, y cómo se ha atendido el aviso de PHP del 23 de octubre de 2026 relativo a CVE-2026-115560. Indiquen también la fecha de activación y la referencia del boletín del proveedor o de la distribución.
Deslice la tabla horizontalmente para leerla.
| Pregunta | Prueba necesaria | Sigue pendiente si… |
|---|---|---|
| ¿Qué sistemas? | Dominios y entornos web asociados | solo se menciona la web principal |
| ¿Qué parche? | Versión del paquete y boletín del proveedor para ambas CVE | la respuesta solo dice «PHP 8» o menciona una actualización del CMS |
| ¿Ya está activo? | Fecha de activación y confirmación del reinicio de los procesos | el paquete solo está disponible para instalar |
| ¿Se revisó el aviso sobre sesiones? | Configuración efectiva o motivo documentado por el que no se aplica | solo se remite a la actualización del 21 de octubre |
| ¿Funciona la aplicación? | Pruebas de acceso, formularios, subidas y tareas relevantes | solo se ha abierto la página de inicio |
Qué demuestran las alertas del WAF y los intentos de ataque
Un cortafuegos de aplicaciones web puede limitar determinadas vías de ataque. No sustituye la actualización de PHP ni la comprobación de la configuración efectiva. Si no es posible actualizar de inmediato, acuerde medidas restrictivas o un aislamiento temporal con el administrador responsable, siguiendo las instrucciones completas del proveedor.
AWS documentó intentos en su telemetría MadPot anteriores a la divulgación pública. También señala que no está claro si esos intentos habrían tenido éxito en sistemas reales. El número de intentos no equivale, por tanto, al número de empresas comprometidas. Del mismo modo, un panel sin alertas no demuestra que una instancia no haya sido afectada. [1] [5] [6]
Cuándo dar por terminadas las comprobaciones
Registre para cada sistema el responsable, el paquete activo, la referencia del proveedor, la fecha de activación y el resultado de las pruebas funcionales. Separe la verificación del parche de la investigación de incidentes: un sistema corregido hoy no explica qué ocurrió antes de actualizarlo.
Si aparecen modificaciones de archivos, procesos inesperados o accesos sospechosos que apunten a una intrusión, conserve los registros disponibles y recurra al equipo responsable de respuesta a incidentes. Una evaluación externa de seguridad puede examinar los sistemas visibles y sus anomalías; sin pruebas adicionales, no puede confirmar de forma concluyente el estado de los paquetes internos ni una posible intrusión.
- Sistemas PHP web relevantes y responsables identificados.
- Parches de las dos CVE originales verificados en la instancia en ejecución.
- Aviso sobre sesiones del 23 de octubre revisado y documentado por separado.
- Funciones esenciales para el negocio comprobadas después del cambio.
- Sistemas pendientes con una próxima acción y un plazo asignados.
- Posibles incidentes investigados por separado; la actualización no se considera una prueba forense de ausencia de intrusión.
Fuentes
- PHP · Critical remote code execution vulnerabilities (21 October 2026)
- PHP · Session upload progress advisory (23 October 2026)
- PHP Foundation · Security release and disclosure background (21 October 2026)
- NHS England · Critical Vulnerabilities in PHP, CC-4875 (21 October 2026)
- NCSC · Critical security issue affecting PHP (21 October 2026)
- AWS · PHP2Shell attempts observed in MadPot (21 October 2026)