Os registros Postgres e SQLite persistem em espaços de nomes hierárquicos como uma string unida a pontos (`("memórias", "alice")` se torna `memories.alice`) e lê-se com o escopo correspondente a essa string com o `LIKE ' %''. Porque `LIKE` não tem noção do separador `.`, um `search` ou `list_namespaces` com escopo também corresponde a espaços de nomes de irmãos cuja forma aplanada compartilha caracteres principais. Aplicações usam comumente o espaço de nomes como um limite do inquilino. Onde eles fazem, uma leitura com escopo para um espaço de nomes pode devolver itens pertencentes a outro, sem qualquer entrada criada — um pedido com escopo comum foi suficiente. Não temos evidências de que este comportamento seja explorado no meio selvagem.
Usuários / sistemas afetados. Você pode ser afetado se você: - use `PostgresStore`/`AsyncPostgresStore` ou `SqliteStore`/`AsyncSqliteStore`, e - confie no espaço de nomes para separar dados entre usuários ou inquilinos, e - tenha etiquetas de espaço de nomes onde um é um prefixo de outro (` 1 ` e ` 12 `, ` alice` e ` alice 2 `), ou etiquetas contendo `_` ou `%` Os aplicativos cujas etiquetas de espaço de nomes são identificadores de comprimento fixo, como os UUIDs, que não contêm `_` ou `%`, não são afetados — nenhum deles pode ser um prefixo de outro. `InMemoryStore` compara os espaços de nomes em sentido de elemento e não é afetado.
Três casos distintos foram possíveis. - **Espaços de nomes de ativação.** Uma leitura com o objetivo de `("foo",)` também devolveu itens em `("foobar",)` e `("foo 2 ",)`. - **Metacaracters de padrão inesperados.** `_` e `%` são etiquetas de espaço de nomes legais — somente `.` é rejeitado — mas foram interpolados no padrão de correspondência inesperado, então `("user_ 1 ",)` também correspondeu `("userX 1 ",)`. - **Condições do Sufix.** `list_namespaces(suffix=("alice",)' também correspondeu à folha do irmão `users.malice'. Isto não é injeção SQL. Os valores foram passados como parâmetros vinculados e nunca interpolados no texto da instrução; o valor vinculado * foi em si mesmo* um padrão `LIKE` cujos metacaracters não foram neutralizados. - Confidencialidade: divulgação de itens armazenados pertencentes a espaços de nomes fora do escopo pretendido pelo chamador, onde os espaços de nomes são usados como limites de locatário ou usuário. - Nenhum impacto de integridade ou disponibilidade. `get`, `put' e `delete' comparam espaços de nomes com `=' e nunca foram afetados; o problema é limitado a caminhos de leitura.
Patches / Mitigação. O escopamento do prefixo agora corresponde exatamente ao espaço de nomes ou requer o separador `.` antes de qualquer resto, metacaracterísticas de padrão em etiquetas serem escapadas, e `list_namespaces` usa compatíveis com segmentos para condições de prefixo e sufixo. No SQLite, a partida descendente moveu- se de `LIKE` para `GLOB`. `LIKE` é insensível ao caso para o ASCII no SQLite, por isso o escopo lê espaços de nomes previamente correspondentes que diferem apenas no caso, enquanto o `get`/ `put`/ `delete` os tratou como distintos. A pesquisa agora concorda com eles. Atualizar para `langgraph-checkpoint-postgres` 3.1.1 ou `langgraph- checkpoint- sqlite` 3.1.1.
`*` em um caminho de correspondência `list_namespaces` agora abrange exatamente um segmento de espaço de nomes. Isto restaura o comportamento documentado — `NamespacePath` documentos `("cache", "*", "v 1 ")` como "qualquer categoria de cache com v 1 versão" — e corresponde a `InMemoryStore`. A combinação de segmentos múltiplos foi um artefato de traduzir `*` para um comodinho SQL `%`, o mesmo mecanismo responsável por este problema, e não pôde ser preservado enquanto o corrigia. Os que ligam com base no comportamento anterior podem expressar "ajuste em qualquer profundidade" combinando ambas as condições de correspondência, que são ANDed:.
``` list_namespaces list_python(prefix=["uid"], sufix=["alice"]) ```. Aplicações cujas etiquetas de espaço de nomes não podem ser prefixos uns dos outros não vêem nenhuma mudança de comportamento. ## Orientação operacional. - Prefere etiquetas de espaço de nomes de comprimento fixo, como UUIDs, para que nenhuma etiqueta possa ser um prefixo de outra. - Onde as etiquetas são fornecidas pelo usuário, valide- as no limite em vez de depender de escopar sozinho.
Nota de implantação LangSmith / hospedado. Ao contrário dos avisos anteriores da loja, este problema atinge as implementações hospedadas. O LangSmith implementa padrão para `LangGRAPH_STORE_BACKEND=python`, que usa `AsyncPostgresStore` a partir de `checkpoint-postgres`. As implantações configuradas com `LangGRAPH_STORE_BACKEND=grpc` usam uma implementação separada que recebeu uma correção equivalente. Registro de aconselhamento: GHSA- 47 pj- 3 jcm- 6 - O que é isso? Identificadores relacionados: CVE- 2026 - 71433.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 06 T 19: 03: 12.000 Z e lista a sua última modificação como 2026 - 08 - 06 T 19: 03: 12.000 Z. Gravidade: MODERAR. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N.
Software afetado e informações de versão: pacote PyPI langgraph-checkpoint-postgres — ECOSYSTEM: introduzido 0, corrigido 3.1.1. Pacote PyPI langgraph- checkpoint- sqlite — ECOSISTEM: introduzido 0, corrigido 3.1.1. Classificação e evidência: identificadores de fraqueza CWE- 200, CWE- 863. O registro contém 6 suporte de referências nestes tipos: WEB, PACKAGE.