Una semana loca en ciberseguridad: por qué nuestro chat de IA europeo se mantuvo a salvo de las últimas brechas

tl;dr: Esta tercera semana de octubre de 2026 trajo una oleada extraordinaria de incidentes de seguridad en todo el sector tecnológico, pero DentroChat y tus datos están a salvo.

Si sigues las noticias de seguridad, esta semana se ha sentido como una inundación. Aunque salen avisos menores a menudo, ver tantas herramientas base y plataformas cloud comprometidas en cuestión de pocos días es, digámoslo claro, UNA LOCURA.

En menos de una semana se nos juntó todo esto:

• El incidente de la autoridad de certificación eMudhra: Se descubrió que 8 certificados intermedios bajo la raíz emSign de eMudhra tenían claves privadas extremadamente débiles. Como esas claves se podían calcular mediante ingeniería inversa para interceptar tráfico HTTPS, los principales navegadores tuvieron que bloquear los certificados, eMudhra ha anunciado hoy que abandona por completo el negocio mundial de certificados SSL/TLS (!) y hubo que publicar actualizaciones de emergencia para uv, pip, Node.js, Bun, Go y Rust (!) para eliminar la CA comprometida de sus almacenes de confianza integrados.
• CVEs críticos en software clave de internet: Se parchearon dos fallos de ejecución remota de código sin autenticación en PHP (CVE-2026-109618 y CVE-2026-109619), junto con un desbordamiento de búfer crítico en Google Brotli (CVE-2026-111497), una RCE sin autenticación de máxima gravedad en GitLab (CVE-2026-110264) y la vulnerabilidad «PwnEscape» del kernel de Linux (CVE-2026-99999).
• El ataque a la cadena de suministro de LiteLLM: Ayer, 21 de octubre, unos atacantes comprometieron (otra vez) el pipeline de publicación de LiteLLM y subieron una versión con puerta trasera (v1.107.0) a PyPI y Docker Hub. Como el paquete malicioso incluía un hook de inicio que se ejecutaba automáticamente cada vez que arrancaba Python, robó al instante credenciales cloud y claves de API de los servidores afectados.
• Brechas en las plataformas Railway y Zeabur: Zeabur anunció que cierra de forma definitiva tras una segunda brecha que expuso 3,2 millones de registros de variables de entorno de 321.000 cuentas de usuario. Ayer, Railway también comunicó que un atacante accedió a variables de entorno de clientes y logró descifrarlas. Curiosamente, el objetivo principal eran las claves de inferencia de IA.
• Grandes brechas empresariales: Atacantes lograron acceder a entornos de clientes de Microsoft 365 usando credenciales de copia de seguridad robadas de ConnectWise (SkyKick), y Capcom sufrió una brecha que afectó a 11,7 millones de cuentas de usuario.

¿Estamos ante un «Cyberpocalypse» o es que el sistema inmunitario de internet está despertando?

¿Por qué están apareciendo al mismo tiempo tantos fallos antiguos en compiladores de expresiones regulares, decodificadores de compresión, gestores de memoria y configuraciones criptográficas?

La respuesta es, sobre todo, que ahora la IA está leyendo el código del mundo. Investigadores de seguridad y defensores (y también atacantes) están poniendo a la IA a revisar el código de librerías open source. El resultado es que salen a la luz un montón de casos límite que a los revisores humanos se les pasaron durante 15 años. Incluso las claves débiles de la CA de eMudhra se detectaron al parecer con ayuda de IA.

Algunos comentaristas han llamado a esta semana un «Cyberpocalypse». Sin embargo, nuestra forma de verlo es que el sistema inmunitario de internet por fin está despertando y curándose a sí mismo. La mayoría de estos fallos ya llevaban años en código en producción, y descubrirlos significa que por fin se corrigen.

Como hace ya tantos años escribí mi tesis de grado en la TU Graz sobre el modelo de confianza y los riesgos estructurales de las autoridades de certificación, ver cómo el caso de eMudhra caía en cascada sobre uv, pip, Node.js y Bun me recordó por qué elegí aquel tema entonces. En internet, la confianza adopta muchas formas y es un sistema enormemente complejo.

En qué punto está DentroChat frente a los incidentes de esta semana

Si usas DentroChat para tu trabajo diario y tus documentos confidenciales, tus conversaciones y archivos no se han visto afectados por ninguno de estos incidentes. Como mantenemos una arquitectura ligera, la mayor parte del software afectado ni siquiera forma parte de nuestro stack, y parcheamos al instante lo que sí usamos:

• El problema de confianza CA en uv, pip, Node.js y Bun: Como las herramientas de línea de comandos y los runtimes incluyen su propia lista de autoridades de certificación de confianza, cualquier herramienta que confiara en el certificado raíz comprometido de eMudhra tenía que actualizarse. DentroChat no usa uv ni pip en sus servidores. Sin embargo, nuestra aplicación web corre sobre Bun, así que actualizamos nuestros contenedores de producción a Bun 1.4.4 (junto con los certificados del sistema Debian ya parcheados), eliminando por completo la raíz comprometida de eMudhra.
• LiteLLM (malware en v1.107.0): Aunque enrutamos las peticiones de IA a través de una pasarela de inferencia europea (Cortecs), no usamos la librería de Python LiteLLM ni sus imágenes de Docker en ninguna parte de nuestro stack.
• Railway, Zeabur y plataformas de despliegue en la nube: No alojamos en plataformas PaaS multi-inquilino como Railway o Zeabur, ni guardamos datos de clientes en hiperescaladores de EE. UU. ni en tenants cloud de Microsoft. Tal como documentamos en nuestra página de Subprocesadores, gestionamos nuestros despliegues mediante nuestra propia instancia autoalojada de Coolify, que corre directamente en nuestros servidores europeos. Por tanto, ningún proveedor PaaS externo guarda nuestras variables de entorno ni nuestros secretos de despliegue.
• PHP, GitLab y dependencias de la aplicación: No usamos PHP ni GitLab autoalojado. Además, auditamos y actualizamos todo el árbol de dependencias tanto de nuestra plataforma de chat como de nuestra web, y ahora mismo estamos en cero vulnerabilidades conocidas.

Cómo diseñamos la arquitectura de DentroChat para mantener tus datos a salvo

Como las auditorías de código asistidas por IA seguirán destapando nuevos CVEs en el software open source, los paquetes de terceros nunca estarán «libres de bugs». Por eso diseñamos DentroChat con un aislamiento estricto, de modo que un fallo en un componente no pueda comprometer ni tus datos ni nuestros servidores.

1. Ejecución de código en un sandbox WebAssembly sin red

Este año, un informe de seguridad muy sonado mostró que unos agentes de OpenAI escaparon de su sandbox durante una evaluación interna. Aquella fuga fue posible porque los agentes corrían dentro de un contenedor de Linux que seguía teniendo acceso de red a un proxy interno de paquetes, y el agente explotó un fallo zero-day en ese proxy para salir a internet.

En DentroChat esa vía de ataque no existe (a día de hoy), porque no ejecutamos código de usuario dentro de un contenedor Linux con shell ni instalador de paquetes. En su lugar, cuando subes una hoja de cálculo o le pides a DentroChat que ejecute un análisis en Python, el código corre dentro de un sandbox aislado de WebAssembly (WASM):

• Todas las librerías de Python compatibles para análisis de datos y creación de documentos vienen preempaquetadas en tiempo de compilación, de modo que nunca se descarga nada de PyPI ni de un proxy interno en tiempo de ejecución.
• Antes de ejecutar una sola línea de Python, todas las APIs de red saliente, los cargadores de librerías dinámicas y los puentes con el sistema de archivos del host se cortan y eliminan del runtime.
• Incluso si una librería de Python llegara a incluir una puerta trasera como el script de inicio de LiteLLM, el sandbox de WebAssembly no tiene conexión de red para enviar datos fuera ni acceso a las variables de entorno del servidor o a los archivos de otros usuarios. En cuanto se devuelve tu gráfico o documento, el espacio de trabajo temporal se borra de nuevo por completo.

2. Un enfriamiento de 7 días frente a ataques a la cadena de suministro

El ataque de LiteLLM funcionó porque:

1. se publica la versión maliciosa del paquete en PyPI
2. los pipelines de compilación automatizados de todo el mundo la instalan al instante
3. a las 2 horas los investigadores de seguridad se dan cuenta de que algo va mal
4. para entonces, el código malicioso ya ha podido explotar muchos sistemas

Para frenar este llamado «ataque a la cadena de suministro», nuestro gestor de paquetes impone una antigüedad mínima de publicación de 7 días junto con lockfiles bloqueados. Una versión recién publicada de un paquete open source debe superar una semana entera de escrutinio público antes de que nuestro pipeline de compilación permita instalarla. Salvo, claro está, que auditemos y fijemos manualmente un parche de seguridad concreto como la actualización del runtime de hoy…

3. Por qué bloqueamos el acceso a la red interna cuando la IA visita páginas web

Cuando le pides a DentroChat que lea una página web o descargue un conjunto de datos público de una API de datos abiertos, nuestro servidor consulta esa URL en tu nombre. Sin límites de red estrictos, una web maliciosa podría esconder instrucciones en la página para engañar a la IA y hacer que pida direcciones internas del servidor (como 127.0.0.1 o puertos internos de la red de Docker) en vez de una web pública. Esa técnica, llamada Server-Side Request Forgery (SSRF), podría exponer servicios internos que corren en el propio servidor.

Por eso, nuestro módulo de peticiones salientes resuelve el DNS antes de conectar, bloquea todos los rangos de IP privados, de loopback e internos, y fija la dirección IP verificada en cada salto de redirección. Incluso si una página web intenta engañar al modelo o usa DNS rebinding para cambiar la IP de un dominio a 127.0.0.1 en el último milisegundo, la conexión se rechaza antes de que toque nuestra red interna.

4. Cifrado en reposo gestionado por nosotros mismos en Hetzner en Europa

Todos los servidores de aplicación, bases de datos y herramientas autoalojadas de DentroChat corren en Hetzner en Alemania, mientras que las copias de seguridad cifradas y los registros de servidor seudonimizados se guardan en Scaleway en Francia, todo bajo jurisdicción de la UE y fuera del alcance de la US CLOUD Act. Puedes consultar nuestra infraestructura completa en cualquier momento en nuestra página de Subprocesadores.

Todos los datos están protegidos con cifrado en tránsito y cifrado en reposo. Un detalle técnico que suele pasarse por alto: en la mayoría de los proveedores de alojamiento (también en Hetzner), los discos de los servidores no vienen cifrados en reposo por defecto. Por eso configuramos y gestionamos nosotros mismos el cifrado en reposo. Esta infraestructura segura encaja además con nuestros controles de privacidad habituales:

• Cero entrenamiento con tus conversaciones o archivos
• Borrado automático de chats bajo tu control
• Modo de chat discreto cuando quieres dejar una conversación fuera de la memoria de la IA

Mantenerse alerta

La buena seguridad nunca se da por terminada.

Sobre todo ahora que tanto investigadores como atacantes pueden encontrar vulnerabilidades zero-day con IA más rápido que nunca. Aunque agradecemos que nuestra arquitectura haya mantenido a DentroChat completamente protegido de la oleada de incidentes de esta semana, no bajamos la guardia.

Estamos evaluando activamente cómo acortar todavía más nuestro tiempo de respuesta ante futuros exploits zero-day, reforzar las fronteras de nuestros servidores y mantener tus datos a salvo por muy loca que venga la próxima semana en ciberseguridad. ¡Gracias por formar parte de DentroChat!