PHP2Shell: versiones de PHP afectadas y cómo actualizar tu web
Qué significan CVE-2026-109618 y CVE-2026-109619, cuáles son las primeras versiones corregidas y qué comprobar en el hosting o servidor antes de dar la actualización por terminada.
PHP publicó el 21 de octubre de 2026 actualizaciones para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Pueden permitir ejecución remota de código sin autenticación bajo determinadas condiciones. La prioridad es comprobar qué intérprete ejecuta cada web y aplicar un paquete que incorpore las correcciones.
Información revisada el 22 de octubre de 2026. Para decisiones operativas, contrasta los avisos oficiales y la revisión del paquete de tu proveedor: la disponibilidad y las instrucciones pueden actualizarse.
Qué versiones contienen las correcciones
El anuncio oficial de PHP establece estas primeras versiones corregidas por rama:
- PHP 8.2: 8.2.35; las versiones anteriores de la rama requieren corrección.
- PHP 8.3: 8.3.36; las versiones anteriores de la rama requieren corrección.
- PHP 8.4: 8.4.27; las versiones anteriores de la rama requieren corrección.
- PHP 8.5: 8.5.12; las versiones anteriores de la rama requieren corrección.
PHP 8.1 y anteriores están fuera del soporte normal del proyecto. El aviso ofrece parches mínimos de código para 7.4, 8.0 y 8.1; no equivalen a una actualización automáticamente instalada en cada hosting. Debes confirmar cobertura del proveedor o preparar una migración compatible.
Una distribución puede incorporar el arreglo manteniendo el número base de PHP. Revisa la revisión completa del paquete y su aviso de seguridad antes de clasificarlo solo por el número visible.
Qué ocurre en CVE-2026-109618
El aviso sobre corrupción por falta de memoria describe operaciones que pueden quedar interrumpidas mientras sus estructuras internas están parcialmente inicializadas. Al terminar la petición, PHP puede tratar esos datos incompletos como válidos.
El impacto puede superar un error de aplicación y llegar a ejecutar código con los permisos del proceso web. El aviso documenta una vía en Apache con mod_php que se produce antes de ejecutar código de la aplicación. La exposición y las condiciones varían según el entorno: no debe asumirse que cualquier petición explota automáticamente cualquier servidor.
Actualizar un plugin o proteger el administrador del CMS no modifica por sí solo el intérprete. Una web sencilla también necesita que su entorno esté corregido.
Qué ocurre en CVE-2026-109619
El segundo aviso oficial describe estado interno que conserva referencias a memoria de una petición anterior cuando esa memoria ya se ha liberado. Otra petición atendida por el mismo proceso puede utilizar ese estado antes de que se reinicialice correctamente.
Es un problema de uso de memoria liberada. Su explotación depende del estado y de las operaciones que lo producen y consumen. El aviso contempla diferentes condiciones, por lo que ocultar los errores o cambiar una única opción no debe presentarse como protección completa.
A quién afecta: PHP no es lo mismo que WordPress
El anuncio incluye instalaciones web con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo destacado para mod_php no convierte automáticamente a las demás modalidades en seguras.
WordPress, WooCommerce, Moodle y aplicaciones propias pueden depender de esos intérpretes. El nombre del CMS no determina por sí solo la exposición. Tampoco basta con que PHP esté instalado para concluir qué aplicaciones están accesibles o qué paquete utiliza cada una.
En un servidor pueden convivir varios pools o versiones. En Docker, una imagen puede incorporar su propio PHP aunque el sistema anfitrión tenga otra versión. El inventario debe seguir los procesos que atienden las peticiones reales.
Qué pedir al hosting si no administras el servidor
Solicita confirmación del paquete corregido para tu instalación y de qué sitios o pools cubre. Pregunta cuándo se aplicó y si los procesos antiguos fueron sustituidos. Una respuesta genérica sobre mantenimiento del hosting no identifica necesariamente el entorno de tu cuenta.
Facilita dominios y aplicaciones afectadas, sin enviar contraseñas por un canal abierto. Después verifica los recorridos del negocio: acceso, formularios, pedidos, cursos o integraciones según corresponda.
Si el proveedor administra la capa PHP, la intervención puede centrarse en coordinación y validación de compatibilidad. Cambiar de hosting no es un requisito automático para corregir el problema.
Cómo organizar una actualización controlada
Primero identifica entorno, versión efectiva, origen del paquete y copia recuperable. Decide si aplicarás un parche en la misma rama o si hace falta adaptar la aplicación para migrar a otra.
Prepara un ensayo cuando sea viable y prioriza las funciones críticas. Una emergencia puede exigir una ventana más corta, pero el cambio sigue necesitando un responsable, criterio de validación y registro de lo aplicado.
Después de instalar o reconstruir, sustituye los procesos que conservan el intérprete anterior. Comprueba el resultado desde el entorno web y prueba las funciones acordadas. Actualizar una imagen descargada sin recrear el contenedor no demuestra que el servicio ya use esa imagen.
El informe final debería distinguir instalaciones corregidas, pruebas realizadas y pendientes. Una captura del panel o la versión de consola no describe por sí sola toda la instalación.
Por qué un WAF o una configuración temporal no bastan
PHP indica que actualizar es la solución completa. Las medidas temporales descritas en sus avisos reducen determinadas vías de exposición, pero no convierten una instalación sin parche en segura.
Las restricciones de tráfico pueden formar parte de una medida operativa mientras se actualiza. Deben evaluarse con el proveedor y comprobarse contra la aplicación. No conviene copiar cambios de memoria o límites desde redes sociales sin entender sus efectos sobre disponibilidad y funcionamiento.
¿Actualizar demuestra que nadie entró antes?
No. Un parche evita las condiciones cubiertas por la corrección, pero no elimina automáticamente cambios o accesos que pudieran existir. Tampoco un error de memoria aislado demuestra por sí solo que haya ocurrido una intrusión.
Si aparecen archivos desconocidos, procesos inesperados u otros indicios, hay que delimitar investigación, conservación de evidencias y recuperación. Ese trabajo es diferente de una actualización de compatibilidad y puede requerir especialistas.
Qué papel tuvo la IA
La PHP Foundation describe investigación asistida por IA junto con auditorías, reproducción y correcciones humanas. La utilidad está en ampliar investigación y validación; no significa que cualquier alerta generada por un modelo sea una vulnerabilidad confirmada.
Para quien opera una web, el criterio práctico sigue siendo contrastar avisos, identificar su instalación y verificar el cambio. No hace falta presentar una actualización rutinaria como un servicio de inteligencia artificial.
Ayuda para revisar y actualizar tu instalación
Nuestro servicio de actualización de PHP y compatibilidad incluye inventario, revisión de parches, pruebas y actualización según alcance. También podemos trabajar sobre servidores Linux o coordinarlo con el mantenimiento WordPress.
Para versiones antiguas y planificación posterior, consulta los riesgos de utilizar PHP o Node.js sin soporte. Un aviso urgente puede resolverse con un parche; mantener el entorno después requiere conocer sus dependencias y su ciclo de soporte.