PHP2Shell encendió una alerta de seguridad en el ecosistema de hosting. El nombre agrupa dos vulnerabilidades del motor de PHP que pueden permitir ejecución remota de código sin autenticación. Su importancia va más allá de un CMS o un plugin: comprometen el software que interpreta las aplicaciones del servidor.
Ambas recibieron una calificación oficial CVSS v4.0 de 9,2 sobre 10, crítica. Conviene entender qué ocurre, qué instalaciones están expuestas y por qué actualizar PHP es una tarea urgente. Información revisada al 27 de octubre de 2026.
Qué es PHP2Shell y por qué preocupa
PHP2Shell reúne CVE-2026-109618 y CVE-2026-109619. La primera afecta el tratamiento de errores por falta de memoria; la segunda, el estado interno que puede persistir entre solicitudes. No son dos nombres para una vulnerabilidad de WordPress: son problemas del propio intérprete.
La ejecución remota de código, o RCE, significa que un tercero puede lograr que el proceso del servidor ejecute instrucciones bajo su control. En estos casos no se requiere una cuenta previa. Eso no significa que cualquier petición funcione contra cualquier instalación: la posibilidad de explotación depende del entorno y de la ruta alcanzable. Canonical resume el alcance y la severidad.
Cómo surgió: una investigación que venía de años anteriores
Según la reconstrucción de The PHP Foundation, los primeros indicios del problema de memoria aparecieron durante el trabajo asociado a una auditoría externa de 2024, realizada por Quarkslab. Resolverlo implicaba decisiones difíciles de compatibilidad, rendimiento y comportamiento de extensiones.
En 2026, Calif, OpenAI y Wiz aportaron investigaciones y rutas de ataque que permitieron dimensionar el impacto. Calif comenzó su auditoría el 30 de julio y reportó ejecución remota el 11 de agosto; Wiz aportó hallazgos el 24 de agosto y OpenAI, vectores adicionales el 18 de septiembre. La investigación asistida por IA formó parte del trabajo, junto con análisis y revisión humana.
La divulgación pública y las actualizaciones de emergencia
El 20 de octubre circularon los identificadores antes de la divulgación coordinada. Después se difundió un video de demostración publicado por error. El equipo adelantó la entrega prevista para el 22 de octubre al 21 de octubre de 2026. La puntuación oficial es 9,2, pese a que inicialmente circuló otra cifra. La urgencia de actualizar responde al impacto potencial; una demostración o un intento bloqueado no prueban por sí solos una intrusión exitosa.
Cómo funciona CVE-2026-109618: corrupción al agotar memoria
PHP necesita reservar memoria para procesar cada solicitud. Algunas estructuras internas atraviesan un período en el que existen, pero todavía no están completamente inicializadas. Si una reserva falla en ese momento, el tratamiento del error puede interrumpir la operación antes de dejar esas estructuras en un estado consistente.
La fase de cierre de la solicitud puede después utilizar los datos incompletos como si fueran válidos. El resultado excede un error de aplicación: puede convertirse en corrupción de memoria y ejecución de código.
En Apache con mod_php se confirmó una ruta que ocurre durante el procesamiento inicial de la petición, antes de ejecutar el código del sitio. Por eso proteger solamente el formulario de login no resuelve el problema. La corrección cambia el manejo de falta de memoria para evitar interrupciones en puntos inseguros. Aviso técnico de CVE-2026-109618.
Cómo funciona CVE-2026-109619: referencias que sobreviven a una solicitud
Los procesos de PHP suelen atender varias solicitudes durante su vida útil. Cierto estado global puede apuntar a memoria perteneciente a una petición concreta. Esa referencia debe restablecerse antes de liberar la memoria.
Si un error interrumpe la limpieza, el proceso puede conservar una referencia obsoleta. Otra petición atendida por el mismo proceso puede usarla antes de que la inicialización normal la reemplace. Se produce un use-after-free: acceso a memoria después de haber sido liberada.
Los casos documentados incluyen estado de errores y procesamiento de sesiones relacionado con el progreso de cargas. Se validaron rutas en mod_php y PHP-FPM; sus condiciones son distintas. Tener múltiples procesos puede reducir la probabilidad por intento, pero no elimina el defecto. El parche restablece el estado que no debe sobrevivir entre solicitudes. Aviso técnico de CVE-2026-109619.
Qué podría hacer un atacante
Los impactos documentados incluyen ejecución de código, exposición de memoria y caída del servicio. A partir de un compromiso, las consecuencias concretas dependen de los permisos del proceso y de los recursos a los que tenga acceso. JFrog analiza estos impactos.
- Confidencialidad: podrían quedar expuestos archivos de configuración, credenciales o datos accesibles desde la aplicación.
- Integridad: podría alterarse contenido que el usuario del servicio tenga permiso para escribir.
- Disponibilidad: la caída de procesos puede interrumpir la atención de solicitudes.
RCE no equivale automáticamente a obtener root. El alcance inicial corresponde a los privilegios del proceso web. Separar usuarios, limitar permisos y aislar sitios ayuda a contener daños, aunque no reemplaza la corrección de PHP.
¿Afecta a todas las versiones y a cualquier servidor?
La advertencia abarca instalaciones de PHP que atienden peticiones web, incluyendo PHP-FPM, Apache con mod_php, CGI, FrankenPHP y LiteSpeed. El riesgo no se limita a Windows, a un panel de hosting ni a una aplicación determinada. El proyecto PHP señaló a mod_php como el escenario de mayor riesgo.
Decir “todas las versiones” necesita contexto: las ramas sin corregir deben revisarse, pero un paquete que ya incorpora el parche no sigue siendo vulnerable solo por conservar un número antiguo. Tampoco se debe confundir una rama histórica con una configuración explotable de manera idéntica. Aviso oficial de PHP.
Qué versiones incluyen las correcciones
El 21 de octubre se publicaron PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12, según los anuncios de las nuevas versiones. Para cada rama, hay que instalar esa versión o una posterior que incluya las correcciones.
PHP 7.4, 8.0 y 8.1 están fuera del soporte ordinario del proyecto. Se facilitaron parches mínimos para esas ramas y existen distribuidores con actualizaciones retroportadas, o backports. Hay que comprobar el paquete y el aviso del proveedor, no solo el resultado de php -v. Recibir este parche puntual no devuelve a una rama antigua su soporte general.
La advertencia adicional sobre sesiones del 23 de octubre
PHP publicó después un aviso sobre una ruta poco habitual relacionada con el progreso de cargas y aplicaciones que cambian el serializador de sesiones durante la ejecución. Recomendó deshabilitar session.upload_progress.enabled hasta la siguiente versión correctiva; quienes ya aplicaron esa medida deben mantenerla. No significa que el parche inicial sea inútil: subraya la importancia de seguir los avisos posteriores del proyecto.
Por qué actualizar WordPress o activar un WAF no alcanza
Mantener actualizado el sitio sigue siendo necesario, pero un cambio en el CMS no sustituye la actualización del intérprete. La corrección debe llegar al PHP que ejecuta la aplicación.
Cloudflare desplegó reglas contra intentos conocidos y observó cambios en las solicitudes de ataque para intentar evitarlas. Estas defensas pueden reducir exposición, pero dependen de la cobertura del tráfico y de los patrones detectados. Un WAF es una capa adicional; no convierte un PHP sin parche en un PHP corregido. Detalle de las protecciones de Cloudflare.
Cómo comprobar que la actualización realmente quedó aplicada
Una revisión práctica debe contemplar todo el recorrido de la aplicación:
- Identificar las ramas instaladas: un servidor puede tener varias versiones y asignaciones diferentes por dominio.
- Comprobar el origen del paquete: confirmar en el aviso del proveedor que incorpora ambas correcciones.
- Revisar el PHP del sitio: el intérprete de consola puede ser distinto del que atiende la web.
- Renovar los procesos: después de actualizar, reiniciar los servicios correspondientes para cargar los componentes corregidos.
- Validar funcionamiento: revisar páginas, tareas programadas, formularios y registros de errores.
Canonical recuerda que instalar paquetes puede requerir reiniciar la aplicación o el servidor para que los componentes nuevos se utilicen. Conviene documentar qué servicio se actualizó y cuándo, en lugar de asumir que una actualización descargada ya protege todos los procesos.
Qué hacer si todavía no se puede actualizar
Las mitigaciones temporales deben decidirse con el administrador. Limitar cargas y tamaños de peticiones puede reducir algunas rutas. Los avisos también contemplan cambios de configuración específicos, pero no existe una combinación genérica que sustituya el parche completo.
No recomendamos copiar ajustes aislados sin analizar su efecto. Por ejemplo, eliminar un límite de memoria puede modificar otra protección operativa y no garantiza seguridad. La prioridad es obtener un paquete corregido, aplicarlo y validar la instalación.
Actualizar y revisar un posible incidente son tareas diferentes
Corregir PHP evita conservar el defecto, pero no demuestra que antes no haya existido una intrusión. Si hay indicios, conviene preservar registros, revisar archivos modificados, procesos y accesos, y evaluar la rotación de secretos que pudieran haberse expuesto. Estas son recomendaciones de respuesta, no una afirmación de que todos los servidores vulnerables hayan sido comprometidos.
También es recomendable mantener copias de seguridad verificadas y planificar la migración de aplicaciones que dependen de ramas sin soporte. Un parche de emergencia resuelve un incidente concreto; el mantenimiento sostenido reduce la próxima ventana de riesgo.
La respuesta de XWEB: actualizaciones en menos de 24 horas
En XWEB aplicamos las actualizaciones y correcciones de seguridad desde PHP 7.4 hasta la versión estable más reciente afectada, en menos de 24 horas desde que se dio a conocer PHP2Shell.
Para las ramas antiguas, la protección corresponde a la incorporación de los parches específicos, no a que PHP 7.4 haya vuelto a recibir soporte general. Seguimos recomendando migrar las aplicaciones a versiones mantenidas y compatibles con cada proyecto.
Si tenés dudas sobre la versión que utiliza tu sitio o necesitás ayuda para planificar una migración, contactá al equipo de XWEB. La seguridad del hosting también depende de reaccionar a tiempo y mantener actualizado el entorno que ejecuta cada aplicación.
