FlawOpen

flawopen.com/AI Security/langgraph-js-custom-auth-cross-user-store-access

● CWE-639 / CWE-863 · CVSS v4 8.6[1] · Alta
Pesquisa · FlawOpen

LangGraph JS Auth: acesso cruzado ao Store

langgraph-api <0.15.0 podia perder namespaces do Store reescritos por custom-auth JS/TS, permitindo acesso entre usuários. Atualize para 0.15.0.[1], [2]

Vetor CVSSCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N[1]
💡 Explicação em Linguagem Simples (ELI5)

Imagine um bibliotecário que confere seu cartão e pede a outro balcão que busque um livro. O segundo balcão anota sua própria estante, mas a mudança se perde na transferência e ele busca a estante informada originalmente pelo visitante. O caminho de autenticação JavaScript/TypeScript afetado podia perder a reescrita do namespace entre o runtime de autorização e a operação Store. A correção transporta o namespace autorizado e o valida antes de consultar o Store.[1]

Conceitos Centrais e Termos

GHSA-4hm6-w6qq-w73v
Aviso LangGraph de alta severidade publicado em 28 de setembro de 2026. Não há CVE atribuído. O pacote afetado é langgraph-api; a correção está na versão 0.15.0.[1]
Namespace do Store
Nome hierárquico usado para agrupar registros do Store LangGraph. Aplicações costumam incluir nele a identidade do usuário ou tenant para separar dados.[1]
Handler de autorização personalizado
Código da aplicação que decide se uma solicitação autenticada pode acessar um recurso e pode reescrever o namespace antes da operação Store.[1]
CWE-639 / CWE-863
Bypass de autorização por chave controlada pelo usuário e autorização incorreta. A falha está em não aplicar a restrição de namespace definida pelo handler.[1], [3], [4]

Mapeamentos de frameworks

Fluxo de Ataque Passo a Paso

Passo 1

Confirme se a implantação está no escopo

Verifique se langgraph-api está em >=0.1.2 e <0.15.0 e se o servidor usa handler personalizado JavaScript ou TypeScript.[1]

Passo 2

Localize a reescrita do namespace

O handler altera o namespace solicitado para incluir ou impor a identidade do usuário autenticado, em vez de rejeitar uma solicitação fora desse namespace.[1]

Passo 3

O resultado da autorização cruza um limite de runtime

Nas versões afetadas, a alteração de namespace pode não chegar à operação Store. O namespace original fornecido pelo solicitante pode continuar em uso.[1]

Passo 4

Um usuário autenticado mira outro namespace

Uma conta comum pode solicitar operações Store em registros fora do próprio namespace. O aviso cita leitura, sobrescrita, pesquisa e exclusão como possíveis impactos.[1]

Passo 5

Atualize ou negue namespaces não autorizados

Atualize para langgraph-api>=0.15.0. Se isso não for imediato, rejeite namespaces não autorizados em todas as ações Store e confirme que o Store recebe somente o namespace autorizado.[1], [2]

Análise de Causa Raiz

O GHSA dos mantenedores do LangGraph, publicado em 28 de setembro de 2026, descreve uma falha em langgraph-api versões >=0.1.2 e <0.15.0 quando todas estas condições ocorrem: a implantação usa autenticação personalizada em JavaScript ou TypeScript; o handler de autorização do Store reescreve o namespace solicitado para limitar os dados ao usuário atual; um usuário autenticado comum pode enviar operações Store; e dados de vários usuários passam por esse caminho de autorização. O aviso afirma que handlers personalizados Python não são afetados e que handlers JavaScript/TypeScript que rejeitam namespaces não autorizados, em vez de reescrevê-los, também não são afetados. A alteração do namespace feita pelo handler podia se perder entre runtimes, fazendo a operação Store usar o namespace original da solicitação. Um usuário autenticado poderia ler, sobrescrever, pesquisar ou excluir registros fora do próprio namespace autorizado. Isso não contorna o login e não é um ataque remoto sem autenticação. O aviso classifica a falha como Alta, CVSS 4.0 8,6, e atribui CWE-639 e CWE-863. A versão 0.15.0 transporta as alterações do handler, valida o namespace resultante e rejeita mudanças malformadas ou não aplicadas. Se a atualização atrasar, a alternativa recomendada é rejeitar namespaces não autorizados em todas as ações do Store. O código é uma ilustração TypeScript reduzida do fluxo de dados, não o código-fonte do SDK.[1]

Código-Fonte: Vulnerável vs. Seguro

Este exemplo TypeScript reduzido ilustra um contrato de fronteira; os nomes das funções e o formato do resultado são ilustrativos, não o código-fonte do SDK LangGraph. O aviso confirma que alterações de autorização JS/TS podiam se perder antes da operação Store, mas não publica esta implementação interna exata. Portanto, o lado vulnerável representa somente o invariante documentado: o Store usa o namespace da solicitação em vez do namespace autorizado. O lado corrigido consome e valida o resultado autorizado. A alternativa documentada pelo mantenedor é rejeitar namespaces não autorizados, em vez de reescrevê-los, em todas as ações Store.[1]

Trecho de origem: Fronteira de autorização da API LangGraph ao Store — contrato ilustrativo reduzido

IMPLEMENTAÇÃO VULNERÁVEL
type StoreRequest = { namespace: string[]; key: string };
type AuthorizationResult = { allowed: boolean; namespace: string[] };

async function readStore(userId: string, request: StoreRequest) {
  const authorization = await authorizeStore(userId, request); // Illustrative bridge contract.
  return store.get(request.namespace, request.key); // The bridge drops the authorized result.
}
PATCH SEGURO E ROBUSTO
type StoreRequest = { namespace: string[]; key: string };
type AuthorizationResult = { allowed: boolean; namespace: string[] };

async function readStore(userId: string, request: StoreRequest) {
  const authorization = await authorizeStore(userId, request); // Illustrative bridge contract.
  if (!authorization.allowed) throw new Error("forbidden");
  const namespace = validateAuthorizedNamespace(userId, authorization.namespace);
  return store.get(namespace, request.key); // Apply the authorized result.
}

Lista de Verificação de Segurança para Engenharia

Fontes

← AI Security Directory →