Actualizado: 23 de octubre de 2026. PHP2Shell es el nombre utilizado para dos vulnerabilidades críticas de PHP. La prioridad para quienes gestionan una web es confirmar si su alojamiento ha recibido las correcciones pertinentes. Que la web funcione, muestre un candado o tenga el CMS actualizado no responde a esa pregunta.
¿Qué ha ocurrido?
Las vulnerabilidades son CVE-2026-109618 y CVE-2026-109619. Afectan a la gestión de memoria de PHP y, bajo determinadas condiciones, pueden permitir ejecutar código sin autenticación con los permisos del proceso web. Los informes originales explican el fallo relacionado con el agotamiento de memoria y el fallo por reutilización de estado interno.
Deben evaluarse las instalaciones de PHP que atienden peticiones web; el problema no se limita a un CMS concreto. El comunicado conjunto de ENISA y otras entidades europeas pide identificar las aplicaciones PHP y coordinarse con los proveedores. Una advertencia de vulnerabilidad no demuestra que todas las webs afectadas hayan sufrido ya una intrusión.
¿Qué versiones corrigen las dos vulnerabilidades?
El 21 de octubre de 2026 se publicaron las siguientes versiones de seguridad. Debe utilizarse la rama mantenida adecuada o una versión posterior aprobada. Si el proveedor incorpora correcciones retroportadas, conviene solicitar la referencia de su aviso de seguridad. El número de versión visible puede no contar toda la historia. Consulte el aviso de seguridad de PHP.
| Rama de PHP | Versión de seguridad del 21 de octubre |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Actualización importante del 23 de octubre
PHP ha publicado además un aviso sobre session.upload_progress.enabled y una configuración de sesiones poco habitual, con un próximo informe sobre CVE-2026-115560. Pida al proveedor que revise este aviso además de los parches del día 21. La recomendación actual y sus límites figuran en el archivo oficial de noticias de PHP.

Por qué actualizar WordPress no es suficiente
WordPress es una aplicación que depende, entre otros componentes, de un entorno PHP. Actualizar WordPress, temas y plugins es distinto de actualizar ese entorno. Los requisitos de alojamiento de WordPress identifican PHP como una dependencia separada. Pregunte qué paquete corregido utiliza realmente cada web, incluidos subdominios, tareas programadas e instalaciones independientes.
Lista práctica para responsables de webs
- Defina responsables. Documente quién gestiona servidor, aplicación, copias y decisiones técnicas. En un alojamiento administrado, solicite confirmación escrita en lugar de modificar por su cuenta ajustes que no conoce.
- Identifique los servicios expuestos. Incluya tiendas, formularios, portales de clientes e instalaciones antiguas. Dé prioridad a los sistemas accesibles desde internet, como recomienda el NCSC británico.
- Coordine la actualización. Solicite la referencia del paquete o aviso, la fecha de finalización y la confirmación del entorno activo. Prepare copia y recuperación sin aplazar la protección urgente hasta un futuro rediseño completo.
- Pruebe las funciones importantes. Revise navegación, acceso, búsqueda, formularios y, cuando proceda, el proceso de compra mediante pruebas autorizadas. Registre qué se ha probado realmente y quién ha validado el resultado.
- Gestione la exposición pendiente. Si no hay protección inmediata, consulte con la administración responsable cómo aislar el servicio expuesto. El Cyber Centre canadiense recomienda aislamiento cuando no sea viable aplicar pronto los parches.
¿Y si se sospecha un ataque?
Conserve registros y una cronología, y solicite una revisión profesional de cambios inexplicables en archivos, cuentas o redirecciones. Un parche corrige una vulnerabilidad; por sí solo no determina si una intrusión anterior dejó una puerta trasera. La guía del NCSC pide evaluar posibles compromisos cuando se ha retrasado la protección. No elimine posibles pruebas precipitadamente ni interprete la ausencia de errores visibles como garantía de seguridad.
Preguntas útiles para el proveedor
¿Qué instalación de PHP atiende cada web? ¿Qué aviso del fabricante acredita la corrección? ¿Se ha revisado el aviso adicional del 23 de octubre? ¿Qué queda pendiente y quién lo hará? Estas preguntas aportan más información que una afirmación genérica de que el servidor está «actualizado».
Para planificar una revisión técnica, consulte nuestros servicios WordPress. Acuerde accesos, alcance y responsabilidades antes de empezar. Este artículo no certifica el estado de seguridad de una web concreta.
Fuentes consultadas el 23 de octubre de 2026: avisos de PHP, ENISA, NCSC británico, Cyber Centre canadiense y WordPress.org. Revise sus avisos actuales para conocer novedades posteriores.
