La IA ayudó a encontrar el agujero en PHP, pero parchear servidores antiguos sigue siendo cosa de personas

El miércoles 21 de octubre, los desarrolladores de PHP publicaron las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, anunciadas un día antes sin detalles. Corrigen dos vulnerabilidades conocidas en conjunto como PHP2Shell, ambas con una puntuación de 9,2 sobre 10 en la escala CVSS. Son más peligrosas en servidores Apache con mod_php: allí un atacante puede ejecutar su propio código sin iniciar sesión, solo con peticiones HTTP, antes de que la web ejecute una sola línea. Pero tampoco se libran otras formas de ejecutar PHP, incluido el popular PHP-FPM. PHP mueve alrededor del 69 % de las webs cuyo lenguaje del lado del servidor puede identificarse, entre ellas Wikipedia y las webs hechas con WordPress, según The Verge, que cita datos de W3Techs. Del descubrimiento informamos el miércoles.

El código vulnerable más antiguo se remonta a PHP 5.4, publicado en 2012. El error de fondo, en la gestión de la falta de memoria, se detectó ya en 2024, al corregir problemas señalados por una auditoría externa. Pero nadie demostró cómo aprovecharlo, así que el equipo de seguridad de PHP, al que le faltaba gente, fue aplazando la corrección: la PHP Foundation lo califica de «fallo estructural». En agosto de este año, Calif y OpenAI notificaron el error por separado, y dos semanas después lo hizo Wiz, propiedad de Google.

Wiz explica que utilizó los modelos Gemini 4 Argon y GPT-5.6 Sol junto con su propia herramienta, Wiz Atlas. Según la empresa, «con modelos de IA de frontera y las herramientas adecuadas, un solo investigador completó en una semana lo que antes le habría llevado meses de trabajo a un equipo de primer nivel mundial». Qué modelo ayudó a Calif solo lo sabemos por OpenAI. Calif buscaba fallos dentro de Patch the Planet, un programa que dirige OpenAI, y fue OpenAI quien anunció que la vulnerabilidad se había encontrado con GPT-5.6 Sol. La propia Calif no menciona el modelo y se limita a decir que utilizó modelos al alcance de cualquiera.

La IA también acelera a los atacantes. CJ Moses, director de seguridad de la información de Amazon, explica que antes la mayoría de los ataques empezaban solo cuando ya se había publicado un exploit funcional. Según Moses, la IA permite ahora construir a bajo coste un exploit funcional a partir únicamente del parche o del aviso de seguridad. Eso significa que más atacantes pueden golpear a las pocas horas, o incluso minutos, de que se hagan públicos los detalles. Matthew Prince, consejero delegado de Cloudflare, afirmó que Cloudflare detectó en su red decenas de miles de intentos de explotación en los 45 minutos posteriores a la publicación del parche, y millones en menos de 12 horas.

Algunos atacantes ni siquiera esperaron al parche. Según la PHP Foundation, los identificadores de las vulnerabilidades se filtraron en internet la víspera de la publicación, y Calif colgó por error, durante un rato, un vídeo de un ataque funcional. Cloudflare registró miles de intentos en las 10 horas anteriores a la publicación del parche. Amazon encontró en sus datos un intento aún anterior, del 17 de octubre, antes de la filtración. Nadie sabe cómo alguien conocía el fallo tan pronto. Eso sí, hasta ahora no se ha confirmado ninguna intrusión con éxito.

Algunas instituciones prefirieron no esperar. Como informa CNBC citando a Reuters, los Países Bajos desconectaron, entre otros, el portal gubernamental Overheid.nl, la web del puerto de Róterdam e incluso la del NCSC, el propio centro nacional de ciberseguridad del país. En Finlandia, Valtori, el proveedor estatal de servicios informáticos, desconectó de internet los servicios públicos de la administración, y Francia retiró de la red las webs de las administraciones locales. CERT Polska, el CERT nacional de Polonia, ya recomendó lo mismo antes de que saliera el parche: apagar temporalmente los servicios con PHP accesibles desde internet, siempre que eso no perturbara el trabajo de la organización. La agencia estadounidense CISA aconseja desconectar los sistemas que no puedan actualizarse de inmediato, así como todo lo que funcione con PHP 8.1 o anterior.

Algunos administradores ya han actualizado sistemas antiguos con ayuda de la IA y lo cuentan en foros. En Reddit, alguien escribe: «Solo me llevó 30 minutos con Claude actualizar un complejo sistema LMS de la 5.6 a la 8.5». Una persona que administra cientos de webs con Drupal 7 cuenta que sin IA estas actualizaciones habrían llevado meses y que ahora Claude Code corrige los errores que aparecen tras cambiar de versión de PHP. Otra persona que administra sistemas describe cómo pasó dos horas con un agente revisando sus sistemas y planificando la actualización. Después le pidió que preparara un panel con un resumen y se fue a comer. En Hacker News, alguien escribió que Claude convirtió su blog de MediaWiki en páginas estáticas, de modo que el blog puede funcionar sin PHP hasta que se parchee el servidor. Son solo relatos de sus propios autores y nadie los ha verificado.

Pero son historias de gente que sabía lo que hacía y pudo pasarse a una versión nueva sin prisas. Quien hoy tenga que rescatar a toda prisa un servidor de producción lo tiene mucho más difícil, y de esos servidores hay muchísimos. Recorded Future cita análisis de VirusTotal: los servidores de unos 1,1 millones de direcciones IP revelan su versión de PHP, y 758 000 de ellos, casi el 70 %, ejecutan PHP 8.1 o anterior. El equipo de PHP ya no da soporte a esas versiones y no ha sacado para ellas ninguna versión con la corrección. La agencia estadounidense CISA aconseja desconectar esos servidores hasta que se actualicen.

Quedan las correcciones de las distribuciones de Linux y de los paneles de control de hosting, pero no a todo el mundo le llegarán. Según un resumen de Digital Applied, Amazon no tiene ninguna intención de parchear algunos paquetes de PHP en Amazon Linux. Ubuntu 20.04 solo recibió la corrección en Ubuntu Pro, que es gratuito en un máximo de cinco máquinas. Por eso Laravel Forge aconseja sustituir por uno nuevo cualquier servidor con Ubuntu 20.04 o anterior y apagar el antiguo.

Sin un paquete listo, solo quedan las correcciones del código fuente que el equipo de PHP publicó para las versiones 7.4, 8.0 y 8.1. Hay que aplicarlas por cuenta propia y compilar PHP, con las mismas extensiones que antes. Las versiones más antiguas ni siquiera recibieron eso. Alguien en Reddit tiene una web con PHP 5.6, así que le encargó a Claude portar las correcciones a esa versión. Y enseguida reconoció: «¿Se puede usar? Quién demonios lo sabe».

Incluso después de actualizar, es difícil saber si un servidor está a salvo. El número de versión que muestra php -v no lo aclara: en el resumen de Digital Applied, 21 de las 76 entradas son paquetes que recibieron la corrección pero conservaron el número de versión antiguo. Ubuntu 24.04, por ejemplo, sigue mostrando 8.3.6 tras la actualización. Incluso la herramienta de OpenAI para comprobar servidores advierte de que un resultado «UNKNOWN» no significa «parcheado». Además, instalar la corrección no es el final. Hay que reiniciar todos los procesos de PHP-FPM, porque los que se iniciaron antes de la actualización siguen ejecutando el código antiguo y vulnerable. En los servidores con cPanel o Plesk, cada versión de PHP instalada tiene que parchearse por separado.

Los apaños rápidos tienen un precio. Bloquear las peticiones multipart, algo que recomienda Sansec entre otros, impide subir archivos y, en algunas tiendas, como reconoce la propia empresa, también rompe el carrito de la compra. Quitar el límite de memoria (memory_limit=-1) esquiva el error de falta de memoria, pero entonces una sola petición puede consumir toda la memoria del servidor. Y el equipo de PHP advierte de que ningún ajuste protege por completo.

La IA también falló. Según clientes de Hostinger, el chatbot de la empresa insistía en que PHP-FPM no era vulnerable, aunque los desarrolladores de PHP dicen claramente que sí lo es. En Hacker News, varias personas se quejaron de que los filtros de seguridad de Claude y Codex interrumpían su trabajo con la vulnerabilidad.

De estos relatos se desprende una división sencilla. La IA acelera mucho el trabajo de quien sabe en qué modo funciona PHP en su servidor, de dónde vienen los paquetes y qué comprobar tras una actualización. Quien no lo sabe también obtendrá un plan listo, pero no podrá juzgar si es bueno.

Quien tenga una web pero no gestione el servidor puede empezar por hacer dos preguntas a la persona que se encarga de él: si la corrección ya está instalada y si alguien ha revisado los registros desde el 17 de octubre, cuando Amazon detectó el primer intento de explotación. Si nadie sabe responder, alguien que comenta en Hacker News sugiere plantearse un hosting gestionado, en el que el proveedor mantiene PHP al día.

Glosario: CVSS - escala de 0 a 10 que se usa para valorar la gravedad de una vulnerabilidad de seguridad. Exploit - programa o secuencia de peticiones que aprovecha en la práctica una vulnerabilidad. mod_php - PHP ejecutado como módulo del servidor web Apache. PHP-FPM - PHP ejecutado como un conjunto independiente de procesos al que el servidor web pasa las peticiones. Multipart - formato de petición HTTP que usan los navegadores para enviar formularios con archivos.