Chainlit en alerta: dos fallos críticos permiten leer archivos y provocar SSRF para comprometer entornos en la nube

Chainlit, una herramienta de código abierto muy utilizada para montar interfaces conversacionales y orquestar componentes de IA, ha sido el foco de una alerta de seguridad que debería encender las alarmas en organizaciones que la tienen expuesta a Internet. Investigadores de Zafran Labs han identificado dos fallos de alta gravedad que, combinados, permiten desde leer cualquier fichero accesible por el servidor hasta forzar peticiones salientes para sondear redes internas, lo que abre la puerta a fugas de secretos y movimientos laterales en entornos en la nube. Puede leer el informe técnico de los descubridores en la publicación de Zafran Labs: ChainLeak — Zafran Labs.

Antes de entrar en detalles técnicos, conviene poner en contexto la magnitud del problema: Chainlit es un proyecto con un uso notable en Python, acumulando alrededor de 700,000 descargas mensuales en PyPI, y suele encontrarse en despliegues de empresas y entornos académicos que exponen interfaces de chat a usuarios o integran asistentes en flujos productivos. Su naturaleza como "frontend + backend" para chatbots y su integración con autenticación, sesiones y despliegue en la nube lo convierten en un vector atractivo cuando está mal configurado o vulnerable.

Los dos fallos señalados han recibido identificadores oficiales en la base de vulnerabilidades del NIST: el primero, una lectura arbitraria de ficheros, figura como CVE-2026-22218, y el segundo, una vulnerabilidad de tipo SSRF que permite forzar al servidor a realizar peticiones a URLs controladas por el atacante, aparece como CVE-2026-22219.

En términos prácticos, CVE-2026-22218 se explota a través de un punto de extensión para elementos personalizados que Chainlit expone en la ruta /project/element: un atacante puede enviar un elemento con un campo ‘path’ manipulado y provocar que el servidor copie el archivo de esa ruta hacia la sesión del atacante, sin que el contenido pase por comprobaciones suficientes. El efecto es que un actor malicioso puede leer archivos a los que el proceso de Chainlit tenga acceso, lo que incluye claves de API, credenciales de cuentas en la nube, código fuente, ficheros de configuración, bases de datos SQLite locales y secretos de autenticación.

Por su parte, CVE-2026-22219 afecta a instalaciones que usan la capa de datos basada en SQLAlchemy. Allí el mecanismo permite que un elemento personalizado incluya un campo ‘url’ y obligue al servidor a realizar una petición GET hacia esa dirección y almacenar la respuesta. Esta capacidad de hacer peticiones salientes se traduce en una clásica SSRF: desde enumerar y consultar servicios internos y metadatos de la nube hasta traer respuestas que luego pueden descargarse por el atacante desde endpoints de elementos.

Lo más preocupante mostrado por Zafran Labs es que ambas fallas pueden encadenarse: la SSRF permite, por ejemplo, acceder a metadatos de la infraestructura o a endpoints internos que devuelvan credenciales, mientras que la lectura arbitraria puede extraer ficheros críticos una vez que el atacante ha escalado información. En su demostración, los investigadores describen un flujo que culmina en compromiso completo y movimientos laterales en entornos en la nube, un escenario crítico para cualquier organización que dependa de identidades y secretos para la orquestación de recursos.

Los descubridores informaron a los mantenedores de Chainlit el 23 de noviembre de 2025 y obtuvieron respuesta el 9 de diciembre de 2025; las correcciones se publicaron el 24 de diciembre de 2025 en la versión 2.9.4. Desde entonces, la rama ha seguido recibiendo mantenimientos y la versión estable más reciente es la 2.9.6. La recomendación inmediata y prioritaria para equipos afectados es actualizar a 2.9.4 o, preferiblemente, a la versión más reciente disponible.

Si por restricciones de compatibilidad no es posible aplicar el parche de inmediato, existen medidas compensatorias que reducen el riesgo: ejecutar instancias de Chainlit con permisos de fichero estrictos y cuentas de servicio de mínima confianza, bloquear el tráfico saliente desde los contenedores o máquinas que alojan Chainlit mediante reglas de red o proxys de salida, proteger endpoints con autenticación fuerte y WAF, deshabilitar o restringir la funcionalidad que permite subir o registrar elementos personalizados, y auditar accesos y logs en busca de patrones anómalos. También es crucial rotar claves y secretos que podrían haber quedado expuestos y revisar los sistemas internos que puedan ser consultados mediante SSRF.

Más allá de mitigaciones inmediatas, este incidente subraya lecciones de seguridad que resultan aplicables a cualquier plataforma que exponga interfaces para ejecutar o procesar contenido enviado por usuarios. Validación estricta de entradas, principios de mínimo privilegio y controles de egress (salida de red) deben ser parte de la arquitectura cuando se despliega software que admite extensiones o elementos definidos por terceros. Adicionalmente, incorporar pruebas de seguridad dinámicas y revisiones de código para puntos que tratan rutas de ficheros o fetching de URL ayuda a identificar clases de fallos similares antes de que lleguen a producción.

Para los equipos de respuesta a incidentes, conviene generar indicadores de compromiso relacionados con las rutas y endpoints mencionados, revisar logs de acceso a /project/element y otros endpoints de elementos, comprobar si se han descargado ficheros sensibles y auditar tráfico saliente inusual desde las instancias afectadas. Si se detecta actividad sospechosa, lo prudente es aislar la instancia, capturar memoria y sistema de ficheros para análisis y proceder a la rotación de credenciales con posible impacto en servicios dependientes.

La comunidad de seguridad y los responsables de plataformas en la nube deberían tomar nota de cómo componentes de infraestructura "amigables" para desarrolladores, como frameworks para chat de IA, pueden convertirse en vectores críticos si no se aíslan adecuadamente. En ese sentido, es útil revisar guías y buenas prácticas sobre mitigación de SSRF y protección de secretos: recursos como las páginas de CVE y reportes técnicos aportan contexto verificable, por ejemplo en la entrada de la NVD sobre estas vulnerabilidades y en la nota técnica de Zafran Labs ya mencionada.

Finalmente, para quien emplee Chainlit en producción, el camino es claro: actualizar cuanto antes a la versión parcheada, comprobar si hubo exposición potencial, rotar secretos y endurecer controles de red y permisos. La velocidad en aplicar estos pasos reduce significativamente la ventana de exposición frente a atacantes que podrían explotar fallos ya conocidos y documentados. Mantener un inventario actualizado de software expuesto y sus dependencias, y suscribir un proceso de notificación temprana a mantenedores y equipos internos, ayudará a afrontar futuras vulnerabilidades con menos impacto.