Bug 2489596 (CVE-2026-48776)

Summary:	CVE-2026-48776 langgraph: langgraph-sdk: LangGraph Python SDK: Unsafe URL path construction leads to unauthorized resource access
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	anpicker, dfreiber, drow, dschmidt, erezende, hasun, jburrell, jfula, jkoehler, jlanda, jowilson, kshier, lphiri, mbarnett, nyancey, ometelka, ptisnovs, rjohnson, simaishi, smcdonal, stcannon, syedriko, teagle, vkumar, xdharmai, yguenane
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the LangGraph Python SDK. This vulnerability allows a remote attacker with low privileges to manipulate URL paths by providing unsanitized input. This could result in unintended access, modification, or deletion of resources, potentially compromising data confidentiality and integrity. The issue is most significant in systems that directly use untrusted user input for SDK identifier parameters without validation.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-06-16 21:10:13 UTC

LangGraph 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.