Autor: Yarden Porat
Pesquisa da Cyata: Vulnerabilidade LangGrinch no LangChain
Publicado em: https://cyata.ai/blog/langgrinch-langchain-core-cve-2025-68664/
Ontem o LangChain publicou um alerta crítico sobre uma vulnerabilidade que descobri no langchain-core: CVE-2025-68664 / GHSA-c67j-w6g6-q2cm.
No início deste ano, minha pesquisa foi focada em invadir gerenciadores de segredos no nosso trabalho "Vault Fault" – sistemas projetados especificamente como uma fronteira de segurança em torno das suas credenciais mais sensíveis. Uma conclusão se repetiu várias vezes: quando a plataforma trata acidentalmente dados moldados por um atacante como estrutura confiável, essa fronteira desmorona rapidamente. Desta vez, o sistema que "quebra" não é o seu gerenciador de segredos. É a estrutura de agentes que pode usá-los.
Por que essa vulnerabilidade merece atenção especial:
Está no núcleo. Não é um erro de uma ferramenta específica, nem um caso extremo de integração, nem "algum pacote da comunidade fez algo estranho." As APIs vulneráveis (dumps() / dumpd()) estão no próprio langchain-core.
O raio de impacto é enorme. Pelo volume de downloads, langchain é um dos componentes de estruturas de IA mais amplamente implantados no mundo hoje. No final de dezembro de 2025, a telemetria pública de pacotes mostra centenas de milhões de instalações, com o pepy.tech relatando ~847 milhões de downloads totais e o pypistats mostrando ~98 milhões de downloads no último mês.
Um único prompt pode disparar muitos mecanismos. O caminho real mais comum aqui não é "o atacante envia um blob serializado e você chama load()." É mais sutil: as saídas do LLM podem influenciar campos como additional_kwargs ou response_metadata, e esses campos podem ser serializados e depois desserializados por meio de funções comuns da estrutura, como streaming de logs/eventos. Em palavras simples, isso significa que o exploit pode ser acionado por um único prompt de texto, que cascateia em um pipeline interno surpreendentemente complexo.
Antes de continuar lendo: os patches já foram lançados nas versões 1.2.5 e 0.3.81. Se você usa LangChain em produção, isso é mais complicado do que parece; atualize o quanto antes.
O LangChain usa um formato de serialização interno especial, onde dicionários contendo o marcador 'lc' representam objetos LangChain. A vulnerabilidade era que dumps() e dumpd() não escapavam corretamente dicionários controlados pelo usuário que acidentalmente incluíam a chave reservada 'lc'.
Assim, assim que um atacante consegue fazer o loop de orquestração do LangChain serializar e posteriormente desserializar conteúdo incluindo a chave 'lc', ele consegue instanciar um objeto arbitrário inseguro, potencialmente acionando vários caminhos favoráveis ao atacante.
O alerta lista 12 fluxos vulneráveis diferentes, extremamente comuns em casos de uso reais, como streaming padrão de eventos, logging, histórico de mensagens/memória ou cache:
As consequências mais devastadoras incluem:
Extração de segredos de variáveis de ambiente. O alerta observa que isso ocorre na desserialização com secrets_from_env=True. Notavelmente, isso era o padrão até ontem. 🙂
Instanciação de objetos em namespaces pré-aprovados (incluindo langchain_core, langchain_openai, langchain_aws, langchain_anthropic…), potencialmente causando efeitos colaterais nos construtores (chamadas de rede, operações com arquivos etc.).
Sob certas condições, a instanciação de objetos LangChain pode levar à execução arbitrária de código.
Isso é classificado sob CWE-502: Desserialização de dados não confiáveis, com pontuação CVSS CNA de 9.3 (Crítica).
Na véspera de Natal, eu estava fazendo o trabalho mais antifestivo possível: olhando para o código de serialização e me perguntando "espera… por que isso é considerado confiável?"
Pesquisas de segurança muitas vezes parecem dramáticas por fora. Na realidade, isso geralmente é leitura cuidadosa, pequenas hipóteses e o acúmulo lento de momentos de "isso é estranho".
Isso começou como muitas coisas na Cyata: com uma pergunta simples que fazemos constantemente ao avaliar stacks de IA quanto a risco real:
Onde estão as fronteiras de confiança em aplicações de IA, e os desenvolvedores realmente sabem onde essas fronteiras estão?
LangChain é uma estrutura poderosa e, como a maioria das estruturas modernas, ela precisa movimentar dados estruturados complexos: mensagens, chamadas de ferramentas, eventos de streaming, traces, caches e "runnables".
Revisando pesquisas anteriores, já havia um estudo extenso sobre ferramentas e integrações do LangChain, mas muito poucas descobertas na biblioteca principal.
Comecei a pesquisa trabalhando de trás para frente. Encontrar lugares interessantes (sinks) e depois descobrir como um atacante poderia alcançá-los. A desserialização era um alvo óbvio.
Levei bastante tempo para encontrar algo significativo. Mas depois de um tempo, descobri que, assumindo um primitivo de desserialização controlado pelo atacante, eu poderia disparar um SSRF cego que poderia ser usado para exfiltrar variáveis de ambiente (detalhes em breve). Como o resultado era limitado à exfiltração de segredos, e não ao meu objetivo principal de RCE, continuei auditando a desserialização e fui com calma.
O bug não era um pedaço de código ruim; era a ausência de código. dumps() simplesmente não escapava dicionários controlados pelo usuário contendo chaves 'lc'. Escape ausente no caminho de serialização, não na desserialização.
É muito mais fácil notar algo errado do que notar a ausência de algo, especialmente quando você audita load(), e não dumps(). Em uma das estruturas de IA mais rigorosamente revisadas. Por dois anos e meio.
A partir daí, a pesquisa se tornou um exercício estruturado:
Identificar onde conteúdo não confiável (principalmente dicionários arbitrários) entra na serialização (saídas de LLM, injeção de prompt, entrada do usuário, ferramentas externas, documentos extraídos).
Identificar quando esses dados serializados são desserializados.
Identificar o que um atacante pode alcançar com a instanciação arbitrária de objetos.
Naquele momento, a descoberta principal era suficientemente clara e acionável para um relatório responsável: havia uma lacuna de escape em dumps() / dumpd() em torno de dicionários com a chave 'lc'.
O alerta capturou posteriormente o que vemos frequentemente na prática: campos como additional_kwargs e response_metadata podem ser influenciados pela saída do LLM e por injeção de prompt, e esses campos podem ser serializados e desserializados em muitos fluxos.
Em crédito à equipe do LangChain: a resposta e as ações subsequentes foram decisivas, não apenas corrigindo o bug, mas também endurecendo padrões que eram permissivos demais para o mundo em que vivemos agora.
O projeto LangChain decidiu conceder uma recompensa de $4.000 USD por essa descoberta. De acordo com o huntr, a plataforma onde o LangChain conduzia seu programa de recompensas, esse seria o maior valor já concedido no projeto, com recompensas até então de até $125.
O LangChain serializa certos objetos usando um formato de dicionário estruturado. A chave 'lc' é usada internamente para indicar "isto é uma estrutura LangChain serializada", não apenas dados arbitrários do usuário.
Esse é um padrão comum, mas cria um invariante de segurança: qualquer dado do usuário que possa conter 'lc' deve ser tratado com cuidado. Caso contrário, um atacante pode criar um dicionário que "parece" um objeto interno e enganar o desserializador para dar a ele esse valor.
O patch torna a intenção explícita na documentação atualizada: durante a serialização, dicionários simples contendo a chave 'lc' são escapados por meio de um wrapper.
Isso impede que esses dicionários sejam confundidos com objetos LangChain realmente serializados durante a desserialização.
As funções load()/loads() do LangChain não instanciam classes arbitrárias – elas verificam contra uma lista de permissões que controla quais classes podem ser desserializadas. Por padrão, essa lista de permissões inclui classes de langchain_core, langchain_openai, langchain_aws e outros pacotes do ecossistema.
Eis o detalhe: a maioria das classes na lista de permissões tem construtores inofensivos. Encontrar caminhos exploráveis exigiu cavar no ecossistema em busca de classes que fazem algo significativo ao serem instanciadas. As que encontrei estão detalhadas abaixo, mas pode haver outras esperando para serem descobertas.
A função loads() do LangChain suporta um tipo secret, que resolve valores de variáveis de ambiente durante a desserialização. Antes do patch, essa função secrets_from_env estava habilitada por padrão:
if (
value.get("lc") == 1
and value.get("type") == "secret"
and value.get("id") is not None
):
[key] = value["id"]
if key in self.secrets_map:
return self.secrets_map[key]
if self.secrets_from_env and key in os.environ and os.environ[key]:
return os.environ[key] # <-- Retornando a variável de ambiente
return None
Se o objeto desserializado for retornado ao atacante, por exemplo um histórico de mensagens dentro do contexto do LLM, isso poderia vazar variáveis de ambiente.
Mas o caminho mais interessante é a injeção indireta de prompt. Mesmo um atacante que não pode ver nenhuma resposta do LLM pode exfiltrar segredos instanciando a classe certa. ChatBedrockConverse, de langchain_aws, está tanto na lista de permissões padrão de loads quanto faz uma requisição GET ao ser construído. O endpoint GET é controlado pelo atacante, e um cabeçalho HTTP específico pode ser preenchido com uma variável de ambiente por meio da função secrets_from_env.
Esse validador é executado quando ChatBedrockConverse é instanciado. O atacante controla o endpoint_url, disparando uma requisição de saída. Em combinação com secrets_from_env, o cabeçalho aws_access_key_id pode ser preenchido com qualquer variável de ambiente – não apenas chaves AWS.
Deliberadamente não publicamos um exploit pronto aqui para dar tempo às equipes de segurança. Em alguns meses, o site Huntr os publicará automaticamente.
Entre as classes na lista de permissões padrão de loads() está PromptTemplate. Essa classe cria um prompt a partir de um template, e um dos formatos de template disponíveis é Jinja2.
Quando o template é renderizado com Jinja2, código Python arbitrário pode ser executado. Não encontramos uma maneira de acionar isso diretamente apenas pela função loads(), mas se uma chamada subsequente ao objeto desserializado disparar a renderização, segue-se a execução de código.
Suspeitamos que possa haver caminhos para execução direta de código a partir de loads(), mas ainda não confirmamos nenhum. Se você tiver uma ideia sólida ou uma pista que mereça teste, ficaremos felizes em ouvir – é exatamente nesse ponto que a comunidade de segurança ajuda a transformar hipóteses em evidências. 🤝
Também vale notar: em versões passadas, a classe Chain também estava na lista de permissões. Essa classe tinha capacidades especiais que poderiam permitir um fluxo para renderização de templates.
Sua aplicação está potencialmente vulnerável se usar versões vulneráveis do langchain-core. Aqui estão alguns dos padrões vulneráveis mais comuns (no total, foram identificados 12 fluxos):
Ainda assim, o comportamento do sistema é complexo o suficiente para que seja arriscado supor que uma revisão rápida de código revelará todas as variantes alcançáveis. O mais seguro é atualizar para a versão corrigida e não presumir que você está seguro até fazer isso.
O alerta também observa o que considero o ponto mais importante do mundo real:
O vetor de ataque mais comum ocorre por meio de campos de resposta do LLM como additional_kwargs ou response_metadata, que podem ser controlados por injeção de prompt e depois serializados/desserializados em operações de streaming.
Esse é exatamente o tipo de interseção "IA encontra segurança clássica" em que as organizações são pegas de surpresa. A saída do LLM é uma entrada não confiável. Se a sua estrutura trata porções dessa saída como objetos estruturados posteriormente, você deve presumir que atacantes tentarão moldá-las.
Atualize o langchain-core para a versão corrigida. Se você usa langchain, langchain-community ou outros pacotes do ecossistema, verifique qual versão do langchain-core está realmente instalada nos ambientes de produção.
Trate additional_kwargs, response_metadata, saídas de ferramentas, documentos extraídos e histórico de mensagens como não confiáveis até que se prove o contrário. Isso é especialmente importante se você faz streaming de logs/eventos e depois os reidrata com um carregador.
Mesmo após a atualização, siga o princípio: não habilite a resolução de segredos a partir de variáveis de ambiente a menos que você confie na entrada serializada. O projeto mudou os padrões por um motivo.
Com base no meu relatório, há um alerta intimamente relacionado no LangChainJS (GHSA-r399-636x-v7f6 / CVE-2025-68665) com mecanismos semelhantes: confusão do marcador 'lc' durante a serialização, permitindo extração de segredos e instanciação insegura em determinadas configurações.
Se a sua organização executa tanto stacks Python quanto JavaScript do LangChain, trate isto como um lembrete de que o padrão se espalha entre ecossistemas: serialização com marcadores, saída de modelo não confiável e desserialização subsequente são uma forma recorrente de risco.
Estamos entrando em uma fase em que estruturas de agentes de IA se tornam infraestrutura crítica dentro de sistemas de produção. Formatos de serialização, pipelines de orquestração, execução de ferramentas, caches e rastreamento não são mais "encanamento" – eles fazem parte da sua fronteira de segurança.
Essa vulnerabilidade não é "apenas um bug em uma biblioteca." É um estudo de caso de um grande padrão:
Sua aplicação pode desserializar dados que ela considera produzidos com segurança.
Mas essa saída serializada pode conter campos influenciados por fontes não confiáveis (incluindo saídas de LLM moldadas por injeção de prompt).
Uma única chave reservada usada como marcador interno pode se tornar um ponto de virada para segredos e comportamentos próximos à execução.
Na Cyata, nosso trabalho é ajudar organizações a construir visibilidade, avaliação de risco, controle e governança em torno de sistemas de IA – porque se você não consegue responder rapidamente onde os agentes estão rodando, quais versões estão implantadas e quais dados fluem por eles, você está efetivamente voando às cegas quando alertas como este chegam.
Se você é um líder de segurança lendo isto, aqui está a verdade desconfortável:
A maioria das organizações hoje não consegue responder, de forma rápida e confiante:
Onde usamos agentes?
Quais versões estão implantadas em produção?
Quais serviços têm acesso a segredos sensíveis?
Onde as saídas do LLM cruzam essas fronteiras?
Isso não é "problema do desenvolvedor." É um problema de visibilidade e governança.
E é exatamente aqui que entra a Cyata.
Na Cyata, focamos em resultados práticos: reduzir o risco de IA e agentes sem desacelerar os construtores. Vulnerabilidades como esta raramente são "apenas um patch." Elas revelam lacunas em como as equipes detectam onde os agentes estão sendo executados, entendem as fronteiras reais de confiança e garantem padrões mais seguros em estruturas em movimento acelerado.
Saiba o que está rodando, onde e como está conectado.
Responda rapidamente à primeira pergunta do CVE: estamos vulneráveis e em quais fluxos?
Descubra runtimes de agentes e integrações entre ambientes (IDEs, CI, serviços, jobs, agentes hospedados).
Rastreie frameworks, pacotes e versões em uso.
Priorize o que importa com base no raio de impacto real, não apenas "a biblioteca está presente."
Mantenha uma triagem mais rápida: o que está exposto à internet, o que envolve segredos, o que roda com privilégios elevados.
Identifique os caminhos de maior risco: conteúdo não confiável fluindo para contextos privilegiados (serviços com segredos, permissões amplas de ferramentas, acesso à rede de produção).
Destaque onde "campos estruturados" podem cruzar fronteiras de confiança (metadados, saídas de ferramentas, eventos de streaming, artefatos em cache).
Reduza a exposição mesmo antes de cada dependência ser corrigida em todos os lugares.
Incentive padrões operacionais mais seguros: privilégios mínimos, fronteiras de isolamento e verificações de políticas que escalam entre equipes.
Forneça gateways em torno de padrões arriscados (por exemplo: desserialização de dados não confiáveis, ressuscitação permissiva de objetos, fluxos inseguros de streaming-para-cache-para-reidratação).
Bloqueie ou restrinja capacidades sensíveis em contextos não confiáveis (por exemplo: acesso a segredos do ambiente, execução de ferramentas com altos privilégios ou execução de caminhos de código arriscados em workers privilegiados).
Torne o "uso seguro de agentes" repetível, auditável e difícil de sofrer drift.
Defina políticas para frameworks, versões e configurações aprovados.
Acompanhe e limite por tempo as exceções, com proprietários e justificativas.
Monitore drift e uso arriscado de recursos ao longo do tempo, com trilha de auditoria que suporte revisões de segurança e compliance.
Quando o alerta de Natal chega, o objetivo não é heroísmo – é uma resposta calma e controlada, respaldada por inventário real e gateways garantidos.
Relatório enviado via Huntr – 4 de dezembro de 2025
Reconhecido pelos mantenedores do LangChain – 5 de dezembro de 2025
Alerta e CVE publicados – 24 de dezembro de 2025