Pánico en PHP: dos fallos críticos ponen en riesgo al 70% de internet y todo el mundo entra en pánico

Si has estado en línea hoy, aunque sea un poco, habrás visto el pánico: una vulnerabilidad crítica amenaza con “pwnear” prácticamente todos los sitios web del planeta.

Finlandia acaba de empezar a desconectar sitios web gubernamentales el miércoles, la NSA recomienda a todas las organizaciones que usan PHP que cierren sus sitios, y los Países Bajos y Francia hicieron lo mismo. Y no, no fue una ciberguerra.

El culpable era PHP, un lenguaje de programación del que la mayoría de la gente nunca ha oído hablar. Sin embargo, casi con total seguridad lo has usado hoy: ejecuta alrededor del 70% de todos los sitios web cuyo lenguaje del lado del servidor se conoce, según W3Techs.

PHP es el software que trabaja tras el telón en el servidor de un sitio web—la computadora que almacena el sitio y construye cada página que solicitas. Cada sitio de WordPress, por ejemplo, se aloja en un servidor PHP, según la empresa de seguridad de WordPress Wordfence.

Ah, por cierto, Wordfence también está caído.

Dos errores recién descubiertos en el propio PHP permiten a un desconocido ejecutar sus propios comandos en ese servidor sin siquiera iniciar sesión. La gente de seguridad llama a esto ejecución remota de código no autenticada. Todos los demás pueden llamarlo "ahora lo conduce otro".

Si ese servidor almacena tu cuenta, tu dirección o tu historial de pedidos, bueno, eso también es suyo. El proveedor de alojamiento web GoDaddy advirtió que las fallas podrían permitir a los atacantes robar datos, desfigurar sitios o tomar el control total de los servidores.

"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 la desfiguración de un sitio o a una toma de control total", dice GoDaddy.

Lo que anunció PHP

La PHP Foundation, la organización sin fines de lucro que financia el desarrollo del lenguaje, dio la alarma el martes. En una declaración compartida en X, dijo: "El equipo de seguridad de PHP está dando aviso previo: Próxima versión de seguridad mié, 21 de oct de 2026, 14:00UTC, dos vulnerabilidades críticas, ambas calificadas CVSSv4 9.2. Se anima a los usuarios de PHP a prepararse para actualizar. Versión anterior si los detalles se hacen públicos o hay evidencia de explotación activa."

Ese 9.2 proviene de CVSS, el Sistema de Puntuación de Vulnerabilidades Comunes, que califica cuán peligroso es un error basándose en cosas como la facilidad con que se puede alcanzar a través de internet y cuánto daño puede hacer. Va de 0 a 10, y cualquier cosa desde 9.0 en adelante se etiqueta como crítica—así que estos dos son casi lo peor que puede haber sin llegar a un 10 perfecto.

La corrección llegó aproximadamente a las 13:35 UTC del miércoles, unos minutos antes, como las versiones de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El aviso de seguridad no se molestó en ser sutil: "Se anima encarecidamente a todos los usuarios de PHP a actualizar de inmediato."

Pero publicar una corrección y lograr que todo el mundo implemente la solución no son la misma cosa, así que se recomienda precaución.

Cómo funcionan los errores

El primer error, CVE-2026-109618, aparece cuando PHP se queda sin memoria a mitad del manejo de una solicitud y luego trata esos datos a medio construir como si estuvieran terminados. El segundo, CVE-2026-109619, permite que los restos de la solicitud de un visitante permanezcan en la memoria después de que deberían haberse descartado, donde la siguiente solicitud puede tropezar con ellos.

Piense en un cocinero que sigue leyendo pedidos de tickets que ya están en la basura. Cuele un ticket falso en el cubo y el cocinero preparará lo que sea que haya escrito en él. En este caso, el "pedido" es el código del atacante, y el servidor lo ejecuta.

PHP dijo que el riesgo es mayor en servidores que usan una configuración común de Apache llamada mod_php, donde un exploit demostrado funciona "antes de que se ejecute cualquier código de la aplicación". En otras palabras, las defensas propias del sitio web, como las pantallas de inicio de sesión y los plugins de seguridad de WordPress, ni siquiera se activan.

Los investigadores de la fundación PHP señalaron la función de progreso de carga de PHP, la cosa que rastrea cuánto de un archivo ha enviado, como una de las formas confirmadas de entrada. Ha estado activada por defecto durante más de una década, y pocos sitios web la usan realmente.

Una filtración, luego ataques

Nada de esto debía ser público todavía. El martes, alguien publicó en el foro de Hacker News que dos fallos de PHP se revelarían ese jueves, mientras admitía que no tenían "ninguna evidencia más allá de 'fuente: confía en mí, hermano'."

Resulta que el hermano tenía razón. La firma de seguridad watchTowr confirmó que los errores eran reales y estaban bajo embargo —un acuerdo para mantener los detalles en silencio hasta que haya una corrección lista— y PHP adelantó su lanzamiento un día.

"Estamos viendo surgir ataques tempranos y estamos actualizando las mitigaciones a medida que aparecen nuevos vectores", escribió en X el director de tecnología de Cloudflare, Dane Knecht, la madrugada del miércoles, casi seis horas antes de que se enviara el parche. Cloudflare envió reglas de firewall de emergencia, filtros que bloquean patrones de ataque conocidos, a todos los clientes, pero Knecht las calificó como "solo un paliativo".

Los gobiernos accionan el interruptor de apagado

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

El Ministerio del Interior de Francia declaró que los sitios web de sus prefecturas fueron "retirados temporalmente de línea a la espera de la publicación de un parche de seguridad por parte del editor del framework".

CERT-EU, el equipo de ciberemergencias de la UE, 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 solución disponible". Eso es jerga burocrática para decir "desenchúfalo". Las agencias de Australia, Japón y el Reino Unido dijeron prácticamente lo mismo, según Reuters.

En qué se equivocaron las publicaciones virales

Hilos virales en X afirmaban que las versiones de PHP "que se remontan a 2004" eran vulnerables. Eso se remonta a las primeras estimaciones de que todo desde PHP 5 estaba afectado, lo que CERT-EU admitió que se basa en publicaciones de redes sociales.

La empresa de seguridad de comercio electrónico Sansec sitúa el rango en PHP 5.4 y posteriores. Así que 2012, no 2004, aunque sigue siendo bastante antiguo.

PHP solo distribuye versiones oficiales para las versiones 8.2 y posteriores, lo que hace que la afirmación de "no hay solución para versiones antiguas" sea medio correcta. Dada la gravedad de esta, su equipo de seguridad también publicó parches de código fuente básicos para 7.4, 8.0 y 8.1, y las distribuciones de Linux están aplicando sus propios parches retroactivos.

La empresa de seguridad Mallory contabilizó alrededor de 884.000 hosts expuestos a internet que anunciaban PHP 8.1 o anterior el 20 de octubre, o el 59% de los aproximadamente 1,5 millones que muestran públicamente una versión. Un solo servidor de alojamiento compartido puede albergar muchos sitios web, por lo que el número de sitios detrás de ellos es mayor.

Algunos hilos también incluyeron a Node.js, una tecnología web diferente que casualmente programó su propia actualización de seguridad, no relacionada, para el mismo día. Mala coincidencia.

Incluso las versiones parcheadas no llegarán a todos los servidores a la vez. "Si dependes del repositorio mantenido por voluntarios https://rpms.remirepo.net, te instamos a que te pases ahora a los paquetes de la distribución o a compilar desde el código fuente, para que puedas aplicar las actualizaciones de inmediato. El repositorio no tendrá actualizaciones hoy", dijo la PHP Foundation en su declaración, refiriéndose a una popular fuente de paquetes de PHP para servidores Linux al estilo Red Hat mantenida por voluntarios.

¿Deberías preocuparte de verdad?

No deberías entrar en pánico, pero tampoco encogerte de hombros. Un sitio web hackeado, por ejemplo, no necesita tocar una blockchain para vaciar tu cartera. En 2024, los atacantes redirigieron los front ends de los protocolos DeFi Compound y Celer a páginas que drenaban las carteras conectadas, y Curve Finance sufrió un ataque similar en 2025.

Aquellos fueron secuestros de DNS, no errores de PHP, pero el truco es el mismo: el sitio parece correcto, la URL parece correcta, y el botón de "aprobar" envía tus tokens a otro lugar. Un servidor comprometido puede servir exactamente ese tipo de página.

Los hackers pueden volverse muy creativos, muy rápido, cuando se trata de exploits de día cero.

Los errores como estos también son cada vez más fáciles de encontrar, con modelos de IA de frontera usados cada vez más para encontrar vulnerabilidades de software, y los expertos dijeron a Decrypt en junio que podrían aparecer muchas más vulnerabilidades a medida que esas herramientas se extiendan.

Qué pasa después y qué hacer

Una vez que un parche es público, los atacantes pueden comparar el código antiguo y el nuevo para ver exactamente qué se corrigió, y el equipo forense de la firma de ciberseguridad Sansec dijo que espera que "los ataques masivos comiencen dentro de los 15 minutos posteriores al lanzamiento". Cuando otra falla de PHP se hizo pública en junio de 2024, Akamai experimentó intentos de explotación contra sus servidores señuelo en menos de 24 horas.

Entonces, ¿debería entrar en pánico la persona promedio? No exactamente. Tu teléfono, navegador y portátil no necesitan un parche de PHP; el trabajo recae en quienquiera que gestione los sitios web que utilizas.

Si gestionas un sitio, pregunta a tu proveedor de alojamiento si PHP se ha actualizado, y no cuentes con que WordPress lo haga por ti: Wordfence advirtió que las actualizaciones automáticas no aplicarán esta corrección e indicó a los propietarios de sitios que averigüen quién es responsable de actualizar PHP en sus servidores. Cualquiera que esté en 8.1 o una versión anterior necesita planificar una actualización.

"Lo único que puedo decir es que la única mitigación es parchear / actualizar PHP", dijo la desarrolladora del núcleo de PHP Gina Peter Banyard en Mastodon. "Lamentablemente sé demasiado".

Y si estás en PHP 8.2, la corrección que acabas de recibir es una de las últimas: esa versión alcanza el fin de su vida útil el 31 de diciembre de 2026, después de lo cual no recibirá más parches de seguridad.