Continuei lendo.

O Código Vulnerável

Três funções internas estavam no centro disso:

• _load_template() — lê arquivos referenciados por template_path, suffix_path e prefix_path
• _load_examples() — lê arquivos referenciados pela chave examples quando ela é uma string
• _load_few_shot_prompt() — lê arquivos referenciados por example_prompt_path

As verificações de extensão de arquivo existiam. .txt para templates. .json, .yaml, .yml para exemplos. Mas não havia nada impedindo que esses caminhos fossem absolutos (/etc/passwd) ou baseados em traversal (../../../../home/user/.ssh/). O filtro de extensão dava uma falsa sensação de segurança — apenas significava que um atacante precisava escolher a extensão certa, não que o ataque estava bloqueado.

Essas funções são todas alcançáveis por meio de duas APIs públicas: load_prompt() e load_prompt_from_config().

Prova de Conceito

A versão mais simples era assim:

É isso. Passe um caminho absoluto, receba o conteúdo do arquivo de volta embrulhado em um PromptTemplate. Sem autenticação. Sem privilégios especiais. Se você puder influenciar o dicionário de configuração, poderá ler arquivos.

O directory traversal funcionava igualmente limpo:

A variante JSON/YAML era argumentavelmente mais perigosa por causa dos tipos de arquivos que podia alcançar:

.docker/config.json contém suas credenciais do Docker Hub. ~/.azure/accessTokens.json tem seus tokens do Azure. Manifestos Kubernetes, configurações de CI/CD, configurações internas de aplicações — qualquer coisa com a extensão certa em qualquer lugar do sistema de arquivos estava em jogo.

A Superfície de Ataque no Mundo Real

A pontuação CVSS veio em 7.5 Alta, com um vetor de AV:N/AC:L/PR:N/UI:N — acessível pela rede, baixa complexidade, sem privilégios, sem necessidade de interação do usuário.

A pontuação é limitada abaixo de 9+ porque a verificação de extensão de arquivo realmente limita quais arquivos podem ser lidos. Mas 7.5 ainda subestima o impacto no mundo real em certos padrões de implantação.

Pense em onde isso aterrissa em produção:

• Construtores de IA low-code que permitem aos usuários configurar prompts por meio de uma interface — se o backend passa configurações controladas pelo usuário diretamente para load_prompt_from_config(), todo usuário é um potencial atacante.
• Wrappers de API que expõem endpoints de carregamento de prompts, assumindo que a biblioteca lida com a sanitização.
• Aplicações implantadas na nuvem onde segredos de ambiente são montados como arquivos (um padrão muito comum em Kubernetes, AWS ECS e GCP).

Nesses ambientes, a limitação de "restringido por extensão de arquivo" importa muito menos. Um atacante pode simplesmente mirar arquivos que sabe que existem com a extensão certa. Em uma instância de nuvem típica: requirements.txt, config.yaml, .env.yaml, arquivos de segredos montados com extensões .json — a lista é longa.

Por Que Isso Existia em Primeiro Lugar

As funções afetadas são descritas no advisory como "APIs legadas não documentadas". Elas são anteriores ao sistema de serialização atual do langchain_core.load (dumpd/dumps/load/loads), que usa um modelo baseado em allowlist e não realiza leituras do sistema de arquivos.

As novas APIs existem. São melhores. Mas o código antigo nunca foi limpo — apenas ficou lá, alcançável, sem validação, esperando.

Este é um padrão que vale a pena observar. Em projetos open-source de movimento rápido, especialmente aqueles que cresceram tão rapidamente quanto o LangChain, a dívida técnica se acumula nos cantos. Código legado que "nunca foi realmente destinado a usuários" não recebe o mesmo escrutínio que a superfície principal da API. Mas ainda é chamável. Ainda está no pacote. E se lê arquivos do disco, é uma vulnerabilidade potencial.

A Correção

O patch chegou no langchain-core 1.2.22. A correção adiciona validação de caminho que rejeita tanto caminhos absolutos quanto sequências de traversal .. antes que qualquer arquivo seja aberto. Uma porta de escape — allow_dangerous_paths=True — está disponível para aplicações que genuinamente precisam ler de caminhos confiáveis, com o reconhecimento explícito de que o chamador está optando pelo risco.

As APIs legadas também foram formalmente descontinuadas com este lançamento. Serão removidas completamente na versão 2.0.0. Se você está usando load_prompt() ou load_prompt_from_config() em qualquer lugar, migre para os equivalentes do langchain_core.load agora, em vez de esperar pela mudança disruptiva.

Atualize imediatamente:

Verifique se você está na 1.2.22 ou mais recente:

O Que Verificar no Seu Próprio Código

Se você está construindo com LangChain, uma auditoria rápida vale a pena:

1. Pesquise por load_prompt e load_prompt_from_config no seu código. Se aparecerem, verifique o que está sendo passado para eles.
2. Pergunte se algum dicionário de configuração que flui para essas funções contém valores influenciados pelo usuário. Se a resposta for sim, você estava potencialmente vulnerável antes de atualizar.
3. Revise o layout de arquivos da sua implantação. Entenda quais arquivos com extensões .txt, .json ou .yaml existem nas suas instâncias e o que eles contêm.

Consideração Final

Bugs de segurança em infraestrutura de IA vão importar mais, não menos, à medida que esses sistemas lidam com cargas de trabalho mais sensíveis. A equipe do LangChain respondeu bem — a correção é limpa, o caminho de descontinuação é claro e a documentação do advisory é completa.

Mas é um bom lembrete de que a superfície de ataque de uma aplicação de IA não é apenas o modelo. É cada biblioteca na stack, cada função legada que nunca foi limpa, cada lugar onde "o usuário provavelmente não vai passar entrada não confiável aqui" acabou sendo uma suposição em vez de uma garantia.

Leia o código. Especialmente as partes antigas.

CVE-2026-34070 foi atribuído a esta vulnerabilidade. O advisory completo está disponível no LangChain GitHub Security Advisory.