Hace diecisiete años escribí aquí un post que se titulaba Phishing de mierda. Me reía de un correo cutre que intentaba robarme la cuenta del banco. En aquella época, buena parte de la seguridad de internet se sostenía sobre la torpeza de los malos.
Ya no me río tanto.
Lo que había debajo
El 21 de octubre PHP publicó parches de emergencia para dos fallos críticos, CVE-2026-109618 y CVE-2026-109619, a los que ya llaman PHP2Shell y que permiten ejecutar código en remoto sin necesidad de autenticarse. PHP está detrás de algo así como el 70 % de las webs: WordPress, Drupal, Joomla, la Wikipedia... y la aplicación que estás leyendo (que nadie se asuste, ya está parcheada).
Lo curioso del tema es quién lo encontró: en agosto, la firma Calif dio con uno de ellos usando un modelo de OpenAI, y Wiz encontró los dos por su cuenta combinando varias herramientas de IA.
La cosa no acaba ahí, uno de los fallos ya había asomado en 2024, en la primera auditoría externa que pasaba PHP en años, y por lo que fuera, alguien decidió no hacer nada.
Las bragas de Internet ya estaban ahí.
No es que la IA esté rompiendo internet, saca a la luz sus vergüenzas. Algunos de estos agujeros llevaban años en el código sin que nadie se fijara, pero el precio de encontrarlos es de unos cientos de euros. Antes hacía falta un experto, mucha paciencia y algo de suerte; ahora basta un modelo y alguien que le pregunte.
Seguridad por oscuridad
En El lenguaje de Dios conté la anécdota de aquella contraseña en esperanto: nadie la iba a adivinar, por la sencilla razón de que casi nadie habla esperanto.
Internet entero funcionaba un poco así. No es que el código fuera seguro, es que mirarlo era caro, y millones de líneas de C escritas hace veinte años, revisadas por cuatro voluntarios en sus ratos libres, sobrevivían porque confiábamos en que nadie tendría tiempo de leerlas todas.
Tenemos un problema cuando el esfuerzo y el tiempo dejan de serlo.
Encontrar es barato, arreglar no
Llevamos un año de vértigo, en septiembre se corrigieron 998 vulnerabilidades alrededor del Patch Tuesday, cuando en el mismo periodo del año anterior fueron 96, y el FIRST calcula que 2026 cerrará cerca de las 66.000 CVE. Diez veces más trabajo para los mismos equipos de siempre.
Y los equipos no han crecido: solo un 9 % de las organizaciones parchea una vulnerabilidad grave en menos de 24 horas, el resto tarda días o semanas.
Hay más, porque la avalancha no es solo de fallos reales. curl cerró en enero su programa de recompensas porque se ahogaba en informes de baja calidad generados con IA, y alguien tiene que leerlos todos para descubrir que eran paja.
¿Y si dejamos que la IA también haga los parches? Ya se ha estudiado, y más de la mitad de las veces el parche generado por IA no arregla el fallo o mete uno nuevo. Lo conté en El embudo tecnológico: la IA busca la solución suficiente, no la mejor. Con los parches pasa lo mismo, y a veces ni eso.
Lo acojonante es que los parches de PHP solo llegan a la versión 8.2 en adelante, y lo anterior no recibe nada. Cisco Talos calcula que la mitad de los sistemas vulnerables podrían quedarse sin parche. Si tienes un servidor olvidado con PHP 7 en una esquina... ya sabes lo que hay.
La carrera de camellos
El parcheo de errores funciona así: el investigador avisa, el proyecto prepara el parche en silencio y, cuando está listo, se publica todo a la vez. Todo con el máximo secretismo...
Los identificadores de PHP empezaron a circular por foros el 20 de octubre, sin detalles técnicos y con una puntuación equivocada, y PHP tuvo que adelantar el parche un día. Según Xataka, que cita a Amazon, uno de sus señuelos registró un intento de explotación el 17 de octubre: cuatro días antes de la divulgación. Nadie sabe cómo llegó el atacante a esa información.
Si encontrar fallos es barato para los buenos, también lo es para los malos. La diferencia es que los malos no avisan.
Y luego está quien no avisa por otros motivos... OpenCode, una herramienta de programación con IA, corrigió en septiembre un fallo crítico de ejecución de código sin publicar CVE ni aviso. Sin CVE, los escáneres de dependencias no lo ven: lo tienes instalado, el escáner te dice que todo está ok, y tú tan tranquilo.
También son nuestras las bragas nuevas.
Las herramientas de IA que usamos para programar se han convertido en el cajón de los calcetines de nuestra casa digital, el sitio donde guardamos las llaves de todo.
LiteLLM, la pasarela que mucha gente pone delante de varios modelos, ha tenido este año una inyección SQL sin autenticación que se explotó en la práctica poco después de publicarse. En marzo aparecieron paquetes falsos en PyPI que robaban credenciales de proveedores de IA. Y de OpenCode se informó que alguien accedió a un sistema antiguo de su consola, y que pudieron quedar expuestas claves de OpenAI, Anthropic o Google de alrededor del 1,4 % de sus usuarios.
Con una clave de API robada, te roban los tokens, y eso no lo arregla ninguna actualización. Cuando se pierde un secreto, el parche no lo devuelve: hay que cambiarlo.
¿Y ahora qué?
Ante esto, solo nos queda dar por hecho que el bug ya existe. Actualizar, claro, pero también mirar los registros, cambiar las claves que hayan pasado por herramientas de terceros y dejar de confiar en que un servidor está seguro, desconfianza por default.
Para los que tengáis servidores a vuestro cargo, la lista de deberes de esta semana:
- PHP: 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o el paquete equivalente de tu distribución. Y revisar registros desde el 17 de octubre.
- GitLab propio: 19.4.2, 19.3.5 o 19.2.8 como mínimo (otro fallo con un 10 de 10, este en las expresiones regulares de CI/CD).
- Node.js: actualizar y reconstruir las imágenes de Docker que llevan su propio Node.
- Java: la actualización trimestral de octubre de Oracle.
- LiteLLM y OpenCode: actualizar y rotar las claves de proveedores que hayan pasado por ellos.
- Certificados: sistema y navegador al día, para que lleven el bloqueo de los certificados de eMudhra (claves privadas que se adivinaban probando 256 valores... sí, 256).
La seguridad por oscuridad... Estamos todos en bragas.