DuneTech LabsQué permiten las dos fallas
Cuando PHP se queda sin memoria o tiene un error fatal a mitad de una petición, puede dejar datos internos a medio preparar o apuntando a memoria que ya se liberó. Luego los usa como si fueran válidos: al limpiar esa misma petición, o en la siguiente que atiende el mismo proceso. Con peticiones armadas, un atacante puede aprovecharlo.
| Falla | Qué pasa | Qué se demostró |
|---|---|---|
| CVE-2026-109618 | Al quedarse sin memoria, la limpieza de la petición trata datos a medio preparar como válidos | Ejecución de código sin iniciar sesión, con la cuenta del servidor web: con mod_php sin configuración especial; con PHP-FPM, por rutas de la aplicación, según la PHP Foundation; Red Hat lo ve difícil en la práctica con FPM, y el aviso de GitHub aún no lo da por demostrado |
| CVE-2026-109619 | Datos de una petición sobreviven en memoria ya liberada y los usa la siguiente | Lectura de memoria y ejecución de código sin iniciar sesión, con mod_php y con PHP-FPM |
Las dos tienen gravedad de 9.2 de 10 (CVSS 4.0): se atacan por la red, sin cuenta y sin que nadie haga clic, pero con complejidad alta y ciertas condiciones previas. Red Hat las califica un escalón abajo («Important») porque aprovecharlas de forma confiable pide manipular la memoria con precisión. La memoria que se puede leer «may contain passwords, authentication tokens, API keys and certificates», según Wiz, una de las empresas que las reportaron.
PHP dice que afectan a «all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed», con el riesgo más alto en mod_php. Los investigadores de Calif confirmaron la ejecución de código sin cuenta contra WordPress, Drupal, Joomla, Magento, Nextcloud, Laravel, Symfony, phpMyAdmin y WHMCS, entre otros. Las aplicaciones no tienen que hacer nada especial para quedar expuestas: el problema está en el PHP que las corre.
Cómo se respondió
| Cuándo | Qué pasó |
|---|---|
| 2024 | En una auditoría externa de PHP, un desarrollador del proyecto encontró las primeras señales del problema de memoria; no se halló cómo aprovecharlo |
| 11 de agosto de 2026 | Calif reporta a PHP, en privado, una forma de ejecutar código; OpenAI reporta la misma causa ese día. PHP confirma la prueba de Calif el 15 |
| Agosto y septiembre | Más reportes: Calif el 21 de agosto, Wiz el 24, OpenAI el 18 de septiembre |
| 20 de octubre, 9:00 (hora del centro de México) | Los números de las fallas empiezan a circular en foros y redes, con una gravedad equivocada (10) y sin detalles técnicos |
| 20 de octubre, 13:30 | PHP publica su aviso previo y adelanta la publicación un día, del 22 al 21. No la saca de inmediato porque los distribuidores, que tenían el parche por adelantado, aún lo empaquetaban |
| 20 de octubre, por la noche | Cloudflare activa reglas para frenar los ataques en sus clientes, también en el plan gratuito |
| 21 de octubre, 8:00 | PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El mismo día: cPanel, Plesk, Ubuntu y Debian publican sus versiones corregidas, y CISA emite su alerta |
La PHP Foundation explica que el plan coordinado funcionó «until 2 days ahead of the targeted release date». Y es franca con lo que no funcionó: las señales del problema eran de 2024, y el arreglo se atoró meses porque cada solución rompía algo; «We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources». Está cambiando sus procesos para que un caso así llegue antes a su dirección. Lo que mostró este caso, en nuestra lectura: cuando el parche y los proveedores están coordinados de antemano, una filtración no deja a los usuarios sin salida, porque el arreglo puede salir en un día.
Qué versiones lo corrigen
| Rama de PHP | Corregida en | Nota |
|---|---|---|
| 8.5 | 8.5.12 | Una de las rutas confirmadas, solo en 8.5, usa fatal_error_backtraces |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | «PHP 8.2 reaches end of life on 31 December 2026» |
| 8.1 y anteriores | Sin versiones nuevas | PHP publicó correcciones mínimas en código fuente para 7.4, 8.0 y 8.1; cPanel ya corrigió sus paquetes de esas versiones. php.net pide preguntar al proveedor |
En los paquetes de Linux, lo que cuenta es el paquete corregido, no el número de PHP. En Ubuntu 24.04, 8.3.6-0ubuntu0.24.04.13 ya trae la corrección aunque su número sea menor que 8.3.36. En Debian, bookworm la corrige en 8.2.35-1~deb12u1 y trixie en 8.4.27-1~deb13u1.
Qué se sabe de los ataques
- CISA, al publicar su alerta: «has not observed exploitation of these vulnerabilities as of the time of publication». No están en su catálogo de fallas ya explotadas (versión del 21 de octubre).
- Cloudflare: «we observed attack traffic targeting our customers» desde la filtración, y atacantes que modificaban sus intentos para saltarse las reglas.
- watchTowr: «observing active exploitation attempts of both».
- PHP Foundation: no identificó «any functional exploits at the time of release/public disclosure».
- Sansec: «The writeups and an exploit tool are public».
Hay intentos. Al cierre de esta página, Patchstack decía «no hard evidence of breaches yet» y Huntress aún no veía que se explotaran entre sus clientes (a las 8:00 del centro de México); watchTowr sí las marca como explotadas. Con los detalles ya públicos, en nuestra lectura, esperar es el riesgo.
Fuentes
Consultadas el 21 de octubre de 2026.
- PHP, el aviso y las versiones corregidas, 21 de octubre de 2026: «all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php»; «There are no complete mitigations, updating is the only safe choice»; «PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes»; «minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1»; las medidas temporales, que «reduce exposure to specific attack paths but do not make an installation safe»; «PHP 8.2 reaches end of life on 31 December 2026». Y el aviso previo del 20 de octubre.
- PHP, los avisos de seguridad GHSA-w8hw-w9fx-j79w (CVE-2026-109618): «The confirmed impact is unauthenticated remote code execution as the web worker account»; «no complete FPM exploit has been demonstrated». Y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): «unauthenticated heap use-after-free, memory disclosure and remote code execution with the web worker's privileges»; «Session lifecycle RCE was validated against mod_php and FPM».
- Registro de las CVE, CVE-2026-109618 y CVE-2026-109619: CVSS 4.0 de 9.2; versiones afectadas, 8.2 antes de 8.2.35, 8.3 antes de 8.3.36, 8.4 antes de 8.4.27 y 8.5 antes de 8.5.12.
- PHP Foundation, qué pasó y cómo se respondió, 21 de octubre de 2026: «On August 11th researcher Ryan A at Calif reported an unconditional remote code execution… OpenAI independently reported the same root cause on the same day, followed by further attack vectors from OpenAI on September 18th and from Wiz on August 24th»; «The coordinated disclosure of these vulnerabilities worked well until 2 days ahead of the targeted release date»; «On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media»; «It also moved the release from October 22nd, 14:00 UTC, to October 21st, 14:00 UTC»; «had received the patch in advance so its users could update the moment the vulnerabilities were disclosed»; «did not identify any functional exploits at the time of release/public disclosure»; «Remote code execution was also confirmed on PHP-FPM through application-level code paths»; «We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources».
- Calif, PHP2Shell: «August 11 · Calif reported the first bug to PHP and started coordinated disclosure process»; «August 15 · PHP confirmed that the RCE PoC worked as expected»; las aplicaciones probadas.
- Wiz, PHP2Shell: «may contain passwords, authentication tokens, API keys and certificates». Y Calif sobre la medida temporal: «Setting memory_limit=-1 removes PHP’s memory cap, increasing the risk of memory exhaustion».
- CISA, la alerta, 21 de octubre de 2026: «allow for unauthenticated remote code execution in PHP and affect all PHP installations serving web requests»; «While CISA has not observed exploitation of these vulnerabilities as of the time of publication»; «should take PHP-based systems offline until they can be patched or updated»; «A web application firewall may provide some protection». Y su catálogo de fallas explotadas (versión 2026.10.21): sin las dos CVE.
- Red Hat, CVE-2026-109618: «Important»; «reliable exploitation requires precise heap manipulation and timing»; con PHP-FPM, «remote code execution is difficult in practice and typically requires non-default behavior».
- Cloudflare, la protección de su firewall, 21 de octubre de 2026: «we observed attack traffic targeting our customers»; «available and deployed automatically on all plans with WAF deployed, including Free users»; «updating website code or a plugin(s) alone does not fix these vulnerabilities… If a hosting provider manages PHP, ask the provider»; «Customers should patch their PHP repos even with WAF protections».
- WordPress.org, aviso: «No WordPress update is required or planned»; «Tools > Site Health > Info > Server».
- cPanel, EasyApache 4, versión 25.91, «2026 October 21»: las versiones corregidas y «Backport the fix for CVE-2026-109618 and CVE-2026-109619» en ea-php74, ea-php80 y ea-php81. Plesk, registro de cambios, «21 October 2026»: «Updated PHP 8.5 to version 8.5.12» y las demás.
- Ubuntu, USN-8948-1, 21 de octubre de 2026: en 24.04,
8.3.6-0ubuntu0.24.04.13. Debian, CVE-2026-109618: bookworm8.2.35-1~deb12u1(DLA-4848-1, «Wed, 21 Oct 2026 16:11:55 +0200»), trixie8.4.27-1~deb13u1(DSA-6574-1, «Wed, 21 Oct 2026 13:45:09 +0000»). - watchTowr, PHP2Shell (secundaria): «watchTowr is observing active exploitation attempts of both». Sansec, PHP2Shell (secundaria): «The writeups and an exploit tool are public». Patchstack, su alerta (secundaria): «no hard evidence of breaches yet». Huntress, su análisis (secundaria): «has not yet seen in-the-wild exploitation of these vulnerabilities across our partner base as of October 21 at 10am ET».