Back to blog

LangGraph CVE-2026-118668: test the Store authorization result

3 min read
LangGraph CVE-2026-118668: test the Store authorization result

Sources checked: . FailSafe Research.

An authorization handler can look correct while the system applies a different result. The LangGraph maintainer advisory GHSA-4hm6-w6qq-w73v describes certain JavaScript or TypeScript custom-authentication deployments failing to apply Store namespace changes. That is a concrete reason to review agent memory through the running application.

Separate affected deployments from the broader product

The advisory lists langgraph-api versions from 0.1.2 before 0.15.0. Its required conditions include JavaScript or TypeScript custom authentication and a handler that relies on namespace rewriting to restrict user access. The maintainer distinguishes other authentication patterns and Python handlers from that affected case.

Use those conditions to identify the relevant deployments. The advisory is not evidence that every LangGraph application or a particular hosted service exposed user data. Record any uncertainty in the inventory rather than converting it into a breach claim. Assign an owner to resolve an unknown handler configuration before accepting the applicability decision.

Make ownership visible in the test data

Create two synthetic users with visibly different records and an approved ownership policy. Define which read, search, update and delete operations each may perform. That gives the reviewer a practical basis for deciding whether a result crossed a boundary.

Do not place credentials, personal conversations or real customer documents into a public reproduction. A harmless marker can establish ownership and demonstrate an authorization failure without creating another disclosure.

Observe the operation after authorization

Review the request, the handler's decision and the Store operation that actually occurs. If the implementation crosses a language or runtime boundary, capture enough sanitized evidence to show that the authorized namespace survives the transition.

Test denied access through the application paths in scope, including any supported alternatives that reach the same Store operation. Agreement on one front-end route does not establish equivalent authorization across every SDK or administrative interface.

Retain a useful closure record

The maintainer identifies version 0.15.0 as the fix and describes a rejection-based workaround for deployments that cannot immediately upgrade. Follow the current advisory and have the application owner review any temporary change.

After deployment, repeat the allowed and denied cases. Tie the results to the updated service version and remaining exclusions. FailSafe's AI application assessments can scope this kind of end-to-end boundary review. For the broader persistent-state threat model, see agent memory poisoning, which addresses a different question from this specific authorization defect.

Source review, 2 November 2026: LangGraph maintainer advisory GHSA-4hm6-w6qq-w73v. Original publication and later advisory updates should be distinguished when tracking disclosure dates.

Questions & answers

Questions about this topic

Direct answers to common questions about this page.

No. It describes particular JavaScript or TypeScript handlers that rely on namespace rewriting, along with other required conditions.

Keep running-version evidence and results showing legitimate access works while unauthorized cross-user Store operations are denied.

Put this guidance to work

Use a scoped AI assessment to evaluate the running authorization path with synthetic user records and evidence your engineering owner can review.

Startup offer: $999 USD for 250 credits and one authorized black-box run. Sign in to SWARM before Stripe checkout. Custom scope and sovereign deployments are separate.

Scope an AI application assessment