PHP: el fallo crítico que expone al 70% de la web

Qué ha pasado con PHP y por qué importa más allá de PHP

El 21 de octubre el proyecto PHP publicó parches de emergencia para dos fallos críticos en el núcleo del lenguaje, bautizados en conjunto como PHP2Shell y registrados como CVE-2026-109618 y CVE-2026-109619. Ambos puntúan 9,2 sobre 10 en la escala CVSS v4.0, según The Hacker News. No son fallos de una aplicación concreta: están en el motor del lenguaje, así que cualquier instalación de PHP que atienda peticiones web queda expuesta, incluso si el código propio del sitio es impecable.

La escala explica la alarma. Wiz describe PHP como «la columna vertebral de la web» y estima que impulsa el 70% de las páginas del mundo, según recoge ElOtroLado. El profesor Alan Woodward, del Surrey Centre for Cyber Security, dijo a la BBC que la cifra de sitios afectados ronda los 30 millones y que se trata de una vulnerabilidad de ejecución remota de código: «un atacante puede meter su propio código en el servidor y ejecutarlo, y básicamente hacer lo que quiera». Puede robar datos, moverse a otras partes de la red o dejar una puerta trasera para volver después.

La propia PHP Foundation fue tajante en su aviso: «No hay mitigaciones completas, actualizar es la única opción segura». Los parches están en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

El fallo que la PHP Foundation vio en 2024 y no pudo cerrar

Un desarrollador del núcleo detectó los primeros indicios del fallo de gestión de memoria detrás de CVE-2026-109618 durante una auditoría externa en 2024, pero entonces solo se teorizó un posible ataque y no se encontró una ruta concreta hacia la ejecución de código. Las correcciones en competencia arriesgaban romper la compatibilidad, abrir vías de denegación de servicio o forzar cambios en extensiones de terceros. Un equipo pequeño no logró ponerse de acuerdo y el trabajo se estancó durante meses.

La Fundación calificó esa demora como «un fallo estructural» de su proceso de decisión y de sus recursos, según The Hacker News. Es exactamente el punto que plantea Xataka: que un sistema funcione bien durante años no garantiza que sea seguro. Corregir un componente obliga a tocar otros, y en infraestructura crítica ese efecto dominó da miedo. El resultado es que internet —y buena parte del software corporativo— sigue corriendo sobre piezas que nadie se atreve a mover.

Por qué la IA cambió el cálculo

Los fallos llevaban más de una década en el código. En 2026 PHP entró en Patch the Planet, una iniciativa de OpenAI para reforzar la seguridad de proyectos de código abierto. Calif arrancó una auditoría el 30 de julio y el 11 de agosto uno de sus investigadores reportó ejecución remota de código usando GPT-5.6 Sol; Wiz llegó a los mismos fallos de forma independiente. Según El Mundo, el equipo corrigió cerca de 200 archivos y escribió más de 10.000 líneas de código.

Ami Luttwak, cofundador de Wiz, lo llamó «la vulnerabilidad de IA más grave que se ha encontrado jamás». Y ahí está el problema de fondo: la misma capacidad que permite encontrar el fallo permite explotarlo. Thai Duong, CEO de Calif, lo dijo sin rodeos: «Cualquier tipo en Twitter podría coger los parches, aplicarles la IA y publicar algún script de explotación».

Los números de explotación confirman el temor. Matthew Prince, CEO de Cloudflare, escribió que en las 10 horas previas al anuncio público se vieron miles de intentos de explotación, que saltaron a decenas de miles en los 45 minutos posteriores, a cientos de miles en dos horas y a millones después, según Mirror. El CTO de Cloudflare, Dane Knecht, calificó sus reglas de firewall como un parche temporal y pidió actualizar. Ninguna fuente confirmó una intrusión exitosa.

El proceso de divulgación tampoco fue limpio: la noticia se filtró en Hacker News el 20 de octubre, Calif publicó por error un vídeo con su prueba de concepto y Chainguard distribuyó imágenes con el parche unas seis horas antes del anuncio oficial, según The Hacker News. En un mundo donde la IA lee parches en minutos, cada hora de ventaja cuenta.

¿Qué significa esto para tu startup?

La lección no es sobre PHP. Es sobre qué parte de tu stack no controlas y desde cuándo no la miras. Si tu producto corre sobre un runtime, una librería o una imagen de contenedor que nadie actualizó en dos años, tienes el mismo problema en miniatura.

Hay un detalle que se repite en casi todas las startups: el equipo actualiza el framework y cree que está al día. No lo está. Actualizar WordPress o Laravel no actualiza el runtime de PHP que hay debajo; eso viene del paquete del servidor, del hosting o de la imagen del contenedor, según The Hacker News. Es el punto ciego más común.

¿Cómo revisar tu stack esta semana?

• Haz inventario de runtimes, no de frameworks. Lista la versión exacta de PHP, Node, Python o Java que corre en producción, en staging y en cada contenedor. Si no puedes responderlo en cinco minutos, ese es tu primer hallazgo.
• Verifica el changelog, no el número de versión. Las distribuciones de Linux y los proveedores de soporte largo reciben los parches antes y pueden publicarlos bajo una versión que parece antigua. Debian recomienda buscar el CVE en el changelog del paquete, según The Hacker News.
• Define una ventana de parcheo y un responsable. No un comité: una persona con nombre y una fecha límite. El fallo de PHP estuvo abierto desde 2024 en parte porque nadie era el dueño de la decisión.
• Usa IA para auditar tu propio código, no solo para escribirlo. La misma tecnología que encontró PHP2Shell sirve para revisar dependencias y detectar patrones raros. Google Cloud describió cómo sus ingenieros usaron modelos de IA para localizar y validar fallos de PHP, desarrollar pruebas de explotación y comprobar las correcciones, según Xataka.
• Revisa la configuración de memoria después de actualizar. El parche añade un límite duro de memoria nuevo: al alcanzarlo, el proceso termina y los manejadores de apagado no se ejecutan. Comprueba memory_limit y post_max_size contra lo que tu aplicación necesita, según The Hacker News.
• Mira el calendario de fin de vida. PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto, y PHP 8.2 llega a fin de vida el 31 de diciembre de 2026. Si tu stack depende de esa rama, tienes una migración pendiente con fecha.

Conclusión

El episodio de PHP deja dos verdades incómodas. La primera: la IA está encontrando a gran velocidad fallos que llevaban décadas escondidos, y eso convierte el software antiguo en un pasivo que se revaloriza en riesgo cada trimestre. La segunda: encontrar el fallo es la parte fácil; arreglarlo en un ecosistema que depende de la compatibilidad hacia atrás es la parte que se atasca.

Para un founder, la traducción es simple. La deuda técnica dejó de ser una discusión estética sobre código feo y pasó a ser una línea de riesgo operativo. No hace falta reescribir nada: hace falta saber qué versiones corres, quién las actualiza y cuándo. Ese inventario, hecho esta semana, vale más que cualquier plan de modernización a dos años.

Fuentes

• Xataka: Lo que ha sucedido con PHP nos avisa
• The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws
• Mirror: Cybersecurity expert warns situation is 'serious'
• ElOtroLado: Dos fallos en PHP descubiertos con ayuda de la IA
• El Mundo: La IA detecta un fallo que pone en riesgo hasta al 70% de las páginas web del mundo