🚨 La IA encontró en días cómo entrar a 7 de cada 10 sitios web. Cerrar la puerta llevó dos meses

🚨 El 21 de octubre, 4chan se puso en modo solo lectura, Pinboard bajó su sitio y partes de Wikipedia se apagaron por las dudas. Nadie los había hackeado. Estaban esperando un parche de PHP para dos fallas críticas bautizadas PHP2Shell.

Lo que me voló la cabeza no es la falla. Es cómo la encontraron: con IA, dos equipos por separado. Y los tiempos dan miedo: a la máquina le llevó días encontrar cómo entrar; a los humanos, dos meses cerrar la puerta ⏱️.

Encontrar un bug grave ya no es lo difícil. Lo difícil ahora es arreglarlo a tiempo. Te lo explico de a poco, porque vale la pena entenderlo bien 👇.

🐘 Primero, qué es PHP y por qué asustó tanto

Si no lo ubicás: PHP es el lenguaje de programación con el que está hecha buena parte de la web. WordPress, Drupal y Joomla están escritos en PHP. Según W3Techs, lo usa cerca del 69% de los sitios. Si tenés un blog, una tienda online o el sitio de tu empresa, hay muchas chances de que por debajo corra PHP 🌐.

Las dos fallas permitían algo que en seguridad se llama “ejecución remota de código”. Dicho simple: alguien desde afuera, sin usuario ni contraseña, podía hacer que tu servidor corriera lo que quisiera. Es como si un desconocido entrara a tu casa, se sentara en tu compu y la usara como propia, sin tocar el timbre 🚪.

Y aunque no llegara a tanto, Wiz mostró que la falla dejaba leer pedazos de la memoria del servidor, justo donde viven las contraseñas, los tokens y las claves de API. Por eso la reacción fue tan fuerte.

🔍 Dos días para entrar, dos meses para cerrar

Primero fue Calif, una firma de seguridad que revisaba el código de PHP con plata de Patch the Planet, un programa de OpenAI para buscar fallas en software open source crítico. En su reporte cuentan que arrancaron a fines de julio y que el 1 de agosto ya tenían el primer bug. Y aclaran algo clave: no usaron nada especial, solo modelos que cualquiera puede usar.

Semanas después, Wiz llegó a las mismas fallas por su cuenta, con su plataforma y los modelos Gemini 4 Argon y GPT-5.6 Sol. Mirá su línea de tiempo 👀:

• 19 de agosto: encuentran la primera falla.
• 20 y 21 de agosto: ya ejecutan código sin login en Drupal y en WordPress.
• 24 de agosto: se lo reportan al equipo de seguridad de PHP.
• 21 de septiembre: PHP acusa recibo y empieza a armar el arreglo.
• 21 de octubre: salen las versiones corregidas.

Dos días para tener un ataque funcionando. Dos meses para tener el parche.

PHP2Shell, en una línea

Esos meses de silencio tienen nombre: “divulgación coordinada”. Quien encuentra la falla no la publica enseguida: primero le avisa en privado al que mantiene el software, para que prepare el arreglo antes de que se enteren los atacantes.

Es como avisarle al encargado del edificio que la puerta de atrás no cierra, en vez de pegar un cartel en la vereda. Funciona, pero depende de que del otro lado haya alguien con tiempo para atender.

⚖️ La misma IA juega para los dos equipos

Acá viene la parte incómoda. Para aprovechar una falla hace falta un “exploit”, el programa que la usa para entrar. En PHP armar uno confiable era muy difícil, porque el comportamiento cambia con cada versión, cada configuración y cada servidor. Es tener la llave de una cerradura que cambia de forma en cada puerta 🔑.

Wiz cuenta que los modelos hicieron justamente eso: miraban por qué fallaba el ataque y lo iban ajustando, versión por versión. Su frase no deja dudas: “con IA, esto ya no es una barrera”. Una sola persona hizo en una semana lo que antes le llevaba meses a un equipo de primer nivel.

Eso vale para el que defiende y para el que ataca 😬. Las mismas herramientas que usó Wiz las tiene cualquiera.

OpenAI dice que espera que hallazgos de esta escala aumenten fuerte en los próximos meses. Le creo. Hace unos días conté que Anthropic ofrece escanear gratis proyectos open source importantes: los laboratorios compiten por encontrar bugs. Bien ahí 👍. Pero cada bug encontrado es un parche que alguien tiene que escribir, probar, publicar e instalar.

🧑‍🔧 El cuello de botella somos nosotros

Ojo, no es una crítica a la gente de PHP. Es un equipo chico sosteniendo el lenguaje de la mayoría de los sitios del mundo. Que un reporte tarde un mes en ser atendido no habla de desidia: habla de que el lado humano no escala al ritmo de las máquinas.

Y el plan tampoco salió como estaba previsto. Los detalles se filtraron en Hacker News antes de tiempo y PHP tuvo que adelantar el parche. Cloudflare activó reglas de protección para todos sus clientes, incluso los gratuitos, unas nueve horas antes del anuncio.

Los organismos de seguridad de Europa y del Reino Unido recomendaron considerar desconectar los sistemas hasta poder parchear. Por eso vimos sitios enormes bajarse solos: era más seguro apagar que esperar.

Para no exagerar: al momento del anuncio, CISA (la agencia de ciberseguridad de Estados Unidos) no había visto ataques reales, aunque Cloudflare ya reportaba los primeros intentos. Esta vez los buenos llegaron primero. La pregunta es cuántas veces más va a pasar.

Hay un detalle del reporte de Calif que me encantó 😄. La persona que encontró el bug conocía la historia de PHP y sus fallas viejas, y desde ahí le hizo las preguntas correctas al modelo. Ellos mismos lo dicen: ningún modelo encuentra “todos los bugs” con un prompt simple, “al menos por ahora”. La IA no reemplaza al que sabe. Lo multiplica.

🌎 ¿Tu PHP tiene arreglo? (y acá, más que nunca)

Si los bugs graves van a aparecer más seguido, gana el que parchea rápido. Y en nuestra región hay muchísimo PHP viejo: hostings compartidos, sitios de organismos públicos, sistemas internos que nadie se anima a tocar porque “andan”.

PHP publicó arreglos para 7.4, 8.0 y 8.1 aunque ya no tienen soporte, pero para lo anterior no hay nada. Y la falla viene desde PHP 5.4, que salió hace más de diez años.

Lo que yo haría esta semana:

• 📋 Saber dónde corre PHP. No “creo que en el sitio institucional”: una lista con cada servidor y su versión. Si hoy no la tenés, el día del próximo aviso vas a perder horas buscándola.
• ⏳ Parchear lo crítico en horas, no en semanas. Que actualizar PHP sea un proceso probado y aburrido, con pruebas automáticas que te digan si algo se rompió, no una aventura de viernes a la noche.
• 🔌 Tener el plan B decidido de antemano. Un WAF (firewall de aplicaciones web) es un filtro delante del sitio que frena los pedidos que parecen ataques, como un patovica en la puerta del boliche. Definí quién puede prenderle reglas nuevas o bajar un sitio sin esperar una reunión. 4chan y Wikipedia reaccionaron en horas porque alguien podía decidirlo.
• 🪦 Jubilar lo que no tiene soporte. Un PHP 5 olvidado no es “legacy”: es una puerta abierta que nadie va a volver a cerrar.

🎯 La carrera ya no es encontrar, es arreglar

Wiz compara a PHP2Shell con Heartbleed y Log4Shell, los dos sustos que nos enseñaron cuánto depende internet de piezas que mantienen pocas personas. Este agrega una lección nueva: con IA, encontrar fallas se volvió barato para todos. Lo caro, y lo que va a separar a los equipos que la pasan bien de los que no, es cuánto tardan en tener el parche instalado.

¿En tu equipo cuánto tarda un parche crítico en llegar a producción? ¿Horas, días, semanas? Contámelo, que te leo 👇.