Si has estado en internet hoy, seguramente has visto el pánico: una vulnerabilidad crítica amenaza con comprometer prácticamente todos los sitios web del planeta.

Finlandia empezó a desconectar sitios gubernamentales el miércoles, la NSA estadounidense está recomendando que todas las organizaciones que usan PHP apaguen sus sitios, y Países Bajos y Francia han hecho lo mismo. Y no, no se trata de un ciberataque de guerra.

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

PHP es el software que funciona entre bastidores en el servidor de un sitio web: el ordenador que almacena el sitio y construye cada página que solicitas. Cada sitio de WordPress, por ejemplo, está alojado en un servidor PHP, según la empresa de seguridad para WordPress Wordfence.

Por cierto, Wordfence también está fuera de servicio.

Dos fallos descubiertos recientemente en el propio PHP permiten que un desconocido ejecute sus propios comandos en el servidor sin necesidad de iniciar sesión. Los expertos en seguridad lo llaman ejecución remota de código no autenticada. Para el resto de nosotros, es como si alguien tomara “el control”.

Si ese servidor almacena tu cuenta, tu dirección o tu historial de pedidos, bueno, eso también pasa a ser suyo. La empresa de hosting GoDaddy ha advertido de que los fallos pueden permitir que los atacantes roben datos, desfiguren sitios web o se hagan con el control total de los servidores.

“Un fallo como este puede permitir que un atacante ejecute su propio código en un servidor expuesto a internet, lo que puede derivar en robo de datos, desfiguración de un sitio web o toma total del control”, afirma GoDaddy.

Lo que ha anunciado PHP

La Fundación PHP, organización sin ánimo de lucro que financia el desarrollo del lenguaje, emitió la alerta el martes. En un comunicado compartido en X, el equipo de seguridad de PHP informó: “El equipo de seguridad de PHP avisa con antelación: la próxima actualización de seguridad se publicará el miércoles 21 de octubre de 2026, a las 14:00 UTC, y corregirá dos vulnerabilidades críticas, ambas clasificadas como 9,2 en CVSSv4. Se aconseja a los usuarios de PHP que se preparen para actualizar. El lanzamiento se adelantará si los detalles se hacen públicos o si hay pruebas de explotación activa.”

La clasificación de 9,2 procede del CVSS, el Sistema Común de Puntuación de Vulnerabilidades, que evalúa lo peligrosa que es una vulnerabilidad en función de factores como la facilidad con la que puede explotarse a través de internet y el daño que puede causar. La escala va de 0 a 10, y cualquier valor por encima de 9,0 se considera crítico, de modo que estas dos vulnerabilidades son extremadamente graves, casi al máximo de 10.

La corrección se implementó hacia las 13:35 UTC del miércoles, unos minutos antes de lo previsto, para las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 de PHP. El aviso de seguridad no se anduvo con sutilezas: “Se recomienda encarecidamente a todos los usuarios de PHP que actualicen de inmediato.”

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

Cómo funcionan los fallos

El primer fallo, CVE-2026-109618, se manifiesta cuando PHP se queda sin memoria en mitad del procesamiento de una solicitud y, posteriormente, trata esos datos parcialmente procesados como si estuvieran completos. El segundo, CVE-2026-109619, permite que los datos residuales de la solicitud de un visitante permanezcan en memoria después del momento en que deberían haberse descartado, lo que puede causar problemas en la siguiente solicitud.

Imagina a un cocinero que lee pedidos de comandas que ya están en la basura. Pon una comanda falsa en la papelera y el cocinero preparará lo que hayas escrito en ella. En este caso, el “pedido” es el código del atacante y el servidor lo ejecuta.

PHP ha afirmado que el riesgo es mayor en servidores que utilizan una configuración común de Apache llamada mod_php, donde una vulnerabilidad demostrada funciona “incluso antes de que se ejecute ningún código de la aplicación”. Dicho de otro modo, las propias defensas del sitio, como las pantallas de inicio de sesión y los plugins de seguridad de WordPress, ni siquiera llegan a activarse.

Investigadores de la Fundación PHP señalaron la función de progreso de subida de PHP, que rastrea la cantidad de un archivo enviado, como una de las vías confirmadas de acceso. Está activada por defecto desde hace más de una década y pocos sitios la utilizan realmente.

Una filtración, seguida de ataques

Nada de esto debería ser público todavía. El martes, alguien publicó en el foro Hacker News que dos fallos de PHP se divulgarían ese jueves, admitiendo que no tenía “ninguna prueba más allá de ‘fuente: confía en mí, tío'”.

Resulta que el tío tenía razón. La empresa de seguridad watchTowr confirmó que los fallos eran reales y estaban bajo embargo —un acuerdo para mantener los detalles en secreto hasta que una corrección esté lista— y PHP adelantó su lanzamiento un día.

“Estamos viendo surgir los primeros ataques y actualizamos las medidas de mitigación a medida que aparecen nuevos vectores”, escribió Dane Knecht, CTO de Cloudflare, en X la mañana del miércoles, casi seis horas antes del lanzamiento de la actualización. Cloudflare implementó reglas de firewall de emergencia, filtros que bloquean patrones de ataque conocidos, para todos los clientes, pero Knecht las calificó de “solo una medida paliativa”.

Los gobiernos lo apagan todo

El centro estatal de TI de Finlandia, Valtori, empezó a desactivar los servicios web públicos como medida de precaución, informó la radiotelevisión pública Yle, mientras que la agencia nacional de ciberseguridad neerlandesa retiró su propio sitio web.

El Ministerio del Interior francés afirmó que los sitios web de las prefecturas se habían “desactivado temporalmente hasta que la editora del framework publique una actualización de seguridad”.

El CERT-EU, el equipo de respuesta a emergencias cibernéticas de la UE, aconsejó a las organizaciones que no hubieran podido aplicar la actualización que “consideren aislar las aplicaciones expuestas a internet de las redes públicas hasta que haya una corrección disponible”. Dicho de otro modo, “desconéctalo todo”. Agencias de Australia, Japón y Reino Unido dijeron prácticamente lo mismo, según Reuters.

En qué se equivocaron las publicaciones virales

Hilos virales en X afirmaban que versiones de PHP “de 2004” eran vulnerables. Esto se remonta a estimaciones iniciales según las cuales todo lo posterior a PHP 5 estaba afectado, algo que el CERT-EU reconoció que se basaba en publicaciones en redes sociales.

La empresa de seguridad para comercio electrónico Sansec indica que el problema aparece a partir de PHP 5.4. Es decir, de 2012, no de 2004, aunque sigue siendo una versión muy antigua.

PHP solo publica actualizaciones oficiales para las versiones 8.2 y posteriores, lo que hace que la afirmación de que “no hay corrección para las versiones antiguas” sea solo parcialmente cierta. Dada la gravedad de esta vulnerabilidad, su equipo de seguridad también ha publicado parches básicos de código fuente para las versiones 7.4, 8.0 y 8.1, y las distribuciones de Linux están implementando correcciones retroactivas por su cuenta.

La empresa de seguridad Mallory contabilizó alrededor de 884.000 servidores de hosting expuestos a internet que anunciaban PHP 8.1 o versiones anteriores el 20 de octubre, lo que representa el 59% de los aproximadamente 1,5 millones que muestran públicamente una versión. Un único servidor de hosting compartido puede alojar muchos sitios web, por lo que el número de sitios afectados es aún mayor.

Algunos hilos también mencionaron Node.js, una tecnología web distinta que casualmente había programado su propia actualización de seguridad, no relacionada con esta vulnerabilidad, para el mismo día. Pésima elección de momento.

Ni siquiera las versiones corregidas llegarán a todos los servidores a la vez. “Si dependes del repositorio voluntario https://rpms.remirepo.net, te recomendamos que migres a paquetes de tu distribución o que compiles desde el código fuente ahora, para poder aplicar las actualizaciones de inmediato. El repositorio no tendrá actualizaciones hoy”, dijo la Fundación PHP en su comunicado, en referencia a una fuente popular de paquetes PHP para servidores Linux del tipo Red Hat, mantenida por voluntarios.

¿Deberías preocuparte?

No deberías entrar en pánico, pero tampoco ignorar el problema. Un sitio web hackeado, por ejemplo, no necesita acceder a una blockchain para vaciar tu wallet. En 2024, atacantes redirigieron las interfaces de los protocolos DeFi Compound y Celer hacia páginas que drenaron los monederos conectados, y Curve Finance sufrió un ataque similar en 2025.

Esos fueron ataques de secuestro de DNS, no fallos de PHP, pero el truco es el mismo: el sitio web parece correcto, la URL parece correcta y el botón “aprobar” envía tus tokens a otro lugar. Un servidor comprometido puede mostrar exactamente ese tipo de página.

Los hackers pueden ser muy creativos y muy rápidos cuando se trata de exploits de día cero.

Fallos como estos también son cada vez más fáciles de encontrar, ya que los modelos de IA punteros se usan cada vez más para hallar vulnerabilidades de software, y expertos dijeron a Decrypt en junio que podrían surgir muchas más vulnerabilidades a medida que estas herramientas se extiendan.

¿Qué pasa ahora y qué hay que hacer?

En cuanto se publica una corrección, los atacantes pueden comparar el código antiguo y el nuevo para ver exactamente qué se ha corregido, y el equipo forense de la empresa de ciberseguridad Sansec dijo que espera que “los ataques masivos comiencen en los 15 minutos siguientes al lanzamiento”. Cuando se divulgó un fallo distinto de PHP en junio de 2024, Akamai sufrió intentos de explotación contra sus servidores señuelo en 24 horas.

Entonces, ¿debería entrar en pánico el usuario corriente? No exactamente. Tu móvil, tu navegador y tu portátil no necesitan una corrección de PHP; el trabajo recae en quienes administran los sitios web que usas.

Si administras un sitio web, pregunta a tu proveedor de hosting si PHP se ha actualizado y no confíes en que WordPress lo haga por ti: Wordfence ha advertido de que las actualizaciones automáticas no aplicarán esta corrección y ha instado a los propietarios de sitios web a averiguar quién es responsable de actualizar PHP en sus servidores. Cualquiera que use la versión 8.1 o anterior necesita planificar una actualización.

“Lo único que puedo decir es que la única solución es aplicar los parches o actualizar PHP”, dijo Gina Peter Banyard, desarrolladora del núcleo de PHP, en Mastodon. “Por desgracia, sé demasiado.”

Y si estás usando PHP 8.2, la corrección que acabas de recibir es una de las últimas: esa versión llega al final de su vida útil el 31 de diciembre de 2026, tras lo cual no recibirá más parches de seguridad.

* Traducido y editado con autorización de Decrypt.

La puerta de entrada al bitcoin, la mayor criptomoneda del mundo, está en MB. Es sencillo, seguro y transparente. Deja de posponer una inversión con un potencial enorme. ¡Invierte en pocos clics!