Summary
Letta contains an authentication and authorization bypass that allows an API caller to claim another user's identity through a self-asserted HTTP header. If the caller can reach the API and control this identity value, they may access or modify another tenant's agents, memory, and configuration, even when secure server settings are enabled.
Letta contains an authentication and authorization bypass that allows an API caller to claim another user's identity through a self-asserted HTTP header. If the caller can reach the API and control this identity value, they may access or modify another tenant's agents, memory, and configuration, even when secure server settings are enabled.
Affected context
The vulnerability occurs in Letta API deployments where the server accepts a client-supplied user identity value without reliably binding it to the authenticated principal. It is especially risky in multi-tenant environments, where user or tenant identifiers determine access to agents, memory, and configuration. Transport security or secure-server settings do not by themselves prevent the issue if authorization trusts an attacker-controlled identity header.
The vulnerability occurs in Letta API deployments where the server accepts a client-supplied user identity value without reliably binding it to the authenticated principal. It is especially risky in multi-tenant environments, where user or tenant identifiers determine access to agents, memory, and configuration. Transport security or secure-server settings do not by themselves prevent the issue if authorization trusts an attacker-controlled identity header.
Exploit preconditions
- Attack surface: Letta HTTP API endpoints that use the supplied user identity to select resources
- Required access: Network access to the affected API; the exact need for valid credentials depends on deployment-level authentication controls
- Trigger point: Processing an API request containing a caller-controlled user identity header
- Why exploitation is possible: Resource authorization relies on an identity value supplied by the requester rather than on a server-validated identity bound to the authenticated session
- Attack surface: Letta HTTP API endpoints that use the supplied user identity to select resources
- Required access: Network access to the affected API; the exact need for valid credentials depends on deployment-level authentication controls
- Trigger point: Processing an API request containing a caller-controlled user identity header
- Why exploitation is possible: Resource authorization relies on an identity value supplied by the requester rather than on a server-validated identity bound to the authenticated session
Why this happens
The underlying issue is an authorization design flaw in which a request-controlled identifier is treated as authoritative for tenant or user selection. This allows the caller to influence the security principal used during resource lookup and access checks. The behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key, because access decisions can be redirected to another user's resources through a key controlled by the requester.
The underlying issue is an authorization design flaw in which a request-controlled identifier is treated as authoritative for tenant or user selection. This allows the caller to influence the security principal used during resource lookup and access checks. The behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key, because access decisions can be redirected to another user's resources through a key controlled by the requester.
Potential impact
- An attacker could read another tenant's agents or memory
- An attacker could modify agents, memory, or configuration belonging to another user
- Cross-tenant confidentiality and integrity could be compromised
- Malicious changes could disrupt workflows or alter agent behavior
- The issue could facilitate broader account or tenant compromise depending on exposed operations
- An attacker could read another tenant's agents or memory
- An attacker could modify agents, memory, or configuration belonging to another user
- Cross-tenant confidentiality and integrity could be compromised
- Malicious changes could disrupt workflows or alter agent behavior
- The issue could facilitate broader account or tenant compromise depending on exposed operations
General mitigation guidance
Mitigation generally focuses on deriving identity from a trusted authentication context rather than from client-provided headers.
Common defensive patterns include:
- Binding authorization decisions to a server-validated session, token subject, or mutually authenticated principal
- Rejecting or ignoring client-supplied identity headers for authorization purposes
- Enforcing tenant and resource ownership checks at every relevant API operation
- Applying deny-by-default authorization with least-privilege access scopes
- Separating administrative impersonation workflows from ordinary user requests and requiring explicit, auditable controls
- Testing authorization behavior with conflicting identity values and cross-tenant resource identifiers
Mitigation generally focuses on deriving identity from a trusted authentication context rather than from client-provided headers.
Common defensive patterns include:
- Binding authorization decisions to a server-validated session, token subject, or mutually authenticated principal
- Rejecting or ignoring client-supplied identity headers for authorization purposes
- Enforcing tenant and resource ownership checks at every relevant API operation
- Applying deny-by-default authorization with least-privilege access scopes
- Separating administrative impersonation workflows from ordinary user requests and requiring explicit, auditable controls
- Testing authorization behavior with conflicting identity values and cross-tenant resource identifiers
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis and code review rules identifying authorization decisions based on request headers or other user-controlled identifiers
- Review of middleware and route handlers for identity binding between authentication context and resource ownership
- Dynamic tests that compare authenticated principals with supplied user or tenant identifiers
- API gateway policies that remove, normalize, or block reserved identity headers from untrusted clients
- Audit-log monitoring for access to resources where the requested identity differs from the authenticated principal
- Automated security testing that exercises cross-tenant read and write operations
Organizations can look for this weakness through:
- Static analysis and code review rules identifying authorization decisions based on request headers or other user-controlled identifiers
- Review of middleware and route handlers for identity binding between authentication context and resource ownership
- Dynamic tests that compare authenticated principals with supplied user or tenant identifiers
- API gateway policies that remove, normalize, or block reserved identity headers from untrusted clients
- Audit-log monitoring for access to resources where the requested identity differs from the authenticated principal
- Automated security testing that exercises cross-tenant read and write operations
