PHP2Shell: dos fallas críticas en PHP permiten la ejecución remota de código sin inicio de sesión

El proyecto PHP publicó el 21 de octubre de 2026 correcciones de emergencia para dos vulnerabilidades críticas en el núcleo del lenguaje, apodadas PHP2Shell: CVE-2026-109618 y CVE-2026-109619, ambas con CVSS v4.0 9.2. Permiten la ejecución remota de código (RCE) sin autenticación.

El punto más importante: el problema está en el runtime de PHP, no en las aplicaciones. Un sitio web puede tener código seguro y aun así ser vulnerable.

Qué hacen las fallas

• CVE-2026-109618, corrupción de memoria por falta de memoria (OOM). Si una solicitud alcanza el memory_limit en el momento equivocado, PHP puede dejar datos internos parcialmente inicializados y tratarlos como válidos, corrompiendo la memoria. En Apache con mod_php, una solicitud no autenticada puede disparar la falla antes de cualquier código de la aplicación, y la ejecución remota se demostró con configuraciones predeterminadas. En PHP-FPM, la RCE se confirmó por rutas de código a nivel de aplicación.
• CVE-2026-109619, estado obsoleto. Un error fatal en el punto equivocado puede dejar el estado interno apuntando a la memoria de una solicitud anterior, que una solicitud siguiente, en el mismo worker, vuelve a usar después de ser liberada (use-after-free). La RCE se demostró en una aplicación real bajo Apache con mod_php.

Según la cobertura de The Hacker News, las dos fallas también pueden filtrar memoria del worker, con posibles contraseñas, tokens y claves de otras solicitudes.

Quién está expuesto

Toda instalación de PHP que atiende solicitudes web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Según la cobertura, casi todas las versiones desde PHP 5.4 hasta la 8.5.11 están afectadas. PHP puede venir incrustado en otros softwares, por lo que no siempre es visible en el inventario.

Cómo corregir

Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

1. Haga el inventario de todo lo que ejecuta PHP, comenzando por los sistemas expuestos a internet.
2. Actualice y reinicie Apache, PHP-FPM y workers de larga duración. Sin el reinicio, el proceso antiguo sigue siendo vulnerable.
3. En distribuciones Linux, el parche puede haberse aplicado sin cambiar el número de versión. Consulte el changelog del paquete por el número de la CVE.
4. Después de actualizar, revise memory_limit y post_max_size. El nuevo límite estricto de memoria finaliza el proceso e impide la ejecución de los controladores de apagado, lo que puede afectar a las aplicaciones que dependían de ello.

¿Y quién no puede actualizar?

PHP 8.1 y anteriores ya no reciben correcciones del proyecto. Para la 7.4, la 8.0 y la 8.1 se publicaron backports en código fuente, destinados a quienes compilan por su cuenta o esperan un proveedor. La CISA recomienda retirar los sistemas basados en PHP que no puedan ser corregidos o que usen la 8.1 o anteriores, hasta que sean actualizados.

Quien depende de un hosting, CMS o distribución que aún no ha entregado el paquete corregido sigue expuesto. Contacte al proveedor y pregunte la fecha.

Medidas paliativas, que no hacen que el servidor sea seguro:

• limite el tamaño de las solicitudes en el servidor web o en el proxy y mantenga post_max_size bajo;
• para la CVE-2026-109618, defina memory_limit=-1 para que las aplicaciones no lo sobrescriban. No use RLIMIT_AS ni RLIMIT_DATA;
• para la CVE-2026-109619, defina session.upload_progress.enabled=0 y reinicie los workers. En PHP 8.5, defina también fatal_error_backtraces=0. Esto no bloquea todas las variantes;
• un firewall de aplicación web (WAF) puede ofrecer alguna protección temporal, pero hay informes de atacantes que cambian los payloads para eludir las reglas.

¿Hay explotación?

El panorama aún estaba cambiando la noche del 21/10, y las fuentes difieren.

• La CISA informó que no observó explotación hasta la publicación de la alerta y recomienda aplicar el parche inmediatamente.
• El equipo de seguridad de PHP no identificó ningún exploit funcional hasta el lanzamiento, pero dice que la circulación de pruebas de concepto aumentó el 21/10.
• Cloudflare informó intentos iniciales de explotación y ataques que cambiaban los payloads para eludir sus reglas de firewall.
• watchTowr dijo, en un primer momento, no haber observado explotación y, horas después, actualizó a intentos activos contra las dos CVEs.
• Ninguna fuente confirmó la invasión exitosa de un servidor específico, y las fallas no estaban en el catálogo KEV de la CISA en la fecha de la cobertura.

En la práctica: trate como riesgo de explotación inminente.

Cómo saber si ya hubo intento

Busque:

• solicitudes multipart inusuales seguidas de errores de límite de memoria o HTTP 500 repetidos;
• cookies PHPSESSID anormalmente grandes;
• reinicios inexplicables de workers;
• procesos de worker de PHP iniciando shells o descargando herramientas.

Cómo llegó hasta aquí

El 20/10, los identificadores de las CVEs comenzaron a circular en foros y redes sociales, con un CVSS 10.0 que el proyecto no confirmó (la nota real es 9.2). PHP anticipó la divulgación del 22/10 al 21/10. Según la PHP Foundation, Calif publicó por error un video con prueba de concepto, luego eliminado, y Chainguard publicó imágenes con el parche antes del plazo combinado. Esto aceleró el trabajo de quienes quieren reproducir la falla. Según la cobertura, Cloudflare activó reglas de WAF la mañana del 21/10. Organizaciones como BambooHR llegaron a retirar servicios por precaución.

Cómo Indene puede ayudar

Podemos ayudar a mapear dónde se ejecuta PHP en su entorno (incluso incrustado en otros softwares), priorizar la actualización y buscar señales de intento de explotación. [a confirmar: canal de contacto y CTA estándar de la casa]

Fuentes: PHP Foundation, alerta de la CISA y The Hacker News.