Ciberseguridad
PHP2Shell: por qué el login de tu web no frena estos fallos de PHP
Qué son CVE-2026-109618 y CVE-2026-109619, qué versiones de PHP las corrigen y qué demuestran los exploits públicos. Riesgo real y pasos para actualizar.
Hay motivos para actualizar hoy, no para dar tu web por perdida
PHP2Shell requiere una actualización urgente si tu servidor atiende peticiones con una versión de PHP sin parchear. Son dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que pueden permitir ejecutar código sin iniciar sesión. El problema está en el motor de PHP, por debajo de WordPress, Laravel o la aplicación que hayas escrito.
Los parches salieron el 21 de octubre de 2026. Eso no significa que toda web con PHP haya sido comprometida ni que todos los despliegues sean igual de fáciles de atacar. Sí significa que un formulario de login o un código de aplicación bien revisado no sustituyen el parche. En algunos escenarios el fallo aparece antes de ejecutar ese código.
Qué se rompe dentro de PHP
Un worker es un proceso que atiende peticiones. Normalmente libera la memoria de una al terminar y queda preparado para la siguiente. Aquí fallan algunas de esas transiciones. No se trata de que alguien escriba PHP en un formulario y el servidor lo ejecute directamente.
En CVE-2026-109618, un error de falta de memoria puede interrumpir una operación cuando sus datos internos todavía están a medio inicializar. PHP utilizaba longjmp() para salir de ese contexto. La limpieza posterior podía tratar aquellos datos incompletos como válidos. Con una disposición adecuada de memoria, el efecto puede llegar a ejecución de código.
En CVE-2026-109619, un estado que conserva el worker puede seguir apuntando a memoria ya liberada. Una petición posterior, atendida por ese mismo proceso, llega a utilizarlo antes de reinicializarlo. Es un use-after-free: utilizar una referencia cuando aquello a lo que apuntaba ya no existe.
Imagina una ficha interna que guarda la dirección de un expediente. Se destruye el expediente, pero la ficha sigue ahí. El siguiente trámite consulta esa dirección y encuentra otra cosa. Es una analogía del estado obsoleto; el ataque real depende del ciclo de vida y de la memoria del proceso.
¿Hay exploits públicos que funcionen?
Sí hay repositorios públicos que ofrecen código de explotación. Stonlifer/php2shell publica un laboratorio para PHP 8.4.26. Su README exige condiciones como Apache prefork de un solo worker y ajustes concretos del entorno. Es una demostración declarada para una configuración determinada, no un exploit universal.
El matiz importa. En su informe del 27 de octubre, Wiz diferencia intentos que agotaron memoria sin completar la explotación de herramientas etiquetadas como PHP2Shell que en realidad necesitan otro fallo de inclusión de archivos. Su propia telemetría no registró una cadena completa exitosa; también recoge evidencia pública en honeypots con una configuración favorable. Ninguna de esas observaciones garantiza que tu instalación esté a salvo.
AWS detectó intentos en sus sensores desde el 17 de octubre, antes de la publicación. Por tanto, tampoco estamos ante un riesgo puramente teórico. Intento, caída del proceso y ejecución de código son resultados distintos y conviene exigir esa distinción al leer titulares o repositorios.
Para comprobación existe PHP2Shell-Check, de CovertSwarm Labs. Su documentación explica un límite útil: si no consigue información suficiente, devuelve INCONCLUSIVE. Ocultar la versión o no recibir una alerta no acredita que el servidor esté parcheado.
Qué versiones lo corrigen y qué debes actualizar
Estas son las versiones de origen que incorporaron los parches de ambos CVE. Usa estas o una posterior corregida de tu rama. Si tu distribución aplica backports, comprueba su aviso y la revisión del paquete: una versión base antigua puede llevar el arreglo sin cambiar de número principal.
| Rama PHP | Parche publicado el 21 de octubre |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
El parche tiene que llegar al proceso que atiende la web
Comprueba el PHP de cada pool, contenedor o sitio. El resultado de php -v en tu terminal puede corresponder a otro ejecutable distinto del que usa PHP-FPM o Apache. En un hosting gestionado, confirma con el proveedor la versión o el paquete corregido que sirve ese dominio.
Por ejemplo, una tienda puede tener PHP actualizado en el host y seguir usando una imagen Docker antigua. Debes reconstruir con una base corregida, desplegarla y sustituir los workers anteriores. Después comprueba la versión del servicio y prueba login, sesiones y subidas normales. Actualizar un plugin, Composer o PHP en tu portátil no cambia ese contenedor.
El arreglo de OOM cambia la salida abrupta por una gestión diferida en un punto seguro y una terminación inmediata si se alcanza otro umbral. El segundo parche restablece el estado que no debe sobrevivir entre peticiones. Se corrige el motor; no se añade una validación al formulario de tu aplicación.
PHP 8.1 y ramas anteriores ya no tienen mantenimiento ordinario del proyecto. Revisa si tu proveedor ofrece un backport acreditado y prepara la migración a una rama soportada.
Dos avisos posteriores que conviene distinguir
El 23 de octubre PHP recomendó desactivar session.upload_progress.enabled hasta la siguiente actualización ordinaria por otra vía poco habitual, CVE-2026-115560. Requiere cambiar en ejecución el serializador de php_binary o php_serialize a php antes de session_start(), con el progreso de subida activo. No afecta del mismo modo a toda instalación recién parcheada.
El 26 de octubre se publicaron además paquetes de Windows 8.5.12-1, 8.4.27-1, 8.3.36-1 y 8.2.35-1 por un fallo distinto de Brotli, CVE-2026-111497. El número del runtime no cambia. Si utilizas esos binarios, revisa también el paquete: el descompresor puede alcanzarse mediante cURL cuando se activa la descompresión automática de respuestas.
Qué hacer si todavía no puedes parchear
Las medidas de configuración reducen caminos concretos, pero no sustituyen la actualización. Desactivar session.upload_progress.enabled y reiniciar todos los workers bloquea las vías de sesión confirmadas. Debe aplicarse antes de procesar la petición, mediante php.ini o configuración administrativa; hacerlo con ini_set() o confiar en .user.ini de FPM no cubre ese momento.
Un WAF y límites de petición pueden reducir exposición, pero no acreditan que el motor sea seguro. Prioriza el parche o restringe temporalmente el acceso al servicio mientras lo preparas. Apache con mod_php tiene un escenario demostrado especialmente preocupante; utilizar FPM no basta para descartar los fallos.
Si el servicio estuvo expuesto sin parchear, revisa registros, cambios de archivos y procesos inesperados. AWS recomienda investigar desde al menos el 17 de octubre. Una ráfaga de errores 500 no prueba por sí sola una intrusión. Si encuentras indicios sólidos de compromiso, actualizar PHP no elimina lo que ya haya instalado un atacante.