Vulnerabilidades críticas em Chainlit expõem segredos e abrem portas a ataques na nuvem

A comunidade de cibersegurança acendeu um alarme importante após o achado de falhas críticas em Chainlit, um marco de código aberto para criar chatbots conversacionais que se popularizou com milhões de downloads. Pesquisadores de Zafran Security identificaram duas vulnerabilidades que, combinadas, permitem desde a leitura de arquivos sensíveis até a realização de petições internas a serviços da rede, abrindo a porta à exfiltração de chaves de nuvem e movimentos laterais dentro de uma organização. Você pode ler o relatório dos descubridores no blog de Zafran Security aqui, e consultar a documentação oficial do Chainlit aqui.

Chainlit, que, de acordo com estatísticas públicas, acumula milhões de instalações e dezenas de milhares de downloads semanais, é usado para colocar interfaces conversacionais que frequentemente gerem dados sensíveis e segredos de serviços na nuvem. Devido à sua adoção em massa, qualquer defeito em sua lógica pode ter um alcance amplo: desde o roubo de credenciais de API até o acesso ao código fonte ou a bases de dados internos. Os números de downloads e uso são públicos em sites como PyPI Stats aqui, o que ajuda a dimensionar o risco.

Os dois erros documentados recebem as identificações CVE-2026-22218 e CVE-2026-22219 no catálogo público de vulnerabilidades do NVD. O primeiro é uma vulnerabilidade de leitura arbitrária de ficheiros No fluxo de atualização do elemento de projeto (ruta "/project/element"), que permitiria a um atacante autenticado recuperar o conteúdo de qualquer arquivo acessível pelo serviço. O segundo é uma vulnerabilidade de Server-Side Request Forgery (SSRF) que aparece quando o Chainlit está configurado com a camada de dados SQLAlchemy; nesse cenário, um atacante poderia induzir o servidor a fazer pedidos de HTTP para serviços internos ou para endpoints de metadata da nuvem. Os detalhes técnicos de cada CVE estão disponíveis na base de dados NVD: CVE-2026-22218 e CVE-2026-22219.

O que torna especialmente perigoso a combinação de ambas as falhas é que a leitura arbitrária de arquivos pode revelar segredos que facilitam ataques posteriores: por exemplo, acessar o conteúdo de "/proc/self/environ" expõe variáveis de ambiente com chaves e rotas internas que um atacante pode usar para escalar privilégios ou mover-se lateralmente. Se a aplicação usa o SQLAlchemy com o SQLite, também existe risco de exfiltrar arquivos de base de dados completos. Por sua vez, o SSRF pode ser aproveitado para consultar os serviços de metadata de fornecedores na nuvem (como os que devolvem credenciais temporárias), permitindo que um atacante obtenha acessos válidos a recursos do fornecedor e consolidar a intrusão.

Diante do aviso responsável relatado no final de novembro de 2025, os mantenedores do Chainlit publicaram uma correção na versão 2.9.4, lançada em 24 de dezembro de 2025. É imprescindível que as equipes que executam instâncias de Chainlit atualizem a essa versão ou a uma posterior: a atualização corrige as validações no fluxo vulnerável e reduz a superfície de ataque. O adesivo oficial está no repositório de Chainlit no GitHub aqui.

Estes incidentes não são casos isolados: à medida que as empresas incorporam quadros de IA e componentes de terceiros, estão a ser reintroduzidos tipos de vulnerabilidades clássicas em infra-estruturas novas e específicas para a IA. Zafran e outros pesquisadores alertam que frameworks como Chainlit podem arrastar falhas bem conhecidas – como SSRF ou leitura arbitrária de arquivos – ao coração de implantaçãos que manejam dados críticos, com consequências que vão além de uma aplicação concreta.

Em paralelo, outra pesquisa divulgada recentemente pela assinatura BlueRock detectou uma falha no servidor MarkItDown MCP da Microsoft (apodada MCP fURI) que permite invocar URIs arbitrárias da ferramenta de conversão, o que também abre vias para SSRF, escalada de privilégios e fuga de informação quando o servidor corre em instâncias da AWS com IMDSv1 habilitado. A análise da BlueRock indica que uma proporção significativa de servidores MCP analisados poderiam ser suscetíveis a ataques semelhantes; o relatório completo está disponível no blog da BlueRock aqui. Para entender melhor o risco do SSRF e suas implicações, a comunidade de segurança recorre a recursos como OWASP SSRF e a documentação da AWS sobre como proteger o serviço de metadata com IMDSv2 aqui.

Diante desses achados, as medidas práticas que devem considerar os responsáveis pela segurança vão desde a ação imediata até mudanças estruturais na gestão de dependências. Em urgente, atualizar qualquer instalação do Chainlit à versão que corrige os erros é a prioridade. Em seguida, convém rever configurações de rede e permissões: limitar o acesso do serviço a recursos da rede interna e a metadatas de nuvem, executar processos com os mínimos privilégios necessários, e armazenar credenciais usando mecanismos gerenciados ou rotatividade automática para reduzir o impacto se forem filtrados.

A médio prazo, os equipamentos devem incorporar auditorias de segurança específicas para componentes de IA, incluir testes de SSRF e leitura de arquivos em suas pipelines de pentesting, e aplicar princípios de hardening que reduzam a exposição de metadados e serviços internos. Em ambientes cloud, a adoção de IMDSv2, o bloqueio de endereços IP privados desde processos não confiáveis e o uso de listas brancas podem mitigar muitos vetores de exfiltração. O AWS oferece guias para aplicar IMDSv2 e endurecer o acesso à metadata, que são um bom ponto de partida aqui.

A lição é clara: a integração rápida de ferramentas e frameworks de IA traz benefícios indubitavelmente, mas também arrasta riscos clássicos para camadas novas da pilha tecnológica. Auditar dependências, exigir adesivos e projetar ambientes com limites de segurança bem definidos são passos imprescindíveis para evitar que uma vulnerabilidade aparentemente localizada termine comprometendo contas cloud inteiras ou dados sensíveis da organização.

Se você administra aplicativos baseados em Chainlit, atualizar quanto antes da versão corrigida e revisar logs e segredos que poderiam ter sido comprometidos antes do adesivo. Para mais contexto técnico e mitigações específicas, consulte o aviso de Zafran aqui, os registros da NVD sobre os CVE CVE-2026-22218 e CVE-2026-22219, e a correção publicada por Chainlit no GitHub aqui.