¿Tu web en peligro? La crisis de PHP: por qué millones de webs siguen expuestas

 

Como en otras ocasiones desde que tenemos a la IA «jugando» con la seguridad de sistemas y aplicaciones, ha explotado en menos de 24h una crisis de proporciones inabordables: Entre el 20 y el 23 de octubre de 2026, el proyecto PHP publicó actualizaciones de emergencia para corregir tres vulnerabilidades en su núcleo, dos de ellas críticas y capaces de permitir a un atacante remoto, sin autenticación, ejecutar código arbitrario en cualquier servidor que atienda peticiones web (vamos que no necesita usuario y contraseña, porque hay vulnerabilidades que permiten un acceso no autorizado, una puerta de atrás). Administraciones europeas llegaron a desconectar temporalmente sitios oficiales mientras instalaban los parches.

 

Y hay un detalle que lo cambia todo: según la prensa, los dos fallos principales los descubrió un modelo de inteligencia artificial de OpenAI, no un equipo de seguridad humano.

 

 

1. Qué pasó exactamente

 

• 20 de octubre: el proyecto PHP anuncia una publicación de seguridad inminente para dos vulnerabilidades críticas del núcleo.

 

• 21 de octubre (13:30 UTC): salen las versiones corregidas — 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

 

• CVE-2026-109618 (CVSS 9,2): ejecución remota de código por corrupción de memoria durante el manejo del agotamiento de memoria (OOM). Cuando una petición supera memory_limit, PHP interrumpe el procesamiento con longjmp(); si los datos de la petición estaban solo parcialmente inicializados (por ejemplo, en mitad de una carga multipart), la limpieza de la petición puede tratar datos inválidos como válidos y liberar memoria que nunca fue inicializada. PHP validó la ejecución remota de código sin autenticación contra Apache mod_php, antes de que se ejecute cualquier código de la aplicación.

 

• CVE-2026-109619 (CVSS 9,2): ejecución remota de código por uso de estado global obsoleto. Parte del estado interno asociado a una petición puede sobrevivir en el proceso trabajador después de liberarse su memoria; una petición posterior en el mismo trabajador puede usar ese estado antes de que PHP lo reinicialice (uso después de liberar). PHP confirma rutas en mod_php y PHP-FPM, y en 8.5 también una ruta ligada a las trazas de errores fatales.

 

• Todas las instalaciones que sirven peticiones web están en riesgo: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera mod_php la configuración de mayor riesgo.

 

• INCIBE CERT avisa de que se comunicaron ataques contra servidores PHP antes de la publicación de las actualizaciones.

 

• 23 de octubre: se divulga una tercera vulnerabilidad, CVE-2026-115560 (también RCE), que solo afecta a aplicaciones web configuradas de forma poco habitual; PHP no ha emitido una versión extraordinaria para ella y la corregirá en la próxima publicación regular.

 

• Para las ramas ya fuera de soporte (8.1 y anteriores), PHP ha publicado parches mínimos de código fuente para 7.4, 8.0 y 8.1.

 

 

 

2. Por qué siguen existiendo millones de webs sin parche

 

Las estimaciones del mercado sitúan a PHP en torno al 70% de los sitios web del mundo como tecnología de servidor. Que una brecha así deje expuesta a una parte enorme de esa base no es un accidente puntual: es estructural, y tiene varias causas que se refuerzan entre sí.

 

1. Una cola de legado larguísima. Miles de sitios siguen corriendo PHP 5.x o 7.x, versiones fuera de soporte desde 2019. Por diseño, esas ramas ya no reciben parches: cada día que pasa, la exposición crece.

 

2. «Si funciona, no lo toques». Actualizar la versión de PHP rompe temas y plugins; el miedo a tumbar un sitio productivo frena la migración durante años.

 

3. Inventario inexistente. Muchas organizaciones no saben qué servidores, qué aplicaciones o qué productos de terceros ejecutan PHP. En el hosting compartido, ni siquiera se conoce la versión instalada.

 

4. PHP embebido. Productos comerciales y open source incluyen PHP por dentro y pueden verse afectados aunque no expongan directamente el intérprete. El NCSC holandés mantiene un repositorio público con el software de terceros que incorpora PHP.

 

5. Parchear no es un clic. Exige planificar el cambio, reiniciar workers, probar y vigilar. Muchos sitios son despliegues únicos de hace años, sin dueño ni proceso de cambios.

 

6. Coste y talento. Las pymes sin equipo de sistemas no tienen a quién encargarlo; migrar cuesta dinero y tiempo que no aparece en ningún presupuesto.

 

7. Responsabilidad fragmentada. Núcleo + extensiones + CMS + plugins: decide el eslabón más débil, y a menudo no es el propio PHP.

 

8. Incentivos económicos. Hasta que llega una crisis como esta, el riesgo era abstracto: no había caso de negocio claro para actualizar.

 

3. La duda: ¿casualidad o una puerta dejada abierta a propósito?

 

Vamos a ser rigurosos: no existe evidencia pública de que estas vulnerabilidades fueran creadas a propósito. Son errores clásicos de C —corrupción de memoria, uso después de liberar— acumulados durante décadas; según la prensa, uno de ellos llevaba más de veinte años presente en el código.

 

Pero la pregunta que conviene plantear es otra: ¿cómo es posible que un lenguaje que sostiene a gran parte de la web acumule agujeros críticos que miles de desarrolladores no detectan durante años, hasta que los encuentra una IA?

 

El debate tiene precedente. Desde las filtraciones de Snowden (2013) y Vault 7 se sabe que agencias de inteligencia acumulan zero-days como herramientas ofensivas y presionan a los fabricantes para no publicarlos. Casos como SolarWinds o Log4Shell muestran lo que ocurre cuando un agujero sale a la luz: explotación masiva y urgente. Existe, además, un debate real sobre el «acopio» de vulnerabilidades: algunos Estados prefieren no corregir públicamente ciertos fallos para conservarlos como capacidad operativa.

 

El contraargumento también es fuerte. PHP es uno de los proyectos open source (de código abierto) más examinados del mundo; una puerta trasera plantada deliberadamente habría sido detectada por la comunidad y destruiría el valor mismo de la herramienta. Los incentivos apuntan a negligencia y deuda técnica, no a mala fe.

 

Lo que queda abierto —y es legítimo mantenerlo— es la cadena completa: quién descubre el agujero primero (cada vez más, las IAs), quién decide cuándo se divulga y quién se beneficia del retraso. Que se observaran ataques antes de publicar el parche demuestra que el ecosistema depende de la buena voluntad de quien encuentra primero el fallo. Es una duda razonable, no una acusación: las evidencias disponibles apuntan a economía y deuda técnica, pero el mecanismo de descubrimiento y divulgación sigue siendo un punto débil del que dependen millones de sitios.

 

4. ¿Hay más vulnerabilidades?

 

Sí, y en tres frentes:

 

• CVE-2026-115560: la tercera RCE, revelada el 23 de octubre, afecta solo a configuraciones poco habituales; hasta la próxima versión regular, la mitigación recomendada es desactivar session.upload_progress.enabled y reiniciar todos los workers.

 

• Ramas fuera de soporte: PHP 8.1 y anteriores no reciben parches regulares. Solo existen backports de código fuente para 7.4, 8.0 y 8.1, o retroportaciones de distribuidores y proveedores LTS. Un sitio en esas ramas sigue expuesto por diseño.

 

• Software de terceros que embebe PHP: puede estar afectado aunque no exponga el intérprete; conviene revisar el repositorio del NCSC-NL.

 

Y en perspectiva: PHP lleva décadas acumulando CVEs menores; esta crisis es su episodio más visible, no su único fallo.

 

5. Qué hacer si ejecutas PHP

 

1. Actualiza ya a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o a la versión corregida de tu distribuidor o proveedor LTS).

2. Si estás en 7.4, 8.0 u 8.1: aplica el backport de código fuente o migra a una rama soportada.

3. Mientras no puedas parchear: aplica las mitigaciones de INCIBE/CERT-EU (memory_limit=-1 de forma administrativa, post_max_size bajo, session.upload_progress.enabled=0, reinicio de workers). Reducen la exposición, no son solución.

4. Si no puedes parchear y estás expuesto a Internet: aísla el sistema de las redes públicas hasta aplicar la corrección.

5. Haz inventario: localiza todos los PHP, incluidos los embebidos en productos de terceros.

6. Vigila las fuentes oficiales: INCIBE CERT, CISA, CERT-EU y la página de seguridad del proyecto PHP.

 

Linkedin: Aquilino García