PHP2Shell: un fallo RCE de PHP desencadena millones de intentos de explotación (CVE-2026-109618)

Resumen

PHP2Shell es el nombre que investigadores y proveedores utilizan para dos fallos de ejecución remota de código a nivel del motor en el ciclo de vida de las solicitudes PHP.

• Dos fallos de seguridad de memoria en el propio motor PHP, CVE-2026-109618 (la gestión del agotamiento de memoria corrompe el estado de la solicitud) y CVE-2026-109619 (el estado global obsoleto sobrevive hasta la siguiente solicitud), permiten a un atacante remoto sin autenticación ejecutar código como el proceso de trabajo web. Los fallos están por debajo de cualquier aplicación: una instalación limpia de WordPress, Drupal o Joomla está expuesta del mismo modo.
• Todas las instalaciones PHP sin corregir que atienden solicitudes web están afectadas: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de seguridad PHP clasifica ambos como críticos, CVSS v4.0 9.2, y confirmó ejecución remota de código completa por HTTP contra mod_php con límites predeterminados.
• Los intentos de explotación se dispararon horas después de la divulgación y alcanzaron millones el 22 de octubre (Cloudflare). Los honeypots MadPot de Amazon detectaron un primer intento el 17 de octubre, cuatro días antes de la divulgación.
• CISA añadió ambos fallos a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 26 de octubre, con fecha límite federal de aplicación de parches el 29 de octubre.
• El 24 de octubre, Adel Karimi confirmó ejecución remota de código contra honeypots: «Ahora se confirma RCE con divulgación de memoria utilizable, no solo una caída seguida de un proceso sospechoso». Un exploit público ganó el reto StealMyBitcoin el 25 de octubre. A 27 de octubre, no se ha confirmado públicamente el compromiso de ninguna víctima real (Sophos, Previdian, Wordfence).
• Actualice ahora a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35; la inclusión en KEV impone un plazo. PAN-OS 10.2, 11.1, 11.2, 12.1 y 12.2 incorporan PHP afectado; Palo Alto Networks ha publicado 11 ramas con correcciones urgentes y espera el resto para el 30 de octubre. Si no puede actualizar hoy, las mitigaciones siguientes solo dan tiempo.

¿Estoy afectado?

Está afectado si se cumplen ambas condiciones:

• La instalación ejecuta PHP 5.4 o posterior y atiende solicitudes web mediante PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed. Las instalaciones exclusivamente CLI que nunca analizan cuerpos de solicitudes quedan fuera de las rutas demostradas.
• Para PHP 8.2 a 8.5, la versión es anterior a la publicación de seguridad del 21 de octubre de 2026 de su rama. PHP 7.4, 8.0 y 8.1 han llegado al final de su vida útil y están afectados en principio; el equipo de seguridad publicó adaptaciones mínimas del parche a su código. PHP 5.4 a 7.3 también están afectados en principio, según Sysdig, sin adaptación del proyecto PHP.

Aunque su aplicación nunca llame a las API de cuerpos de solicitudes, no suponga que está protegida: el exploit confirmado de mod_php se activa durante el inicio de la solicitud, antes de que se ejecute cualquier código específico de la aplicación.

Compruebe qué ejecuta en el host y dentro de cada contenedor e imagen de CI:

php -v
php -i | grep -E '^(memory_limit|post_max_size|session.upload_progress.enabled)'
apachectl -M 2>/dev/null | grep -i php      # Apache mod_php loaded?
php-fpm -v                                  # FPM pool version
docker ps --format '{{.Image}}' | sort -u   # images behind running containers
docker exec <container-name> php -v         # PHP inside a running container
docker images | grep php                    # locally pulled PHP image tags

Para CI, compruebe la imagen que realmente construye la canalización, por ejemplo docker run --rm <registry>/<image>:<tag> php -v.

Palo Alto Networks enumera PAN-OS 10.2, 11.1, 11.2, 12.1 y 12.2 como afectados por el PHP incorporado. La exposición se limita al plano de gestión: la interfaz web HTTPS y la API XML. PAN-OS las sirve en la interfaz de gestión o en cualquier interfaz del plano de datos con un perfil de gestión asociado. Los portales y gateways GlobalProtect, Clientless VPN y el portal cautivo no están afectados.

A 27 de octubre se han publicado once ramas con correcciones urgentes; la lista completa está en la tabla del aviso y en la cronología siguiente. Las nueve ramas restantes tienen fechas estimadas del 27 al 30 de octubre de 2026. Palo Alto clasifica el impacto en su propio producto como alto, CVSS 8.7. Su SaaS Cortex XCORE estuvo afectado y se corrigió el 21 de octubre.

La exposición está medida, no estimada. Qualys analizó datos anonimizados de 12.000 clientes:

• Solo se actualizaron 199.000 instancias PHP en las 12 horas posteriores a la divulgación.
• Unos 110 millones de instancias, el 71 por ciento de las instancias PHP medidas por Qualys, ejecutan PHP 5.4 a 8.1 sin soporte, que nunca recibirán un parche del proveedor.
• Otros 44 millones ejecutan ramas con soporte cuyas correcciones aún no se habían aplicado.

Censys sigue la parte expuesta a Internet de ese retraso en un panel público y contabilizaba más de 32.51 millones de servicios PHP aún con una versión afectada a 27 de octubre.

¿Cómo lo corrijo?

Actualice a la versión corregida de su rama. Prefiera los paquetes de su distribución para mantener coherentes las integraciones SAPI:

# Debian and Ubuntu (upgrades every installed php* package and Apache's mod_php)
sudo apt update
sudo apt install --only-upgrade $(dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/ {print $2}')
# RHEL, CentOS Stream, Rocky, Alma, Fedora
sudo dnf update 'php*'
# Containers: rebuild on a fixed tag and recreate the service
docker pull php:8.4.27
docker compose build --pull && docker compose up -d

Reinicie todos los procesos de trabajo PHP y el servidor web tras actualizar. Si compila desde el código o ejecuta una rama sin soporte, utilice las adaptaciones del equipo de seguridad para 7.4, 8.0 y 8.1 o migre a una rama con soporte.

Si aún no puede actualizar, estas medidas del aviso PHP reducen rutas de ataque concretas. Ninguna hace segura una instalación, y el aviso lo afirma explícitamente.

Para CVE-2026-109618, elimine el límite de memoria controlable y reduzca la superficie de entrada:

; PHP-FPM pool (for example www.conf); php_admin_value stops apps from overriding it
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M   ; use 32M if you need file uploads

Con Apache mod_php, establezca los mismos valores en la configuración de Apache:

php_admin_value memory_limit -1
php_admin_value post_max_size 8M

Además:

• Mantenga upload_max_filesize por debajo de post_max_size.
• Imponga límites en el servidor web o proxy al tamaño de solicitud decodificada, número de campos de entrada, número de partes multipart, número de cabeceras y profundidad de anidamiento, incluidas solicitudes sin un Content-Length utilizable.

No utilice RLIMIT_AS ni RLIMIT_DATA: forzar el fallo de mmap() alcanza directamente la ruta vulnerable de salida abrupta.

Para CVE-2026-109619, en php.ini:

session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

En un grupo PHP-FPM, utilice la sintaxis del grupo y reinicie los procesos de trabajo:

php_admin_value[session.upload_progress.enabled] = 0
; PHP 8.5 only:
php_admin_value[fatal_error_backtraces] = 0

Tres pasos más:

• No confíe en ini_set(), .user.ini, error_reporting, @ ni display_errors=Off; el aviso afirma que el consumidor se ejecuta antes de que tengan efecto.
• Elimine ajustes INI no válidos u obsoletos aplicados por solicitud y corrija los errores fatales y tiempos de ejecución agotados alcanzables por atacantes.
• Considere pm.max_requests = 1 si el rendimiento lo permite.

Ese ajuste FPM solo ayuda contra CVE-2026-109619 porque impide que una segunda solicitud alcance el mismo proceso de trabajo; no protege contra CVE-2026-109618, que se activa y consume dentro de una sola solicitud.

¿Cuál es la causa raíz?

Ambos fallos son consecuencia del mecanismo de salida abrupta de PHP, un longjmp() que aborta una solicitud desde las profundidades del motor, combinado con estado que un proceso de trabajo persistente conserva entre solicitudes.

CVE-2026-109618: PHP aborta la solicitud con longjmp() ante un error de memoria insuficiente (OOM). A veces se puede acceder a la memoria de la solicitud antes de inicializarla por completo. Si entonces falla una asignación, el aviso afirma que «PHP no tiene debidamente en cuenta la salida anticipada y deja la memoria de la solicitud en un estado no válido. La asignación fallida no tiene por qué estar relacionada con la memoria no válida. El procedimiento de cierre de la solicitud puede entonces leerla o tomar decisiones basadas en ella».

El atacante no necesita una falta de memoria real. Varias particularidades del análisis multipart permiten que una sola solicitud HTTP agote memory_limit a voluntad:

• Un cuerpo multipart sin Content-Length utilizable supera la comprobación inicial de post_max_size mientras sigue proporcionando datos.
• Una sola parte puede contener un número ilimitado de cabeceras cuya representación en memoria es mucho mayor que el formato transmitido.
• Los controles de archivos vacíos crean matrices de metadatos sin contar para max_file_uploads.

CVE-2026-109619: el proceso de trabajo conserva estado global (de errores, sesiones, objetos y extensiones) que apunta temporalmente a memoria propiedad de la solicitud y debe restablecerlo antes de liberar el montón de esta. Dos modos de fallo rompen ese restablecimiento:

• Un error fatal, incluido agotamiento de memoria o Maximum execution time exceeded, puede abandonar una operación antes de restablecerla.
• Un diagnóstico tardío no fatal puede volver a rellenar estado de error ya limpiado.

Después se libera el montón mientras la variable global del proceso de trabajo aún lo referencia.

Dos consumidores confirmados leen ese estado obsoleto antes de inicializarse la siguiente solicitud:

• Advertencias generadas al aplicar ajustes INI. Con mod_php, .htaccess y php_value de Apache se ejecutan antes de php_request_startup().
• La gestión del progreso de carga de sesiones, que alcanza el estado de sesión antes de su inicialización ordinaria. Está habilitada de forma predeterminada y no necesita llamar a session_start().

¿Cómo se explota?

El ataque CVE-2026-109618 es una solicitud multipart manipulada que agota memory_limit durante el inicio. Una asignación fallida provoca una salida abrupta cuando la memoria de la solicitud está a medio inicializar, y el cierre de mod_php lee después ese estado no válido antes de ejecutar código de aplicación.

Existe una PoC pública, pero está calibrada para la compilación Alpine del reto StealMyBitcoin y aborta en otras compilaciones. Ningún exploit publicado funciona directamente contra compilaciones de producción. VulnCheck documenta su propia cadena, que sí funciona en sistemas x86-64 configurados para producción, descrita a continuación. También hay herramientas funcionales en infraestructura de atacantes. La ruta mod_php confirmada, paso a paso:

1. El atacante envía una solicitud multipart diseñada para agotar memory_limit durante el inicio: sin Content-Length utilizable y con una parte con un número enorme de cabeceras, o controles de archivos vacíos que crean matrices de metadatos sin contar para max_file_uploads.
2. Falla una asignación y PHP sale abruptamente con longjmp() mientras la memoria de la solicitud está a medio inicializar.
3. mod_php ejecuta incondicionalmente el procedimiento de cierre de la solicitud aunque el inicio haya fallado, por lo que el cierre procesa el estado no válido antes de que se ejecute código de aplicación.
4. Un montón dispuesto estratégicamente convierte las lecturas y bifurcaciones sobre estado no válido en secuestro del flujo de control, y el atacante ejecuta código con la cuenta del proceso de trabajo web.

Para CVE-2026-109619, el ataque necesita dos solicitudes en el mismo proceso de trabajo:

• Productor y consumidor: una solicitud productora publica estado propiedad de la solicitud y después termina por un error fatal (OOM, tiempo agotado, fallo de análisis). Una solicitud consumidora alcanza el estado obsoleto antes de que la inicialización lo restablezca.
• Caso demostrado más potente: un error fatal con fatal_error_backtraces habilitado almacena estado de trazas de llamadas que el cierre nunca restablece.
• Ruta de sesión: una carga inicializa antes de tiempo el estado de sesión y del decodificador, un OOM abandona el restablecimiento y la gestión de progreso de carga de la siguiente solicitud consume los punteros colgantes.

Dos proveedores documentaron herramientas funcionales:

• SOCRadar: un exploit autodenominado de un clic para PHP 8.4.26 bajo mod_php, encontrado en un servidor expuesto de un atacante. Recicla el proceso de trabajo, filtra direcciones mediante la cookie de sesión para eludir ASLR y usa el progreso de carga de sesión para ejecutar un comando de shell. El servidor también contenía scripts de comprobación contra unos 20 sitios, ninguno de los cuales cumplía las condiciones previas del exploit a 22 de octubre.
• VulnCheck: una cadena de ambos CVE que filtra memoria para eludir ASLR y consigue ejecución de código en PHP 8.4.26 sobre x86-64 con ASLR habilitado y display_errors=off, el ajuste recomendado para producción. VulnCheck afirma no conocer otro exploit público o comercial que haga lo mismo.

¿Cómo transcurre la cadena de explotación de CVE-2026-109618?

La secuencia desde OOM hasta ejecución de código en mod_php, de extremo a extremo:

¿Qué puede hacer un atacante?

Una explotación exitosa proporciona ejecución remota de código sin autenticación con los privilegios del proceso de trabajo web: leer claves API, credenciales de bases de datos, variables de entorno y archivos accesibles al proceso, y obtener un punto de apoyo para avanzar, como describe VulnCheck. Condiciones necesarias:

• Acceso de red al endpoint PHP, nada más. Sin autenticación ni interacción del usuario.
• Las condiciones que elevan la complejidad de ataque CVSS a alta: un proceso de trabajo que sobreviva entre solicitudes y, para la ruta OOM, un memory_limit finito que el atacante pueda alcanzar o una asignación que pueda forzarse a fallar.
• Emparejar solicitudes en el mismo proceso para CVE-2026-109619; más procesos y su reciclaje reducen la fiabilidad, pero no eliminan la condición, según el aviso.

¿Qué proveedores están afectados?

Los productos que incorporan PHP heredan la exposición, y la lista de avisos de proveedores ha crecido considerablemente. Palo Alto Networks confirmó que PAN-OS 10.2, 11.1, 11.2, 12.1 y 12.2 están afectados por el PHP incorporado. Clasifica el impacto en sus productos como alto, CVSS 8.7, con 11 ramas con correcciones urgentes publicadas a 27 de octubre y el resto previstas del 27 al 30 de octubre de 2026.

Además de PAN-OS, los avisos que identifican impacto de PHP2Shell ya cubren decenas de proveedores, incluidos:

• Redes y seguridad: Arista Networks, F5, Huawei, NETGEAR, SonicWall
• Infraestructura y almacenamiento: Broadcom, Dell, HPE, IBM, QNAP, Synology, Veeam
• Software y SaaS: Citrix, Ivanti, Okta, Salesforce, Splunk

Proyectos CMS como Drupal, Craft CMS y WordPress también han publicado avisos.

En el ámbito industrial, SecurityWeek informa de estos estados:

• Schneider Electric corrigió EcoStruxure Security Expert 1.48.4.0 y sus productos ProLeiT LINEoptimize y EcoStruxure Control Engineering.
• Siemens enumeró Ruggedcom APE1808 como afectado por su PAN-OS incorporado y publicó una lista de productos no afectados.
• Se señaló un sistema de ejecución de fabricación ABB que incorpora DokuWiki.
• B&R enumeró como afectadas las versiones de APROL hasta R4.4-65.
• Rockwell Automation y Johnson Controls seguían evaluando.

Si opera dispositivos de cualquiera de estos proveedores, verificar los parches implica ahora comprobar sus avisos, no solo las versiones PHP.

¿Por qué funciona la corrección?

Un solo commit, 3584a98bda («Evitar corrupción del estado mediante salida abrupta», creado el 18 de octubre de 2026 e integrado el 21 de octubre), corrige ambos CVE. Su mensaje nombra exactamente los dos cambios:

- Replace bailout on OOM with UnwindExit
- Properly reset various globals that may be accessed during startup

Para la ruta OOM, el parche elimina la salida abrupta longjmp() como respuesta. Un OOM blando se registra ahora y se difiere al siguiente punto seguro de la VM:

EG(delayed_oom).message = zend_string_init(buf, strlen(buf), /* persistent */ true);
GC_MAKE_PERSISTENT_LOCAL(EG(delayed_oom).message);
zend_string_addref(script_filename);
EG(delayed_oom).filename = script_filename;
EG(delayed_oom).lineno = script_lineno;
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

El procedimiento de cierre ya no puede observar estado parcialmente inicializado, porque OOM se gestiona en un punto donde el ejecutor es coherente. El parche también añade un límite duro de memoria por encima de memory_limit: por defecto, el doble de memory_limit, o memory_limit más 1 GiB cuando el límite supera 1 GiB. Una asignación que lo rebase termina el proceso inmediatamente con _exit() en vez de deshacer la ejecución.

Para la ruta de estado obsoleto, el parche restablece las variables globales propiedad de la solicitud al final de cada solicitud. Nada que lea la siguiente antes de su inicialización normal sigue apuntando a memoria liberada. Por ejemplo, el cierre del ejecutor limpia ahora el estado de error y excepción:

/* may be used by zend_error_zstr_at before init_executor */
EG(record_errors) = false;
EG(num_errors) = 0;
EG(errors) = NULL;
EG(error_handling) = EH_NORMAL;
EG(exception) = NULL;

La corrección es completa para las rutas demostradas, y el aviso afirma que el restablecimiento más amplio del estado es preventivo: cubre otras familias de estado de errores, excepciones, objetos y extensiones, aunque su accesibilidad depende de los productores y consumidores de cada aplicación.

¿Cómo compruebo si me comprometieron?

Vigile estas cinco señales en registros y archivos de sesión. Cualquiera merece investigación y ninguna requiere acceso al código de aplicación.

• En los registros del servidor web y PHP-FPM: ráfagas de solicitudes multipart sin Content-Length o con uno inutilizable, fallos de segmentación repetidos de procesos de trabajo o terminaciones OOM en solicitudes que nunca alcanzaron el código de aplicación, y Maximum execution time exceeded en rutas alcanzables por atacantes.
• Archivos de sesión PHP con código inesperado: VulnCheck observó una IP ubicada en China intentando depositar una web shell mediante archivos de sesión del servidor.
• Campos de progreso de carga de sesión en solicitudes multipart: la PoC ganadora de StealMyBitcoin activa su etapa OOM en el análisis del progreso de carga, y los sondeos observados también usan esos campos. Esto convierte session.upload_progress.enabled = 0 en una mitigación con relevancia demostrada.
• Tráfico posterior de la familia Mirai: Sophos vinculó intentos con la variante de botnet Potassium, con conexiones a 134.199.154.64 en el puerto TCP 50792 y consultas DNS para thunder.godofthunder.st; Wordfence publicó las IP de origen que siguió.
• Enumeración de variables de entorno y credenciales desde procesos de trabajo web, que varios proveedores describen como objetivo de la oleada de escaneo.

A 27 de octubre no se ha confirmado públicamente el compromiso de ninguna víctima real. Las pruebas de explotación se consolidaron los días 24 y 26 de octubre, pero las demostraciones confirmadas se ejecutaron contra objetivos configurados para ser explotables, no contra víctimas.

Adel Karimi verificó ejecución remota de código completa contra sus honeypots mod_php de un solo proceso de trabajo el 24 de octubre. Informó de «un volcado decodificado de cookies de 800 KiB, y una dirección de función derivada de ese volcado mediante los desplazamientos del exploit público aparece en la carga de ejecución posterior».

El reto StealMyBitcoin, un objetivo PHP 8.4.26 deliberadamente vulnerable con un premio de 0.0251 BTC, se ganó el 25 de octubre tras 19.28 horas. La PoC pública filtra direcciones del montón y del código, elude ASLR y falsifica una HashTable para alcanzar zif_system en un máximo de 20 solicitudes. Sus desplazamientos están calibrados para la compilación Alpine del reto y abortan en la etapa de filtración de código en otras compilaciones.

Unit 42 de Palo Alto Networks informó el 25 de octubre de que una entidad gubernamental europea había sido comprometida mediante estos fallos y retiró la atribución ese mismo día. Observó «un ataque contra una agencia gubernamental europea ejecutado en el contexto de una aplicación PHP vulnerable», pero no pudo «confirmar que el acceso inicial estuviera asociado a los CVE específicos PHP2Shell», dijo la empresa a The Hacker News.

Cronología

• Desde 2012: las rutas de código vulnerables existen desde PHP 5.4, según el análisis de Sysdig.
• 2026-10-17: primer intento de explotación observado posteriormente por la red de honeypots MadPot de Amazon, cuatro días antes de la divulgación.
• 2026-10-20: PHP publica un aviso previo de una versión crítica programada para el 21 de octubre a las 14:00 UTC, con ambos fallos puntuados CVSS v4.0 9.2.
• 2026-10-21: PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35 con los avisos GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp. Previdian registra su primer intento de explotación a las 13:05 UTC; Cloudflare cuenta decenas de miles de intentos en los 45 minutos posteriores a la publicación y millones a primeras horas del 22 de octubre. Palo Alto Networks publica su aviso PAN-OS.
• 2026-10-22: el Reino Unido confirma 32 servicios digitales desconectados como precaución y el NCSC emite unas 50.000 advertencias; Sophos documenta una prueba de concepto pública y los intentos de Potassium.
• 2026-10-23: SOCRadar documenta herramientas de explotación de un clic en un servidor de un atacante; Censys cuenta más de 34.4 millones de servicios PHP aún vulnerables; PHP publica un aviso informativo sobre el CVE-2026-115560 relacionado y aún sin corregir, y recomienda session.upload_progress.enabled=0 hasta la siguiente versión ordinaria.
• 2026-10-24: Palo Alto Networks actualiza su aviso con fechas estimadas de correcciones urgentes por rama del 27 al 30 de octubre; Adel Karimi confirma ejecución remota de código completa contra honeypots mod_php de un solo proceso, con divulgación de memoria utilizable y una carga ejecutada derivada de las direcciones filtradas.
• 2026-10-25: primera publicación de este artículo. Palo Alto Networks publica las tres primeras correcciones urgentes PAN-OS (10.2.18-h13, 11.1.16-h4, 11.2.10-h16); Unit 42 informa de un posible compromiso gubernamental mediante estos fallos y retira la atribución ese mismo día; el reto StealMyBitcoin, un objetivo PHP 8.4.26 deliberadamente vulnerable, se gana tras 19.28 horas con una PoC pública que elude ASLR.
• 2026-10-26: se publican cuatro correcciones urgentes PAN-OS más (11.1.4-h38, 11.1.6-h40, 11.1.10-h36, 11.1.13-h16); CISA añade CVE-2026-109618 y CVE-2026-109619 a su catálogo KEV con fecha límite federal del 29 de octubre.
• 2026-10-27: Palo Alto Networks publica 10.2.13-h27, 10.2.16-h12, 12.1.7-h11 y 12.2.4-h1, elevando a once las ramas publicadas; un hilo de oss-security muestra a operadores de compilaciones PHP 5.4 a 5.6 personalizadas adaptando el parche de forma privada; este artículo se actualiza con la inclusión en KEV y la lista de avisos de proveedores.

Preguntas frecuentes

¿PHP-FPM está tan expuesto como mod_php?

Ambos están afectados, pero de forma distinta. mod_php es el objetivo confirmado sin requisitos específicos de aplicación, porque ejecuta el cierre de solicitud incluso tras un inicio fallido. FPM termina el proceso hijo cuando falla el inicio, lo que bloquea esa secuencia concreta, pero el aviso valida una ruta FPM independiente que publica estado durante la ejecución de la aplicación y lo consume en una solicitud posterior de progreso de carga, y el análisis del código también deja a FPM susceptible a la ruta OOM.

¿Me protege desactivar la visualización o el registro de errores?

No. El aviso es explícito: se accede al estado global antes de que PHP decida si informa, muestra o registra una advertencia, y antes de que error_reporting, @ o display_errors tengan efecto. Estos ajustes solo cambian lo que ve, no lo que el motor hace con el estado obsoleto.

Mi sitio ejecuta código de aplicación limpio y actualizado. ¿Estoy protegido?

No. Los fallos están en el motor, por lo que la calidad de la aplicación no cambia la exposición. Sysdig señala que cualquier sitio WordPress, Drupal o Joomla está expuesto independientemente de la calidad de su código, y Censys contabilizó más de 34.4 millones de servicios PHP aún vulnerables el 23 de octubre.

¿Qué ocurre con el tercer fallo, CVE-2026-115560?

Es real pero limitado, y sigue sin corregir a 27 de octubre. Su explotación requiere una aplicación que establezca session.serialize_handler en php_binary o php_serialize en la configuración y lo cambie de nuevo a php en ejecución mediante ini_set() antes de llamar a session_start(), manteniendo habilitado el progreso de carga de sesiones. PHP lo está corrigiendo para la siguiente versión ordinaria; hasta entonces, mantenga session.upload_progress.enabled=0, que el aviso del 21 de octubre ya recomendaba para CVE-2026-109619.

¿Existe un exploit funcional en ataques reales?

Trate los fallos como explotados. CISA añadió ambos a su catálogo KEV el 26 de octubre, su confirmación de explotación activa, y los honeypots de Karimi registraron RCE completa el 24 de octubre. Aún no se ha confirmado el compromiso de ninguna víctima real.

La cadena de VulnCheck funciona contra sistemas x86-64 configurados para producción. El ganador de StealMyBitcoin atacó una compilación deliberadamente vulnerable con desplazamientos calibrados. Interprete cada caso por lo que demuestra, no como un recuento de víctimas, y aplique los parches dentro del plazo KEV.

¿Necesito actualizar si PHP solo se usa para scripts CLI?

Las rutas de ataque demostradas requieren analizar cuerpos de solicitudes, por lo que una instalación exclusivamente CLI queda fuera. Actualice igualmente: las versiones corregidas incorporan el endurecimiento de restablecimiento de estado y los hosts CLI a menudo adquieren después un endpoint web.

Inventaríe su exposición PHP

Utilice Ostorlab Attack Surface Discovery para inventariar sus dominios y hosts expuestos a Internet. Compare sus versiones PHP y los avisos de dispositivos con los rangos afectados anteriores, incluidas las ramas sin soporte y PHP incorporado, y después verifique los parches en cada instancia.

Referencias

• Aviso de seguridad PHP, «Aviso de seguridad: vulnerabilidades críticas de ejecución remota de código, actualice ahora», 21 de octubre de 2026, con las descripciones de ambos CVE y la lista de soluciones temporales incompletas: https://www.php.net/archive/2026.php#2026-10-21-5 (consultado el 25 de octubre de 2026)
• GHSA-w8hw-w9fx-j79w, «RCE mediante corrupción OOM», estrategias OOM completas, susceptibilidad SAPI y descripción del parche: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w (consultado el 25 de octubre de 2026)
• GHSA-6wmf-4rv5-p3rp, «RCE mediante estado global obsoleto», modelo de productor y consumidor, casos confirmados y mitigaciones: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp (consultado el 25 de octubre de 2026)
• Registro CVE-2026-109618 con el vector CVSS v4.0 9.2 y créditos (Ryan de Calif.io, Wiz y OpenAI como informantes; Arnaud Le Blanc, Ilija Tovilo y Jakub Zelenka como desarrolladores de la remediación): https://cveawg.mitre.org/api/cve/CVE-2026-109618 (consultado el 25 de octubre de 2026)
• Registro CVE-2026-109619 con el vector CVSS v4.0 9.2: https://cveawg.mitre.org/api/cve/CVE-2026-109619 (consultado el 25 de octubre de 2026)
• Commit de corrección 3584a98bda, «Evitar corrupción del estado mediante salida abrupta», que sustituye la salida abrupta OOM y restablece las variables globales accedidas al inicio: https://github.com/php/php-src/commit/3584a98bda (consultado el 25 de octubre de 2026)
• Aviso informativo PHP sobre progreso de carga de sesiones y CVE-2026-115560, 23 de octubre de 2026: https://www.php.net/archive/2026.php#2026-10-23-1 (consultado el 25 de octubre de 2026)
• Catálogo KEV de CISA: CVE-2026-109618 y CVE-2026-109619 añadidos el 26 de octubre de 2026, con vencimiento el 29 de octubre de 2026, acción federal requerida y referencia BOD 26-04: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado el 27 de octubre de 2026 mediante el canal JSON del catálogo)
• The Hacker News, «CISA confirma explotación activa de dos fallos PHP2Shell que permiten ejecución remota de código», 27 de octubre de 2026, con las citas de Karimi sobre RCE en honeypots, la cifra de 32.51 millones de Censys y la lista ampliada de avisos de proveedores: https://thehackernews.com/2026/10/cisa-confirms-active-exploitation-of.html (consultado el 27 de octubre de 2026)
• Informes de pruebas de los honeypots PHP2Shell de Adel Karimi, incluido el conjunto de datos de RCE confirmada del 24 de octubre: https://github.com/0x4D31/honeypot-data (referenciados por The Hacker News y SecurityWeek, consultados el 27 de octubre de 2026)
• Sitio del reto StealMyBitcoin, que documenta la victoria del 25 de octubre tras 19.28 horas y el premio de 0.0251 BTC, y la PoC pública ganadora con su tabla de etapas y salvedades de calibración por compilación: https://stealmybitcoin.com/ y https://github.com/KillaBoi/StealMyBitcoin-PoC (consultados el 27 de octubre de 2026)
• SecurityWeek sobre proveedores industriales que comprueban sus productos frente a PHP2Shell, 26 de octubre de 2026, con los estados de Schneider, ProLeiT, Siemens Ruggedcom, ABB, B&R, Rockwell y Johnson Controls: https://www.securityweek.com/industrial-vendors-check-their-products-for-php2shell-vulnerabilities/ (referenciado por The Hacker News, consultado el 27 de octubre de 2026)
• Hilo de oss-security sobre adaptaciones privadas de parches PHP 5.4 a 5.6 para CVE-2026-109618, 27 de octubre de 2026: https://www.openwall.com/lists/oss-security/2026/10/27/1 (consultado el 27 de octubre de 2026)
• Aviso de Palo Alto Networks sobre el impacto de CVE-2026-109618 y CVE-2026-109619 en PAN-OS, con once ramas de correcciones urgentes publicadas según el registro de cambios del 27 de octubre y el resto previstas del 27 al 30 de octubre: https://security.paloaltonetworks.com/CVE-2026-109618 (consultado el 27 de octubre de 2026)
• The Hacker News con la retractación de Unit 42 del 25 de octubre sobre la atribución del compromiso de una entidad gubernamental, incluida la declaración del portavoz: https://thehackernews.com/2026/10/php2shell-exploitation-hits-government.html (consultado el 26 de octubre de 2026)
• Sophos sobre la prueba de concepto pública y los intentos fallidos de Potassium, variante Mirai: https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619 (mediante The Hacker News, 23 de octubre de 2026: https://thehackernews.com/2026/10/php2shell-exploit-attempts-hit-millions.html, consultado el 25 de octubre de 2026)
• VulnCheck sobre la cadena de explotación que elude ASLR y el intento de web shell mediante archivos de sesión: https://www.vulncheck.com/blog/php2shell-vulnerabilities (consultado el 25 de octubre de 2026)
• SOCRadar sobre las herramientas mod_php de un clic encontradas en un servidor de un atacante: https://socradar.io/blog/php2shell-exploit-tooling-attacker-server/ (consultado el 25 de octubre de 2026)
• Telemetría de Previdian para ambos CVE, primer evento el 21 de octubre a las 13:05 UTC, sin RCE exitosa observada: https://previdian.com/CVE-2026-109618#telemetry (consultada el 25 de octubre de 2026)
• Registro del Parlamento británico que confirma 32 servicios digitales no disponibles y unas 50.000 advertencias del NCSC: https://hansard.parliament.uk/Lords/2026-10-22/debates/14CB4C6D-4E16-4377-8FCF-C2CF77BB5CC0/details (consultado el 25 de octubre de 2026)
• Recuento de Censys de más de 34.4 millones de servicios PHP vulnerables a 23 de octubre de 2026: https://php2shell.censys.com/ (consultado el 25 de octubre de 2026)
• SecurityWeek, «Operadores de botnets Mirai se suman a los ataques PHP2Shell mientras aparecen exploits que eluden ASLR», 23 de octubre de 2026, con el análisis de parches de Qualys de 12.000 clientes (199.000 instancias actualizadas en 12 horas; unos 110 millones de instancias, el 71 por ciento, en PHP 5.4 a 8.1 sin soporte; otros 44 millones en ramas con soporte pero sin corregir): https://www.securityweek.com/mirai-botnet-operators-join-php2shell-attacks-as-aslr-bypass-exploits-emerge/ (consultado el 26 de octubre de 2026)
• Análisis de Qualys de la versión crítica de octubre de 2026: https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities (mediante SecurityWeek, 23 de octubre de 2026)
• Amazon sobre intentos de explotación desde el 17 de octubre contra sus honeypots MadPot: https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html (consultado el 25 de octubre de 2026)
• Sysdig sobre el código vulnerable que se remonta a PHP 5.4 (2012): https://www.sysdig.com/blog/php2shell-cve-2026-109618-and-cve-2026-109619-detecting-unauthenticated-remote-code-execution-in-php-core (consultado el 25 de octubre de 2026)