PHP2Shell es el apodo de dos vulnerabilidades en el intérprete de PHP, CVE-2026-109618 y CVE-2026-109619, ambas con puntaje 9,2 en CVSS v4.0. Las dos permiten ejecución remota de código sin autenticación en servidores que atienden solicitudes web con PHP. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre de 2026.
Texto actualizado el 22 de octubre de 2026. El caso sigue en movimiento y las cifras de abajo van a envejecer rápido.
Por qué esta es distinta
Un fallo crítico en PHP no es noticia. Casi cada semana aparece uno en algún CMS, plugin o framework escrito en el lenguaje. PHP2Shell está un piso más abajo. Vive en el propio intérprete, en el código que procesa cada solicitud HTTP antes de entregarle el control a la aplicación.
Eso cambia la cuenta de quién está expuesto. Da igual si el sitio corre WordPress, Laravel, Magento o un sistema casero de 2012. Si el PHP que atiende la solicitud está en una versión vulnerable, la puerta de entrada existe. El equipo de PHP ubicó los hallazgos entre los más graves de la historia del proyecto, según el análisis publicado por Wiz, uno de los tres equipos que descubrieron el problema junto con OpenAI y Calif.
Y PHP está en todas partes. Según W3Techs, el 70,3% de los sitios cuyo lenguaje de servidor se puede identificar usa PHP. De ellos, el 28,9% todavía corre la versión 7 y el 7,9% la versión 5, ramas que ya no reciben corrección oficial del proyecto.
Qué hace cada CVE
Los dos fallos nacen del mismo mecanismo. Cuando PHP se queda sin memoria o encuentra un error fatal en medio de una solicitud, abandona el trabajo con un salto directo fuera del contexto actual, longjmp(), que el equipo del proyecto llama bailout. Algunas partes del código no contaban con esa interrupción y dejaban el estado interno a medio armar.
CVE-2026-109618 es corrupción por falta de memoria. Si el bailout ocurre mientras los datos internos de la solicitud están inicializados a medias, la rutina de limpieza que corre después lee esa memoria como si fuera válida. El aviso oficial dice que varias estrategias de agotamiento de memoria disparan la condición de forma consistente.
CVE-2026-109619 es estado global obsoleto. PHP guarda punteros globales que apuntan temporalmente a la memoria de la solicitud. En algunos escenarios no se limpian al final, o se vuelven a llenar después de limpiarse, y siguen apuntando a memoria ya liberada. La solicitud siguiente, atendida por el mismo proceso, puede usar ese puntero antes de que corra la inicialización normal. Es un use-after-free entre solicitudes, descrito en GHSA-6wmf-4rv5-p3rp.
El disparador remoto más citado es el progreso de carga de sesión (session.upload_progress), activado por defecto desde PHP 5.4. Actualiza el estado de la sesión mientras PHP todavía está leyendo el cuerpo de un POST multipart, cuando la aplicación ni siquiera entró en escena. Según Imperva, tres de las cinco técnicas de explotación conocidas pasan por ahí. watchTowr insiste en que es un camino confirmado, no el único.
No vamos a detallar la cadena de explotación. Para quien defiende, lo que importa cabe en una frase: un atacante sin cuenta alguna envía una solicitud armada a cualquier endpoint que acepte POST y puede salir con ejecución de código en el servidor.
Un detalle ayuda a calibrar el riesgo. La explotación es de complejidad alta, porque la solicitud siguiente tiene que caer en el mismo proceso y ocupar la memoria liberada de la forma justa. Cuando no encaja, el proceso se cae en lugar de ejecutar código. Eso frena un intento puntual. No frena un escaneo masivo que lo intenta miles de veces.
Quién está expuesto
Toda instalación de PHP que atiende solicitudes web, con cualquier SAPI: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Qualys y watchTowr señalan a mod_php como el caso más urgente, porque Apache llama a la rutina de cierre de la solicitud aun cuando el arranque falló. El ataque se completa antes de que corra cualquier código de la aplicación.
| Rama de PHP | Versión corregida | Situación |
|---|---|---|
| 8.5 | 8.5.12 | parche oficial |
| 8.4 | 8.4.27 | parche oficial |
| 8.3 | 8.3.36 | parche oficial |
| 8.2 | 8.2.35 | parche oficial |
| 8.1, 8.0, 7.4 | sin release | backport mínimo en código fuente, o paquete de la distribución |
| 7.3 y anteriores, hasta 5.4 | sin corrección | considerar vulnerable |
Ojo con el número de versión en distribuciones Linux. Red Hat, Ubuntu, Fedora, AlmaLinux y otras aplican el backport sin cambiar la versión upstream, así que un php -v que muestra 8.1 puede estar corregido y uno que muestra un 8.2.30 compilado a mano seguro no lo está. Lo que decide es el aviso de su distribución.
Y está el PHP del que nadie se acuerda. El 22 de octubre, Palo Alto Networks informó que todas las versiones de PAN-OS y Panorama están afectadas, todavía sin corrección. Fortinet evalúa 12 productos y Cisco, 31 productos y servicios en la nube. Firewalls, paneles de router, consolas de gestión, appliances de respaldo: mucho equipo trae un PHP embebido que no aparece en ningún inventario de software.
Línea de tiempo
Sansec había previsto explotación masiva dentro de los 15 minutos posteriores al parche. Se quedó corta. El ataque empezó antes del parche.
Lo que muestra ThreatSensor
ThreatSensor, la base pública de inteligencia de explotación de CSURFACE, ya lista las dos CVE con todo lo recolectado hasta ahora. La foto del 22 de octubre:
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Repositorios de PoC en GitHub | 313 | 10 |
| Explotación activa | confirmada, 133 avistamientos | no detectada hasta ahora |
| Primera señal | avistamiento el 18/10 | PoC publicada el 20/10 |
| Interés del atacante | alto | alto |
| Catálogo KEV de CISA | todavía no | todavía no |
| Ransomware asociado | no | no |
Dos cosas llaman la atención.
La primera es la velocidad. En menos de 48 horas después del parche, CVE-2026-109618 acumuló más de 300 repositorios públicos, entre PoC, escáneres, laboratorios en Docker y reglas de detección. Wiz escribió que los modelos de IA de frontera bajaron de forma sustancial la barrera para convertir el fallo en exploit, y el volumen de código público del primer día coincide con eso.
La segunda es el KEV. El fallo tiene explotación confirmada desde antes del parche y todavía no entró en el catálogo de CISA. Quien prioriza la corrección esperando al KEV está, en este momento, detrás de 133 ataques ya observados. CISA necesita evidencia para catalogar, y la evidencia tarda días. Por eso la cola no puede depender solo del catálogo.
Qué hacer ahora
En orden. El orden importa.
- Preserve la evidencia antes de tocar nada. Logs de PHP y del servidor web, configuración actual, archivos sospechosos. Si el servidor ya fue comprometido, el parche borra el rastro y deja al intruso adentro.
- Actualice a la versión corregida de su rama, o al paquete corregido de su distribución. Las ramas sin soporte necesitan el backport del proyecto o un proveedor de LTS. Actualizar es la única corrección completa, y todas las fuentes coinciden en eso.
- Reinicie todos los workers de PHP. PHP-FPM, Apache, LiteSpeed. El estado obsoleto vive en el proceso, y un proceso viejo sigue vulnerable con el binario nuevo en disco.
- Priorice
mod_phpexpuesto a internet, después las demás SAPI expuestas, después el resto. - Busque señales de compromiso en los servidores que estuvieron expuestos desde el 17 de octubre: web shell nueva, cron inesperado, cuenta creada, proceso hijo extraño de PHP, conexión saliente que antes no existía.
- Lo que no se pueda corregir hoy sale de internet o queda detrás de un control de acceso. Es la recomendación del NCSC.
Mitigación temporal, si no puede actualizar ya
Estas configuraciones cierran parte de los caminos. Ninguna reemplaza al parche, y watchTowr advierte que los cambios vía .ini no cubren toda la superficie.
; desactiva el disparador usado por tres de las cinco técnicas conocidas
session.upload_progress.enabled = Off
; PHP 8.5
fatal_error_backtraces = Off
En PHP-FPM, pm.max_requests = 1 hace que cada proceso termine después de una solicitud, lo que impide que el estado obsoleto pase a la siguiente. El costo en rendimiento es alto y requiere prueba. Imperva sugiere además opcache.enable = 0 como medida temporal, también con prueba previa. Desactivar session.upload_progress no resuelve por completo CVE-2026-109618, porque la corrupción por falta de memoria está en el núcleo de Zend.
El WAF ayuda mientras el parche no llega. Cloudflare, Imperva y otros ya publicaron reglas para los vectores conocidos. Una variante nueva pasa por una regla vieja, así que trate el WAF como un puente.
Señales para buscar en los logs
- POST multipart con el campo
PHP_SESSION_UPLOAD_PROGRESS, sobre todo con cuerpo demasiado grande o una cantidad anormal de campos. - Errores
Allowed memory size of ... bytes exhaustedseguidos de la caída de un worker. - Cookie
PHPSESSIDde tamaño absurdo en la respuesta. Una de las técnicas filtra cerca de 67 KB de memoria del proceso por esa cabecera. - Ráfagas de solicitudes al mismo endpoint desde una sola IP, típicas de quien intenta acertar al mismo proceso varias veces.
La pregunta que la mayoría de las empresas no puede responder hoy
Todo equipo de seguridad recibió la misma orden esta semana: corregir PHP. Esa orden supone una lista. Qué servidores corren PHP, en qué versión, expuestos a qué.
La lista que existe es la del inventario oficial, y cubre lo que alguien se acordó de registrar. El PHP que va a ser explotado esta semana vive en otro lado. El micrositio de la campaña de 2019 que nadie apagó. El ambiente de pruebas que se levantó con una integración y quedó con IP pública. El blog institucional en un hosting que marketing contrató con la tarjeta corporativa. El dominio que llegó de regalo con una adquisición. El panel del appliance que TI nunca pensó como servidor PHP.
Eso es shadow IT, y es la parte de la superficie que más pesa en un fallo como PHP2Shell, porque es justamente la que corre las versiones más viejas. El 7,9% de sitios que siguen en PHP 5 no está en el servidor principal de nadie.
Peor que el activo olvidado es el activo que nadie sabe que no conoce. Al olvidado alguien lo conoció alguna vez y se lo puede recordar. El desconocido salió al aire por un camino que no pasó por seguridad, y ninguna pregunta interna llega hasta él, porque nadie sabe que tiene que preguntar.
En dos casos documentados por CSURFACE, una institución financiera mediana tenía 160 activos externos en el inventario oficial y el descubrimiento encontró 271. Una startup de SaaS B2B monitoreaba 85, y eran 570. El coordinador de ciberseguridad de una de las mayores empresas de Brasil resumió el efecto en una frase: descubrir que monitoreábamos apenas el 15% de nuestra superficie de ataque real.
En una empresa así, corregir el 100% de la lista es corregir el 15% del problema.
Cómo los clientes de CSURFACE se anticipan a este tipo de problema
Para quien tiene CSURFACE funcionando, la pregunta "dónde tenemos PHP expuesto y en qué versión" ya tiene respuesta antes de que el fallo tenga nombre. El trabajo que la responde corre todo el tiempo, y la semana empieza por la corrección en lugar de la planilla.
Visión completa de la superficie
El descubrimiento continuo mapea la superficie externa a partir de lo público: dominios, subdominios, certificados, bloques de IP, registros DNS, empresas del grupo. El punto de partida es el nombre de la empresa. La lista que la empresa entregó sirve de comparación, para mostrar lo que le faltaba. Cada activo encontrado se identifica por tecnología, lo que incluye PHP y su versión cuando el servidor la revela, la SAPI cuando se puede inferir y los appliances que traen PHP embebido.
Shadow IT y lo que nadie sabía que existía
Ahí aparecen el micrositio viejo, el ambiente de pruebas con IP pública, el panel del appliance y el dominio de la adquisición. Un activo descubierto sin dueño se convierte en un ítem con contexto: dónde está, cuándo apareció, qué corre, quién probablemente responde por él. Quien le avisa al cliente que el servidor olvidado existe es CSURFACE, antes de que el atacante llegue a él.
Inteligencia de explotación cruzada con el inventario real
ThreatSensor sigue cada CVE con señal de explotación, y la capa de threat intel cruza esa señal con lo que el descubrimiento ya sabe. Cuando una CVE como CVE-2026-109618 empieza a verse en ataques, los activos del cliente que corren la tecnología afectada suben al tope de la cola por la señal de explotación. Sin esperar al KEV y sin depender del CVSS.
Detección rápida, con prueba
La validación continua confirma, de forma no destructiva, si el activo está de verdad expuesto en las condiciones en que está. La cola deja de ser "todos los servidores con PHP" y pasa a ser "estos, que tienen camino abierto ahora", con evidencia para que el equipo de infraestructura actúe y para que el gerente reporte al directorio. Después del parche, la misma validación confirma que la corrección funcionó.
El activo que aparezca mañana también entra
Corregir todo este jueves no protege contra el servidor que alguien levanta el martes siguiente con una imagen Docker vieja. El monitoreo continuo detecta ese servidor el día en que aparece. El pentest anual recién lo vería el año que viene.
PHP2Shell va a quedar corregida, como pasó con Log4Shell y React2Shell. El próximo fallo de este tamaño va a encontrar la misma pregunta sin respuesta en quien no sabe lo que tiene en internet.
Si quiere saber hoy dónde está el PHP de su empresa, incluido lo que no figura en ninguna lista, el análisis preliminar gratuito de CSURFACE le entrega la primera foto de su superficie externa.
Preguntas frecuentes
¿Qué es PHP2Shell?
Es el apodo de dos vulnerabilidades en el intérprete de PHP, CVE-2026-109618 y CVE-2026-109619, divulgadas el 21 de octubre de 2026 con puntaje 9,2 en CVSS v4.0. Las dos permiten ejecución remota de código sin autenticación, disparada por una solicitud HTTP antes de que corra el código de la aplicación.
¿Qué versiones de PHP son vulnerables?
Todas las anteriores a 8.5.12, 8.4.27, 8.3.36 y 8.2.35, en sus respectivas ramas. Las ramas 8.1, 8.0 y 7.4 recibieron solo un backport en código fuente. Las versiones más antiguas, hasta la 5.4, deben tratarse como vulnerables y sin corrección oficial. En paquetes de distribuciones Linux, revise el aviso de su distribución, porque el backport puede conservar el número de versión anterior.
¿PHP2Shell ya se está explotando?
Sí. Amazon registró un intento de explotación el 17 de octubre, cuatro días antes del parche. ThreatSensor muestra explotación confirmada de CVE-2026-109618, con 133 avistamientos al 22 de octubre, y más de 300 repositorios públicos de PoC y herramientas. Para CVE-2026-109619 todavía no se detectó explotación activa, pero hay PoC pública desde el 20 de octubre.
¿Desactivar session.upload_progress lo resuelve?
Reduce el riesgo, sin resolverlo. La configuración elimina el disparador de tres de las cinco técnicas conocidas, pero la corrupción por falta de memoria de CVE-2026-109618 está en el núcleo de PHP y tiene otros caminos. La única corrección completa es actualizar y reiniciar todos los workers.
Mi sitio usa WordPress (o Laravel, o Magento). ¿Estoy expuesto?
Si el PHP que corre por debajo está en una versión vulnerable, sí. El fallo está en el intérprete y se alcanza antes de que corra la aplicación, así que el framework o el CMS no cambian nada. Actualizar WordPress no corrige PHP2Shell. Actualizar PHP, sí.
¿Cómo encuentro todos los servidores con PHP que mi empresa tiene en internet?
El inventario interno responde por lo que se registró. Para lo que está publicado sin registro, como ambientes de prueba, micrositios viejos, dominios de adquisiciones y appliances con PHP embebido, hay que mirar desde afuera, a partir de lo que es público sobre la empresa. Eso es lo que hace el descubrimiento de activos, y es el punto de partida de la gestión continua de la exposición.