Langgraph SdkApplication · Langchain
CVE-2026-48776
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedLangGraph Python SDK is used to connect to running LangGraph API servers, manage assistants, threads and stream runs from Python applications. Versions 0.3.14 and prior have unsafe URL path construction through unsanitized caller-supplied identifier values used in HTTP request paths for resource operations. Without sanitization of those values, identifiers that contain characters with special meaning in URL paths could cause the resulting request to address a different resource (and potentially a different resource type) than the SDK method's call site indicates. In deployments where the SDK receives identifier values that originate from untrusted sources, this could result in unintended access, modification, or deletion of resources beyond the calling user's authorization scope. This issue is most consequential in deployments that forward end-user-supplied values directly into SDK identifier parameters without first validating them against an expected format (such as a UUID), and rely on URL-prefix-based authorization at an upstream layer (reverse proxy, edge gateway, WAF), where the authorization decision is made on the SDK call's intended path rather than on the final delivered request path. The issue has been fixed in version 0.3.15.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe LangGraph Python SDK versions 0.3.14 and prior contain a path traversal vulnerability where unsanitized caller-supplied identifier values are directly interpolated into HTTP request URLs. Attackers can inject special URL characters to manipulate the request path, potentially accessing, modifying, or deleting resources outside the intended authorization scope. This is especially dangerous when identifier values originate from untrusted end-user input and upstream authorization relies on URL-prefix matching.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
Langgraph SdkApplication
< 0.3.15CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Check installed LangGraph SDK versionRun: pip show langgraph or pip list | grep langgraphAffected if Version is 0.3.14 or lower, or version cannot be determined (package not installed)
-
Identify code using LangGraph SDK identifier parametersSearch codebase for calls to SDK methods that accept thread_id, assistant_id, checkpoint_id, or similar identifier parameters (e.g., client.threads.get(), client.assistors.get(), client.checkpoints.get())Affected if Code passes dynamic identifier values to SDK methods without validation
-
Check if identifier values originate from user inputReview code flow: trace whether identifier parameters come from HTTP request parameters, API payloads, query strings, or other user-controllable sourcesAffected if Identifiers are sourced directly from request parameters, headers, or unvalidated user data without format validation
-
Verify identifier format validation existsSearch for validation logic (regex, UUID validation, allowlist checks) applied to identifiers before passing to SDK methodsAffected if No validation found or validation only checks type but not format (e.g., not enforcing UUID pattern)
-
Inspect SDK HTTP request handlingIf possible, enable request logging or proxy traffic to observe if identifier values are URL-encoded when passed to API endpointsAffected if Special characters in identifiers are not URL-encoded and appear directly in request path
You are affected if using LangGraph SDK version 0.3.14 or lower AND your code passes user-controlled or unvalidated identifier values directly to SDK methods without format validation.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped0.3.15
Upgrade LangGraph Python SDK to version 0.3.15 or later. As a defense-in-depth measure, validate all identifier parameters against expected formats (e.g., UUID) before passing to SDK methods, and review upstream authorization logic to ensure it validates the final request path, not just the intended path.
langgraph-sdk version 0.3.15
- Upgrade the langgraph-sdk package to version 0.3.15 or later using your package manager (e.g., pip install langgraph-sdk>=0.3.15)
- Verify the installation succeeded by checking the installed version (e.g., pip show langgraph-sdk)
- After upgrading, test your application to ensure the path traversal vulnerability is mitigated and no regressions are introduced
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Langgraph Sdk
Scoped from the published advisory
- Consultation2.0 h
- Implementation2.0 h
- Testing4.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,752.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-48776 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-48776 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data