PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el 21 de octubre para corregir CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades calificadas con 9.2 sobre 10 que permiten la ejecución remota de código sin autenticación.

Las vulnerabilidades llevaron a Finlandia, Países Bajos y Francia a desconectar sitios web gubernamentales como medida de precaución después de que los detalles se conocieran antes de lo previsto. Cloudflare también reportó ataques varias horas antes de que se publicara el parche. La Agencia de Seguridad Nacional de EE. UU. (NSA) recomendó a las organizaciones que usan PHP que cerraran sus sitios, mientras que agencias de Australia, Japón y el Reino Unido emitieron orientaciones similares.

La mayoría de los usuarios de internet no necesita instalar nada. La responsabilidad de aplicar la corrección recae en los operadores de sitios web, las empresas de hosting y las organizaciones que mantienen servidores PHP. Las versiones 8.1 de PHP y anteriores no reciben lanzamientos oficiales regulares, aunque el equipo de seguridad de PHP publicó parches limitados de código fuente para algunas versiones antiguas debido a la gravedad del problema.

PHP impulsa aproximadamente el 70% de los sitios web cuyo lenguaje del lado del servidor es conocido, según W3Techs. El lenguaje de programación opera en servidores, donde ayuda a almacenar sitios web y generar las páginas solicitadas por los visitantes. Los sitios de WordPress, por ejemplo, suelen depender de servidores PHP, según la empresa de seguridad de WordPress Wordfence.

Las dos fallas pueden permitir que un atacante ejecute comandos en un servidor PHP sin iniciar sesión. Este tipo de vulnerabilidad se conoce como ejecución remota de código sin autenticación. Dependiendo del servidor y de los datos que almacene, un ataque exitoso podría exponer información de cuentas, direcciones, historiales de pedidos u otro material sensible.

El proveedor de hosting GoDaddy advirtió que las vulnerabilidades podrían permitir a los atacantes robar datos, dañar sitios web u obtener el control total de los servidores afectados.

"Una falla como esta podría permitir a un atacante ejecutar su propio código en un servidor afectado a través de internet, lo que puede llevar al robo de datos, a un sitio dañado o a una toma de control total", dijo GoDaddy en su actualización de seguridad.

El anuncio de seguridad de PHP

La PHP Foundation, la organización sin fines de lucro que financia el desarrollo del lenguaje, emitió una advertencia anticipada el 20 de octubre. En un comunicado compartido en X, dijo:

"The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence."

The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence. — The PHP Foundation (@ThePHPF) October 20, 2026

El Common Vulnerability Scoring System, o CVSS, califica las vulnerabilidades de 0 a 10 según factores como la facilidad con la que pueden explotarse a través de internet y el impacto potencial. Las puntuaciones de 9.0 o superiores se clasifican como críticas.

PHP publicó la corrección aproximadamente a las 13:35 UTC del 21 de octubre, unos 25 minutos antes de la hora anunciada. El aviso de seguridad señaló: "Todos los usuarios de PHP son fuertemente instados a actualizar de inmediato". El lanzamiento se adelantó un día después de que la información sobre las vulnerabilidades comenzara a circular públicamente y surgieran evidencias de ataques.

Cómo funcionan las vulnerabilidades

CVE-2026-109618 ocurre cuando PHP se queda sin memoria mientras procesa una solicitud y luego trata los datos parcialmente construidos como si estuvieran completos. CVE-2026-109619 permite que restos de la solicitud de un visitante permanezcan en memoria después de que deberían haberse descartado, lo que posibilita que una solicitud posterior interactúe con esos restos.

El riesgo es mayor en servidores que usan mod_php, una configuración común de Apache. PHP indicó que un exploit demostrado funciona "antes de que se ejecute cualquier código de aplicación", lo que significa que las defensas implementadas por el propio sitio web, como las pantallas de inicio de sesión y los plugins de seguridad de WordPress, podrían no tener oportunidad de intervenir.

Los investigadores de la PHP Foundation identificaron la función upload-progress de PHP como una de las vías confirmadas de entrada a la vulnerabilidad. La función rastrea el progreso de una carga de archivos, ha estado habilitada por defecto durante más de una década y no es utilizada por muchos sitios web.

Más información técnica está disponible en el archivo de seguridad de PHP, el análisis de watchTowr y la entrada de NVD para CVE-2026-109619. La documentación de PHP también describe la configuración de sesiones relevante.

Los detalles se filtraron antes del parche

La divulgación no se esperaba inicialmente antes del lanzamiento programado. El martes, un usuario publicó en el foro Hacker News que dos vulnerabilidades de PHP serían reveladas el jueves, aunque reconoció que la afirmación no tenía "evidencia más allá de 'source: trust me, bro'". La publicación está disponible aquí.

La empresa de seguridad watchTowr confirmó luego que las vulnerabilidades eran reales y estaban cubiertas por un embargo, un acuerdo destinado a mantener la confidencialidad de los detalles técnicos hasta que la corrección estuviera lista. PHP aceleró entonces el lanzamiento.

El CTO de Cloudflare, Dane Knecht, dijo en X en la madrugada del miércoles que los ataques ya habían comenzado, casi seis horas antes de que se publicara el parche. Cloudflare desplegó reglas de emergencia de firewall de aplicaciones web para sus clientes, incluidos los de planes gratuitos, pero Knecht describió las reglas como solo una medida temporal.

"PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show… — Dane Knecht 🦭 (@dok2001) October 21, 2026"

La publicación original también está disponible en la cuenta de X de Dane Knecht.

Los gobiernos desconectan sitios web

El centro de TI estatal de Finlandia, Valtori, comenzó a desconectar los servicios web públicos como medida de precaución, según la radiodifusora pública Yle. La agencia nacional de ciberseguridad de los Países Bajos también retiró su propio sitio web.

El Ministerio del Interior de Francia dijo que los sitios web de las prefecturas habían sido "retirados temporalmente de línea a la espera de la publicación de un parche de seguridad por parte del editor del framework".

El equipo de emergencias cibernéticas de la Unión Europea, CERT-EU, indicó a las organizaciones que no pudieran aplicar el parche que "consideraran aislar las aplicaciones expuestas a internet de las redes públicas hasta que haya una corrección disponible".

Reuters informó que agencias de Australia, Japón y el Reino Unido emitieron orientaciones similares. El informe de Reuters también señaló que los sitios web podrían necesitar desconectarse mientras los operadores se preparaban para instalar las correcciones.

Afirmaciones sobre las versiones de PHP afectadas

Publicaciones que circularon en X afirmaban que las versiones de PHP que se remontan a 2004 eran vulnerables. Esa afirmación provino de estimaciones tempranas de que todas las versiones desde PHP 5 estaban afectadas, una evaluación que CERT-EU dijo que se basaba en publicaciones de redes sociales.

La empresa de seguridad de comercio electrónico Sansec estimó que PHP 5.4 y versiones posteriores estaban afectadas, lo que extendería el rango hasta 2012 en lugar de 2004. PHP proporciona oficialmente versiones actuales solo para las versiones 8.2 y superiores. Sin embargo, debido a la gravedad de estas vulnerabilidades, el equipo de seguridad también publicó parches básicos de código fuente para PHP 7.4, 8.0 y 8.1, mientras que las distribuciones de Linux comenzaron a incorporar las correcciones por su cuenta.

La empresa de seguridad Mallory contó aproximadamente 884,000 hosts expuestos a internet que anunciaban PHP 8.1 o anterior el 20 de octubre. Eso representó el 59% de los aproximadamente 1.5 millones de hosts visibles públicamente que identificaban su versión de PHP. El número de sitios web afectados es mayor porque un solo servidor de hosting compartido puede soportar muchos sitios. La investigación de Mallory está disponible aquí, mientras que el análisis de Sansec está disponible aquí.

Algunas publicaciones en línea también incluyeron a Node.js en la discusión. Node.js es una tecnología web distinta que casualmente tenía programada su propia actualización de seguridad, no relacionada, para el mismo día.

La PHP Foundation advirtió que las versiones corregidas no estarían disponibles en todas partes al mismo tiempo. Señaló: "Si dependes del repositorio mantenido por voluntarios te instamos a migrar a paquetes de la distribución o a compilar desde el código fuente ahora, para que puedas aplicar las actualizaciones de inmediato. El repositorio no tendrá actualizaciones hoy", en referencia a una fuente de paquetes PHP para servidores Linux tipo Red Hat mantenida por voluntarios. El repositorio de paquetes está disponible en

Posible impacto en sitios web y activos digitales

Un sitio web comprometido no necesita interactuar directamente con una blockchain para poner en riesgo los activos digitales de los usuarios. En 2024, atacantes redirigieron las interfaces de los protocolos DeFi Compound y Celer a páginas diseñadas para vaciar las wallets conectadas. Curve Finance sufrió un ataque similar en 2025. Esos incidentes involucraron secuestros de DNS en lugar de vulnerabilidades de PHP, pero el resultado puede parecer similar para un visitante: el sitio web y la URL parecen legítimos mientras una acción de aprobación envía los tokens a otro lugar.

Un servidor PHP comprometido podría usarse para servir una página fraudulenta de ese tipo. La relación entre la infraestructura web vulnerable y el robo de criptomonedas también fue comentada por el emprendedor @levelsio, quien dijo en X que había desconectado sus sitios y servidores privados virtuales mientras esperaba el parche.

"I pre-emptively disconnected ALL my sites / VPS servers from the web I'll wait for the patch to hit at 2 PM UTC If you have a PHP website, probably good to take them down until you patch PHP 69.3% of the web runs on PHP so this is going to be intense! Good time maybe to buy… — @levelsio (@levelsio) October 21, 2026"

La publicación también está disponible en X. Los reportes anteriores de Decrypt sobre el incidente de Compound y Celer y el ataque a Curve están disponibles aquí y aquí.

Las vulnerabilidades también llegan en un momento en que los modelos de inteligencia artificial de frontera se usan cada vez más para identificar fallas de software. Expertos dijeron a Decrypt en junio que la difusión de esas herramientas podría llevar al descubrimiento de muchas más vulnerabilidades. El informe de Decrypt está disponible aquí.

Qué deben hacer los operadores de sitios web

Una vez que un parche se hace público, los atacantes pueden comparar el código vulnerable con el corregido para determinar qué cambió. El equipo forense de Sansec dijo que esperaba que "los ataques masivos comenzaran dentro de los 15 minutos posteriores al lanzamiento". Cuando otra vulnerabilidad de PHP se hizo pública en junio de 2024, Akamai registró intentos de explotación contra sus servidores señuelo en un plazo de 24 horas. El análisis de Akamai está disponible aquí.

Los teléfonos, navegadores y computadoras portátiles personales no necesitan una actualización de PHP. El trabajo recae en las organizaciones que operan sitios web y servidores. Los propietarios de sitios web deben preguntar a sus proveedores de hosting si PHP ha sido actualizado e identificar quién es responsable del mantenimiento del servidor.

Wordfence advirtió que las actualizaciones automáticas de WordPress no aplicarían esta corrección. Por lo tanto, los propietarios de sitios deben confirmar que el propio PHP ha sido parcheado en lugar de suponer que actualizar WordPress resolverá el problema.

La desarrolladora principal de PHP, Gina Peter Banyard, dijo en Mastodon: "Lo único que puedo decir es que la única mitigación es parchar / actualizar PHP", agregando: "Lamentablemente sé demasiado". La publicación está disponible aquí.

Las organizaciones que ejecutan PHP 8.1 o anterior deben planificar una actualización porque esas versiones no reciben lanzamientos oficiales regulares. Los usuarios de PHP 8.2 también enfrentan un plazo inminente: PHP 8.2 llega al fin de su vida útil el 31 de diciembre de 2026, de lo cual ya no recibirá parches de seguridad.