CVE-2026-77937: Cross-Tenant Impersonation via Self-Asserted user_id Header
A flaw in Letta's API takes the caller's tenant identity from a user_id request header without verifying it. Any API caller can impersonate any tenant and read or modify that tenant's agents, memory and configuration, even when authentication is enabled.
Overview
Letta is an open-source platform for building stateful AI agents with long-term memory. It decides which tenant a request belongs to from a user_id HTTP header and never checks that header against an authenticated session or credential.
Enabling LETTA_SERVER_SECURE adds a single shared admin secret, but it does not tie the caller to a tenant, so the header still decides whose data is returned or changed. Any caller who knows or guesses another tenant's user_id can read and modify that tenant's agents, memory and configuration.
Because any caller can read and modify another tenant's agents, memory and data simply by setting a user_id header, and enabling Letta's authentication does not stop it, this vulnerability is rated High (CVSS 8.1), and multi-tenant deployments should not rely on Letta's tenant separation until it is fixed
Affected Product
Affected Files
- letta/server/rest_api/dependencies.py line 39 (actor_id = Header(None, alias="user_id"))
- letta/services/user_manager.py line 113 (user resolved from asserted ID with no verification)
Root Cause
The caller's identity is resolved from a user_id HTTP request header that is taken at face value without verification against any authenticated session or credential. Any caller can assert any user_id value and be granted access to that tenant's data. This flaw persists when LETTA_SERVER_SECURE is enabled: enabling authentication adds a single shared admin secret but does not bind the authenticated caller to a specific tenant identity.
PoC
With any authenticated or unauthenticated session, set user_id header to a victim tenant's ID:
GET /v1/agents/?name=victim-secret-agent
Header: user_id: <victim-user-id>It should return victim tenant's agent list and memory.
Confirmed: same query with the default tenant's user_id returns 0 results,
proving tenant scoping is enforced only against an honest client
Cross-tenant write demonstrated via tool execution:
POST /v1/tools/run with a victim's user_id header:
UPDATE agents SET name=name||'-PWNED'(Applied to victim tenant's agents)
Impact
Any caller with network access to the API can read and modify any tenant's agents, memory, and data by asserting that tenant's user_id in a request header.
Enabling LETTA_SERVER_SECURE does not remediate this finding: the shared admin secret authenticates the request but the asserted user_id header still determines which tenant's data is returned or modified. Full cross-tenant compromise of all agent data, memory, and configuration is achievable by any authenticated API consumer.
Suggested Remediation
Replace the self-asserted user_id header with per-tenant credentials or tokens so that an authenticated caller's identity is derived from their verified credential, not from an arbitrary request header value.
Additional Resources
- CVE-2026-77937 record:
