LangGraph SDK Auth Bug: `actions=` Ignored on `@auth.on` Handlers (CVE-2026-104873)

A flaw in the Python langgraph-sdk means that custom authorization handlers scoped with actions= were silently applied to every action on a resource. Deployments that relied on a narrow handler plus a stricter fallback could let one authenticated user read, update or delete another user's threads, assistants or crons. The bug is tracked as CVE-2026-104873 (GHSA-fvww-7h3r-vfhp), affects langgraph-sdk from 0.1.45 up to but not including 0.4.4, and is fixed in 0.4.4. The GitHub advisory rates it High, with a CVSS v4.0 score of 7.6. It is not in CISA's Known Exploited Vulnerabilities catalog.

What happened

LangGraph's custom auth lets an app register handlers with decorators such as @auth.on.threads, @auth.on.assistants and @auth.on.crons. According to the advisory, langgraph-sdk "incorrectly applies the actions= argument" on those resource-scoped decorators. A handler meant for one action instead "registers that handler for every action on the resource."

The maintainers published the advisory on 28 August 2026, a day after the 0.4.4 release. NVD added the CVE record on 2 October 2026 and its status is still "Received", so NVD has not yet run its own analysis. The score above comes from GitHub as the CNA. GitHub credits the reporter as Grg0rry; the advisory was published by jdrogers940.

Why it matters

Custom auth is the layer that keeps tenants apart on a LangGraph API server. LangChain's documentation says custom authentication applies to both cloud and self-hosted deployments of its server (the product formerly called LangGraph Platform, now LangSmith Deployment). The same docs describe three levels of handler, from the global @auth.on through resource handlers to per-action handlers. This bug breaks the assumption that a narrow handler only fires for its own action. It is the same class of failure as the Obot MCP gateway authorization bypass we covered, where signed-in users reached servers they were not meant to.

The advisory puts the result plainly: an authenticated user "may therefore be able to perform actions the application intended to deny, such as reading, updating, or deleting another user's resource." The attacker needs a valid login but no special interaction. Confidentiality and integrity impact are rated high, availability none.

Who is exposed

The advisory limits exposure to "Python deployments using actions= on the affected resource-scoped decorators." You are likely not affected if:

• you do not use custom auth at all;
• you use only the global @auth.on handler, or per-action decorators such as @auth.on.threads.create, rather than actions= on the resource decorator (this is our reading of the advisory; the record does not list those forms as safe);
• the handler you registered with actions= already enforces ownership and permission checks for every action it receives. The advisory says such deployments "remain protected."

You are at risk if the code that langgraph.json points to under auth.path contains something like @auth.on.threads(actions=["create"]) and your real ownership filtering lives in a broader fallback handler. Whether the vulnerable SDK version is what your server actually loads depends on how you deploy. We could not confirm whether LangChain's managed cloud was updated; check with the vendor if you run there.

Technical details

The advisory's own example:

@auth.on.threads(actions=["create"])
async def allow_thread_create(ctx, value):
    return None

In affected versions this handler is registered for every thread action (read, update, delete, search, create_run and so on). Because a resource-wide handler is selected before broader fallback handlers, the fallback's checks may not run. The handler returns None, which allows the request and applies no owner filter, so another user's thread can be reached. The weakness is classed CWE-863, Incorrect Authorization. The CVSS vector is CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N; the "Attack Requirements: Present" element reflects the need for a particular handler setup.

The fix commit (5a77be5, 27 August 2026) makes the resource decorators honor actions= and reject empty or invalid action lists. It also adds a changelog warning that matters for defenders: "because unmatched custom-auth paths remain allowed, deployments using action-scoped handlers should configure a global default-deny handler." The same note says langgraph-api 0.10 and later warns about uncovered paths at startup. The resource decorators now also reject a resources= value that does not match their own resource and tell you to use @auth.on(resources=...) instead, which could break existing code on upgrade.

A create-only handler is applied to every thread action, so the owner-filter fallback never runs.

What defenders should do

1. Search your repositories for @auth.on.threads(, @auth.on.assistants( and @auth.on.crons( with an actions= argument. No hits means this CVE does not apply to that code.
2. Check the installed langgraph-sdk version in the image or environment that actually runs the server. Treat anything from 0.1.45 to 0.4.3 as vulnerable.
3. Upgrade. 0.4.4 is the fixed release and 0.4.5 (21 September 2026) followed it with no security entry in its notes, so move to the latest 0.4.x or newer rather than pinning to 0.4.4. The advisory lists no workaround.
4. After upgrading, add a global default-deny @auth.on handler (for the wider design, see our piece on runtime authorization for agent tool calls). Since 0.4.4 honors actions=, any action not covered by a handler is still allowed unless you deny it.
5. Run a cross-user test: with two accounts, try to read, update and delete the other's thread, assistant and cron.
6. Review access logs since you adopted actions= handlers for cross-user access. We found no reports of exploitation in the sources we read.
7. Do not stop at this CVE. LangGraph has had several recent authorization-related issues. langgraph-api before 0.10.0 is affected by CVE-2026-55235 (a loopback webhook path that skips the user auth context) and CVE-2026-55236 (a run-creation check that dispatches assistants.search instead of assistants.read, exposing another user's private assistant where only a read handler exists and no global fallback does). Both were fixed in 0.10.0. Separately, langgraph-sdk 0.3.14 and earlier (CVE-2026-48776, fixed in 0.3.15) built request paths from unsanitized identifiers. So 0.4.4 fixes this bug only, and it is not a complete floor for an auth-sensitive deployment.

What is still unclear

• Whether LangChain's managed cloud runs were affected or patched, and when.
• Whether exploitation has occurred; the sources do not say, and the CVE is not in KEV.
• Which handler shapes beyond the example are exploitable, since the advisory says impact depends on handler behavior.
• NVD has not yet analysed the record, so its own severity score may differ from GitHub's 7.6.

Sources

• NVD record, CVE-2026-104873
• GitHub advisory GHSA-fvww-7h3r-vfhp
• langgraph-sdk 0.4.4 release
• langgraph-sdk 0.4.5 release
• Fix commit 5a77be5
• NVD keyword search: langgraph
• CISA KEV catalog
• LangChain docs: custom authentication
• LangChain docs: authentication and access control
• LangChain changelog: product naming changes (LangSmith Deployment)