La cadena de suministro es el nuevo perímetro: Brotli, LiteLLM y el precio de confiar

Dos incidentes con horas de diferencia describen el mismo problema desde ángulos distintos. Uno vive en una librería de compresión que casi nadie mira. El otro, en una clave que alguien olvidó revocar. Ninguno se resuelve con un firewall: se resuelven con disciplina de ingeniería y con una decisión incómoda — tratar cada dependencia como si fuera código propio.

Durante veinte años llamamos "perímetro" al borde de la red: el firewall, el router, la VPN. Ese modelo murió hace tiempo, pero esta semana quedó retratado con claridad brutal. El martes, un fallo de corrupción de memoria en el decodificador Brotli de Google apareció al mismo tiempo en Node.js, Bun, Envoy, Istio y dos paquetes de Python. El jueves se confirmó que una versión maliciosa de LiteLLM llegó a PyPI porque una clave maestra filtrada en mayo nunca fue revocada.

Ninguno de los dos ataques necesitó adivinar una contraseña ni romper un cifrado. Ambos entraron por la puerta que dejamos abierta a propósito: la de las cosas en las que confiamos sin revisar.

Brotli: el error que viaja en el equipaje de todos

Brotli es el algoritmo de compresión que Google liberó en 2015 y que hoy usan prácticamente todos los navegadores y servidores. Comprime texto, JSON, HTML y fuentes mejor que gzip. Es invisible, gratuito y está en todas partes. Precisamente por eso su fallo es distinto a cualquier otro.

El problema, registrado como CVE-2026-111497, es una corrupción de memoria en el decodificador: datos comprimidos diseñados a propósito pueden escribir más allá del final de un búfer y alterar la memoria del proceso. En un lenguaje con recolección de basura como JavaScript eso sería un detalle académico, pero Brotli no está escrito en JavaScript — está escrito en C, y cada runtime compila su propia copia.

Ahí está la trampa. Node.js no "llama" a Brotli: lo empaca. Bun lo empaca. Envoy e Istio lo empacan. Los paquetes brotli y brotlicffi de Python lo empacan. Cuando aparece una vulnerabilidad en el original no hay un parche que aplicar, sino cinco copias en cinco ciclos de lanzamiento distintos, cada una esperando que su mantenedor se entere, lo reproduzca y publique a tiempo.

"Datos comprimidos especialmente diseñados pueden sobrescribir más allá del final de un búfer y corromper la memoria del programa, provocando un fallo, una fuga de memoria o la ejecución de código controlado por el atacante." — The Hacker News, 24 de octubre de 2026.

No es teoría. Imperva logró ejecución de código en una compilación oficial de Node.js 24.22.0 para Linux arm64 y bautizó el exploit Node2Shell. Que el objetivo fuera una build oficial —no una modificación casera— es lo que debería quitarnos el sueño: el binario que descargaste del sitio de Node.js, el mismo que corre en producción desde hace meses, era explotable.

Las versiones corregidas ya existen: Node.js 22.23.4, 24.22.1 y 26.12.1; Bun 1.4.4; Brotli 1.2.1. Hasta ahora no hay ataques reales reportados, lo cual es una ventana, no una garantía. La historia reciente dice que entre la publicación de un PoC y su explotación masiva suelen pasar entre cuatro y diez días. Cuando el exploit ya está escrito, la ventana se mide en horas.

El obstáculo no es el parche, es el inventario. Actualizar Node en desarrollo toma dos minutos; en producción toma ventana de mantenimiento, pruebas de regresión y rollback. Y muchas empresas no saben qué versión corre en cada contenedor: el Dockerfile dice node:24 —una etiqueta móvil que hoy apunta a 24.22.0 y mañana a 24.22.1— y nadie reconstruyó la imagen desde marzo. Ahí es donde una vulnerabilidad de severidad media se convierte en incidente.

LiteLLM: la clave que nadie revocó

Si Brotli es el ejemplo del código que no controlas, LiteLLM es el de la credencial que sí controlas y aun así olvidas. La cronología es casi didáctica por lo mal que está:

• Mayo de 2026: una clave maestra de la Agent Platform de LiteLLM queda publicada por accidente en un repositorio público.
• Ese mismo día: el equipo la detecta, reescribe el commit y borra el rastro del historial de Git.
• Mayo a octubre: la clave sigue activa. Nadie la revoca.
• Octubre de 2026: un atacante la usa para extraer un token OAuth de GitHub con permisos de dueño, alterar el pipeline y subir LiteLLM 1.107.0 a PyPI con código malicioso.

"El error se identificó rápidamente, el commit se sobrescribió y detectamos que las claves expuestas requerían revocación. Sin embargo, la revocación de la clave maestra no ocurrió." — Oliver Jensen y Mateo Wang, LiteLLM.

Lean otra vez esa frase. No hubo negligencia en la detección: hubo detección, análisis y decisión. Lo que faltó fue ejecutar la parte aburrida. Reescribir el historial de Git se siente como remediación porque es visible y satisfactorio; revocar una credencial es un trámite silencioso que nadie celebra. Pero solo una de las dos acciones cierra el agujero. La otra, en el mejor caso, oculta la evidencia.

El daño colateral importa: LiteLLM es la capa que muchas empresas ponen entre sus aplicaciones y los proveedores de modelos —OpenAI, Anthropic, Gemini, Bedrock— para unificar facturación y observabilidad. Comprometerla es comprometer el punto donde viven las claves de todos esos proveedores. PyPI puso la versión en cuarentena el mismo día y Docker Hub retiró las imágenes, pero quien hizo pip install litellm==1.107.0 en esa ventana ejecutó código ajeno con acceso a su facturación de IA.

La lección: rotar credenciales no es un trámite administrativo, es un control con fecha de vencimiento. Un secreto filtrado debe considerarse comprometido para siempre, aunque el commit ya no exista y el repositorio sea privado. La única prueba aceptable de que una credencial está muerta es intentar usarla y recibir un error de autenticación.

El patrón: cuatro fallos, una misma raíz

Si sumamos las noticias de la semana —Brotli, LiteLLM, el cambio de privacidad de Google y las dos vulnerabilidades que CISA sumó a su catálogo de explotación activa— no aparecen cuatro incidentes, sino cuatro manifestaciones de la misma falla de gobierno:

1. Dependencias que no inventariamos. Brotli vive en el árbol transitivo. Nadie lo eligió; llegó con otra cosa. Y como no lo elegimos, no lo vigilamos.
2. Credenciales que no revocamos. La clave de LiteLLM existía en un panel que nadie revisaba. Los secretos sin dueño claro son secretos sin caducidad.
3. Permisos que no acotamos. Un token con permisos de dueño permitió publicar un paquete. Con escritura limitada al pipeline, el ataque se detenía ahí.
4. Políticas que no leímos. El cambio de Google —que explicita el uso de datos de Gmail, Drive y Photos para personalizar anuncios al conectarlos a Gemini o a la IA de Search— entró en vigor el 16 de octubre y no apareció en ninguna alerta de las que la gente sí lee.

El hilo común es la confianza delegada. Confiamos en el binario de Node, en el paquete de PyPI, en el permiso del token, en la política de privacidad. Es una confianza razonable —nadie puede auditar cada línea del stack— pero deja de serlo cuando es implícita. La diferencia entre un incidente y una molestia es haber convertido esa confianza en un control verificable.

Por qué pega más fuerte en una PYME

Google puede dedicar una semana a Brotli. Una empresa de treinta personas en Veracruz, Monterrey o Puebla no. Y sin embargo corre más riesgo relativo, por dos razones. La superficie creció sin que nadie la diseñara: un WordPress con doce plugins, un backend en Node para el cotizador, un script en Python copiado de un tutorial, un bot de WhatsApp con su propio servidor. Cada pieza tiene su cadena de dependencias y ninguna comparte inventario con las demás.

La segunda es que la automatización llegó antes que el gobierno de identidades. El dato del ILIA 2026 es elocuente: solo el 6.8% de las PYMES latinoamericanas usa IA de forma estructurada, pero entre las que sí la usan, la mayoría opera con claves de API pegadas en archivos .env que nadie rota y con agentes que tienen más permisos de los necesarios porque "así funciona".

El cálculo ayuda: reiniciar un backend pequeño toma cuarenta minutos. Recuperar un servidor comprometido, con forense y reconstrucción, rara vez baja de cinco días. La asimetría es de 180 a 1. No hay debate técnico que justifique el lado equivocado de esa balanza.

Cuatro movimientos para esta semana

No hace falta un programa de seguridad de 200 páginas. Hacen falta cuatro acciones concretas, ejecutables en cinco días hábiles, con dueño y fecha.

Lo que realmente se está discutiendo

La conversación sobre ciberseguridad en 2026 sigue atrapada en la pregunta equivocada: qué firewall, qué antivirus, qué EDR. Los incidentes de esta semana no ocurrieron en la red. Ocurrieron en el eslabón donde una empresa decidió que no valía la pena mirar: la dependencia que llegó sola, la clave que nadie reclamó, el permiso que se otorgó "para que funcionara". Y ese tipo de fallo se cierra con proceso más que con presupuesto: un inventario, una rotación verificada y un permiso acotado cuestan horas de trabajo, no licencias.

La cadena de suministro digital ya es el perímetro. La pregunta no es si vas a confiar en alguien —siempre lo harás, es la base del software moderno—, sino si vas a saber en quién, en qué versión y con qué permisos. Eso, y no el firewall, es lo que separa a una empresa que se actualiza de una que aparece en la siguiente noticia.