emSign, PHP2Shell y la IA: la semana en que internet se llenó de bugs críticos

Si esta semana sentiste que internet era un juego de mundo abierto con la policía persiguiendo a todo el mundo, no estabas paranoico. En pocos días se rompió la confianza en los certificados que usan pip y uv para hablar con PyPI, se publicaron fallas críticas en el motor de PHP y le tocó también a Pillow, una de las librerías más usadas de Python, y además apareció una pregunta incómoda: la misma IA que ayuda a encontrar estos bugs también le está dando una mano a los atacantes. Repasemos qué pasó, con fuentes y sin humo.

PHP2Shell: el bug que hizo temblar al 70% de la web

El miércoles 21 de octubre, el proyecto PHP publicó parches de emergencia para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, con puntaje 9,2 sobre 10 en CVSS v4.0, según el anuncio del equipo de seguridad de PHP. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los investigadores que las encontraron las bautizaron PHP2Shell, porque, encadenadas, permiten ejecutar código en un servidor sin autenticarse.

Lo grave es dónde están: en el núcleo de PHP, no en una app ni en un plugin. Según Wiz Research, hasta un "Hola mundo" corriendo en una versión afectada puede ser vulnerable; todas las versiones publicadas en la última década, desde la 5.4, tienen al menos una de las fallas, y además se puede leer memoria del proceso (contraseñas, tokens, claves de API) sin llegar a ejecutar código. Wiz calcula que PHP mueve cerca del 70% de los sitios del mundo, en línea con el 69,3% que mide W3Techs.

¿Afecta a otros lenguajes? Ojo con esto: las fuentes describen fallas de memoria en el motor de PHP (escrito en C), que impactan a todo lo que corre arriba de PHP, sea cual sea el código de la aplicación. No encontramos fuentes que digan que el mismo bug afecte directamente a Python, Ruby o JavaScript. Lo que sí es transversal es el patrón: bugs de memoria escondidos durante años en software base del que depende medio planeta.

La reacción fue a nivel gobierno. La NSA pidió actualizar ya o sacar los sistemas de línea, y el NCSC británico recomendó inventariar todas las instalaciones de PHP, empezando por las expuestas a internet, según contó Ars Technica con el Financial Times.

Python y el caso emSign: ocho llaves que eran cualquier cosa

El 20 de octubre, Seth Larson, de la Python Software Foundation, publicó en discuss.python.org un aviso urgente por un incidente de seguridad con los certificados intermedios de eMudhra, la autoridad certificante detrás de las raíces emSign. ¿Cuál fue el "incidente"? Lo explicó en el mismo hilo Christian Heimes, desarrollador del núcleo de Python: las ocho CA intermedias de eMudhra tenían claves privadas de curva elíptica con un valor menor a 256. Una de ellas era literalmente d=4. Spoiler: eso no es seguro. Las intermedias fueron revocadas y la raíz emSign se sacó de los almacenes de certificados.

El riesgo concreto: con esas claves se pueden emitir certificados válidos para cualquier dominio, y eso habilita ataques de intermediario (MITM) contra clientes TLS, incluidos python.org y pypi.org. O sea, alguien bien ubicado en la red podría hacerse pasar por PyPI justo cuando hacés pip install.

El detalle que lo hace más picante es que certifi, pip y uv traen su propia copia de los certificados raíz. Heimes lo remarcó: pip siempre carga los certificados de su certifi integrado, además de los del sistema, y no hay forma soportada de desactivarlo. Traducción: actualizar los certificados del sistema operativo no alcanza, cualquier pip anterior a 26.2.2 sigue confiando en las CA comprometidas.

Las versiones corregidas, según la PSF, son certifi 2026.10.19, pip 26.2.2 (que, según sus notas de versión, actualiza el certifi integrado), uv 0.13.4, sigstore 4.5.1, conda 26.9.4 y pixi 0.82.1. Además, según el changelog de uv, la versión 0.13.5 actualiza los Python que maneja uv a 3.15.1, 3.14.9 y 3.13.17, que ya traen el pip corregido. Mala noticia para nostálgicos: Python 3.9 y 3.10 todavía incluyen un pip afectado, y uv recomienda migrar.

El aviso GHSA-hq85-5cpj-mr62 lo clasifica como crítico, con CVSS 9,1, y no tiene CVE asignado. La receta: actualizá pip y uv en cada entorno virtual (sí, en todos esos venvs que olvidaste que existían) y reconstruí tus imágenes de Docker sin caché.

En X la cosa se viralizó con el dramatismo de siempre, al grito de "Python est compromis". Tranqui: Python no fue hackeado, ni el lenguaje ni PyPI. Lo que se rompió fue la confianza en una autoridad certificante, y se arregla actualizando. Menos épico, pero más cierto.

Pillow: una imagen trucha y chau servidor

En el mismo frente pythonero, Pillow, la librería de imágenes más popular del ecosistema (unas 436 millones de descargas mensuales), corrigió tres fallas críticas con CVSS 9,2, divulgadas el 19 de octubre y analizadas por OX Security: CVE-2026-112900 (inyección de argumentos en el plugin EPS, que termina en ejecución de comandos vía Ghostscript), CVE-2026-112393 (desbordamiento de heap al guardar TIFF) y CVE-2026-112403 (desbordamiento de heap al decodificar JPEG). Todo se arregla en Pillow 13.0.0: si tu backend recibe imágenes de usuarios, pip install -U pillow, con un pip ya actualizado, claro.

La semana de los bugs no terminó ahí

Unos días antes se conoció CVE-2026-39892, un desbordamiento de buffer con CVSS 9,8 en el paquete cryptography (versiones 45.0.0 a 46.0.6, corregido en 46.0.7), que suele venir instalado como dependencia de otras librerías sin que lo sepas.

La IA como detective…

Acá viene lo interesante. PHP2Shell no lo encontró un humano solo frente a un debugger: según la cronología de Wiz, el primer bug apareció el 19 de agosto usando su plataforma junto con modelos de Google y OpenAI, en un trabajo con OpenAI y Calif. Wiz dice que las fallas existían hace décadas, pero que demostrar que eran explotables requería una cadena de pasos "al límite de lo que investigadores humanos podían lograr", y que los modelos de frontera bajaron muchísimo esa barrera. OpenAI, citada por el FT, sostuvo que, hasta donde sabe, la IA encontró estos bugs antes que los atacantes.

No es el primer antecedente. En 2025, Google contó que Big Sleep, su agente de IA de DeepMind y Project Zero, encontró una falla en SQLite (CVE-2025-6965) que unos atacantes se estaban preparando para usar, y la cortó antes. Google lo presentó como la primera vez que un agente de IA frenaba directamente un intento de explotación real.

…y como cómplice

El problema es que la misma velocidad corre para los dos lados. Amazon detectó un intento de explotar PHP2Shell el 17 de octubre en sus honeypots, cuatro días antes de la divulgación, y no sabe cómo consiguió el atacante la información. Tras la publicación de los parches, dice Amazon, el bug pasó a estar "ampliamente explotado". Su conclusión es clara: el análisis asistido por IA abarata convertir un parche o un aviso en un exploit funcional, así que más actores pueden atacar a horas, o minutos, de conocerse los detalles.

Los números asustan: según SecurityWeek, Cloudflare vio miles de intentos en las 10 horas previas al anuncio, decenas de miles en los 45 minutos posteriores y millones después. Censys contó cerca de 1,57 millones de hosts sin parchear el 21 de octubre. Pero también hay matiz: watchTowr dijo que los exploits que circulan "no funcionan, solo miden tiempos o tiran abajo el servidor", y varias organizaciones reportaron que los intentos que vieron fracasaron. Hasta ahora no hay confirmado un gran hackeo masivo con PHP2Shell; hay muchísimo ruido y mucha gente probando suerte.

Lo que sí ya pasó es un ataque real hecho por una IA. El 21 de septiembre, un "actor de amenazas agéntico" entró en el Instituto Holandés para la Divulgación de Vulnerabilidades (DIVD), justamente una ONG que avisa sobre sistemas expuestos. Según Sysdig y el propio DIVD, un agente autónomo encadenó dos zero-days del helpdesk Zammad (CVE-2026-102489 y CVE-2026-102490), pasó de una sesión robada a root en segundos y se llevó, como mínimo, los mails institucionales de los voluntarios. Fue "ruidoso y muy, muy desprolijo", hasta se saboteó solo, y dejaba comentarios en el código explicando lo que hacía. Torpe, sí. Pero funcionó.

Entonces, ¿estamos en el modo difícil?

Un poco. Que la IA destape bugs de hace diez años es buena noticia: mejor que los encuentre un equipo que avisa a los mantenedores que un grupo que los vende. Pero la ventana entre "sale el parche" y "hay exploits dando vueltas" se achicó a horas, y eso cambia las reglas. Como resume Amazon, los plazos de actualización para sistemas críticos expuestos se miden en horas, no en semanas.

La moraleja nerd es la de siempre, pero con turbo: actualizá PHP, pip, uv, certifi, Pillow y cryptography; revisá dependencias que ni sabías que tenías; y si administrás algo expuesto a internet, asumí que alguien (o algo) ya lo está escaneando. El speedrun de la seguridad ya empezó y no tiene botón de pausa.