GHSA-fvww-7h3r-vfhp: Pip/langgraph-sdk vulnerability
Impact What kind of vulnerability is it? Who is impacted? langgraph-sdk incorrectly applies the actions= argument on resource-scoped authorization decorators, including @auth.on.threads, @auth.on.assistants, and @auth.on.crons.
In affected versions, a decorator such as:
python @auth.on.threads(actions=["create"]) async def allowthreadcreate(ctx, value): return None intended to register a handler for selected actions instead registers that handler for every action on the resource. Because the resource-wide handler is selected before broader fallback handlers, authorization checks implemented in those fallback handlers may not run.
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. Exploitability and impact depend on the affected handler's behavior: deployments remain protected if that handler independently enforces the necessary action, ownership, or permission checks for every request it receives.
Only Python deployments using actions= on the affected resource-scoped decorators are affected.
Patches
0.4.4
Workarounds
No.
References
N/A
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/langgraph-sdkto a version that resolves this vulnerability.Fixed in 0.4.4 - Upgrade
Upgrade
langgraph-sdkto a version that resolves this vulnerability.Fixed in 0.4.4 - Compensating control
For handlers using actions= on resource-scoped decorators such as @auth.on.threads, @auth.on.assistants, or @auth.on.crons, independently enforce the required action, ownership, or permission checks for every request.
Event History
Frequently Asked Questions
Which deployments are affected?
Only Python deployments using langgraph-sdk resource-scoped authorization decorators with the actions= argument are affected. The affected decorators include @auth.on.threads, @auth.on.assistants, and @auth.on.crons.
What conditions allow unauthorized actions?
A resource-scoped handler configured for selected actions is incorrectly registered for every action on that resource. If broader fallback handlers contain the action, ownership, or permission checks, they may not run because the resource-wide handler is selected first.
Are deployments protected if their resource-scoped handler performs its own authorization checks?
Yes. A deployment remains protected when the affected handler independently enforces the necessary action, ownership, or permission checks for every request it receives.
What remediation is available if the deployment is affected?
Update to version 0.4.4. No workaround is provided.