🚨 8 sustos de seguridad en 72 horas: qué pasó en cada uno, explicado para cualquiera

🚨 En unas 72 horas pasó de todo: un agujero en PHP, otro en Node.js, una falla 10 sobre 10 en GitLab, una librería de IA infectada, dos plataformas cloud con intrusos adentro y más de 400.000 certificados dados de baja. Maricarmen lo resumió en una lista que circuló muchísimo, y con razón.

Pero una lista de nombres no te dice qué pasó ni si te toca. Así que agarré los ocho, uno por uno, y te los explico para que los entienda cualquiera, aunque no trabajes en seguridad 🔍. Spoiler de lo que más me preocupa: ninguno de los ocho estaba en el código de las víctimas. Todos estaban en algo que usaban y en lo que confiaban.

Los ocho entran en tres grupos: agujeros en software que usa medio mundo, ataques a los lugares donde se guardan las claves, y problemas con los certificados que hacen aparecer el candadito en el navegador. Vamos de a uno 👇.

📅 El 21 de octubre fue un día de locos

Seis de los ocho se conocieron el mismo día. Si ese día estabas de guardia en un equipo de infraestructura, te debés acordar. Y si no, acá va qué fue cada cosa.

🕳️ Agujeros en software que usa medio mundo

Primero, una palabra que vas a ver todo el tiempo: vulnerabilidad es un error en un programa que alguien puede usar para hacer algo que no debería. Y el parche es la versión nueva que lo arregla. La más peligrosa de todas es la que en seguridad llaman “ejecución remota de código”: alguien desde afuera, por internet, logra que tu servidor corra lo que él quiera.

🐘 PHP. Es el lenguaje con el que están hechos WordPress, Drupal y Joomla, o sea buena parte de la web. Tenía dos fallas, bautizadas PHP2Shell, que dejaban hacer justamente eso sin usuario ni contraseña. El parche salió el 21 de octubre. Lo nuevo es que, según Amazon, ya había intentos de ataque desde el 17, cuatro días antes del arreglo, y hoy se está atacando a lo grande. La historia completa de cómo la encontró una IA la conté acá.

🟩 Node.js. Es lo que hace correr JavaScript en los servidores, y lo usan millones de servidores. El 21 de octubre sacó parches para 10 fallas. La más seria está en Brotli, un formato de compresión: los sitios achican los datos antes de mandarlos y el que los recibe los descomprime. El problema es que, al descomprimir datos armados a propósito, el programa escribía fuera del espacio de memoria que tenía reservado, y eso puede terminar en que el atacante corra su propio código. Como Brotli es de Google y lo usan muchos otros programas, no alcanza con actualizar Node: todo lo que traiga Brotli adentro tiene que actualizarse.

🦊 GitLab. Es donde muchísimas empresas guardan su código y automatizan sus pruebas y despliegues, y muchas lo instalan en sus propios servidores. La falla tiene puntaje 10 sobre 10, el máximo de la escala con la que se mide la gravedad (CVSS). Está en la parte que procesa expresiones regulares, que son los patrones que se usan para buscar texto: un número que se pasaba de su tamaño máximo terminaba dejando que alguien sin cuenta ejecutara código, bajo ciertas condiciones. Afecta a todas las versiones desde la 7.0, de 2014. Y es la segunda falla 10 sobre 10 de GitLab en octubre: la anterior se arregló el 12.

🔑 Fueron a buscar tus claves

Acá cambia el juego. En estos tres casos nadie buscó un error en un programa: fueron directo a donde están guardadas las claves. Las claves de API son las contraseñas que usan los programas para hablar con otros servicios, por ejemplo tu app con OpenAI o con tu base de datos. Quien las tiene, puede usar esos servicios como si fuera vos, y pagás vos.

🤖 LiteLLM. Es una librería de Python que muchos equipos ponen adelante de todos sus modelos de IA: tu app le habla a LiteLLM y LiteLLM le habla a OpenAI, Anthropic o Google. Por eso guarda todas las claves juntas. El 21 de octubre se publicó la versión 1.107.0 con un programa escondido que robaba credenciales de la máquina donde se instalaba. Según Wiz, los atacantes usaron tokens robados (los permisos de acceso que quedan guardados en la compu) de las cuentas de GitHub de dos personas del proyecto: con una dispararon la publicación y con la otra la aprobaron. Estuvo cerca de una hora y cuarenta en PyPI, la tienda de paquetes de Python, y es la segunda vez en el año que le pasa. La versión sana es la 1.106.2.

🚂 Railway. Es una plataforma donde subís tu código y ellos se encargan de correrlo. Ahí guardás tus variables de entorno, que es donde se ponen las contraseñas y las claves para que tu código las lea sin dejarlas escritas adentro. Railway avisó que alguien entró a los sistemas donde guarda esas variables y que, en algunos casos, pudo verlas desencriptadas. Frenó todos los deploys (las subidas de código nuevo) mientras investigaba y dice algo que me dejó pensando: cree que es parte de una serie de ataques contra plataformas para llegar a las claves de proveedores de IA.

🐬 TiDB Cloud. Es una base de datos en la nube de la empresa PingCAP. En su reporte del 19 de octubre cuenta que alguien usó credenciales robadas de una cuenta de servicio (una cuenta que usan los sistemas, no las personas) y estuvo adentro entre el 9 de septiembre y el 7 de octubre. Se llevó código fuente, datos de usuarios, de facturación y un listado de claves de API encriptadas. PingCAP dice que no hay evidencia de que tocaran los datos que los clientes guardan en sus bases. Un grupo se adjudicó el ataque y dice tener mucho más, pero eso PingCAP no lo confirmó.

Ninguno de los ocho sustos estaba en tu código. Todos estaban en algo que usás y en lo que confiás.

🔒 El candadito del navegador

Cuando entrás a un sitio con “https” y ves el candadito, es porque el sitio te mostró un certificado: un documento digital que dice “este sitio es de quien dice ser”. Esos certificados los firman empresas llamadas autoridades de certificación (CA), y tu navegador confía en una lista de ellas. Si la firma es de una CA de la lista, el candadito aparece.

🇮🇳 eMudhra. Es una CA de India. Un investigador demostró que se filtraron las llaves privadas de ocho de sus CA intermedias, que son las que firman los certificados en el día a día. Con esas llaves, alguien podría fabricar un certificado falso para cualquier sitio y el candadito aparecería igual. Chrome, Firefox y Apple las bloquearon en horas o días. Pero muchos programas que corren en servidores no revisan si una CA fue dada de baja: Go, por ejemplo, tuvo que sacar versiones nuevas, y cada programa hecho en Go hay que volver a compilarlo, o sea armarlo de nuevo. Por ahora no se conoce ningún uso malicioso.

🌐 GoDaddy. Acá no hubo ataque. GoDaddy revocó 404.607 certificados, o sea los dio de baja, porque los había emitido con datos que no coincidían con sus propias reglas publicadas. Las reglas que pactan los navegadores y las CA le daban cinco días para revocarlos y no llegó, así que tuvo que abrir otro reporte por la demora. El efecto es concreto: el sitio que no instaló el certificado nuevo le muestra un cartel de advertencia a sus visitantes.

🧭 Qué tienen en común (y por qué me preocupa)

Si mirás los ocho juntos, ninguno fue un error en el código de las víctimas. Estaban en el lenguaje, en una librería, en la plataforma donde despliegan, en la base de datos que alquilan o en la empresa que firma sus certificados. Hoy cualquier sistema está armado con decenas de piezas de terceros, y cada una es una puerta.

Y hay un patrón que se repite: LiteLLM, Railway y TiDB Cloud son ataques para robar claves, y Railway dice en voz alta que los atacantes van por las claves de IA. Tiene lógica: una clave de un proveedor de modelos se puede usar para gastar miles de dólares a tu nombre, o para llegar a todo lo que esa IA tiene conectado.

En Latinoamérica esto pega fuerte, porque hay mucho PHP viejo en hostings compartidos, muchos equipos chicos que dependen de plataformas como Railway y poca gente para responder a las tres de la mañana. Por eso, más que reaccionar a cada susto, conviene estar preparado para el próximo.

✅ ¿Me toca? Qué haría yo esta semana

Primero lo urgente: fijate en la tabla si usás alguna de estas cosas y hacé lo que dice hoy, no el lunes. Después, tres cosas que yo pondría en marcha para que la próxima semana así te agarre mejor parado:

• Saber qué usás: una lista de qué lenguajes, librerías y plataformas corren en cada servidor y en qué versión. Sin eso, cada susto arranca con una búsqueda a ciegas.
• Poder actualizar en horas: que un parche urgente llegue a producción el mismo día, con pruebas automáticas que te den confianza para hacerlo.
• Claves que vencen solas: credenciales de corta duración en lugar de claves que duran años, para que si alguien se las lleva le sirvan poco tiempo. Y tener claro cómo rotarlas todas de una.

Ninguna de las tres es nueva ni cara. Lo que cambió es el ritmo: ya no es un susto por mes, son ocho en tres días.

¿A tu equipo le tocó alguno de los ocho? ¿Cuál te hizo correr? Te leo en X 👇.