Letta EUVD-2026-104693

Exploitation requires that the Letta server accept and trust a client-supplied 'user_id' HTTP header as the tenant/user identity (the default behavior through version 0.16.8, per the referenced dependencies.py identity-resolution logic). The attacker must have network access to the Letta API and enough access to issue API calls (PR:L); they then simply set user_id to a target tenant's ID. Notably, enabling LETTA_SERVER_SECURE does NOT limit this attack - the reporter states the bypass works even with that control on. Limiting factors: the attacker needs working API connectivity to the server and must know or guess a valid target user_id/tenant ID; single-tenant deployments with no other users present little to steal, so real impact concentrates in multi-tenant or shared-instance Letta deployments running 0.16.8 or earlier.

This is a genuine high-priority issue, not a CVSS-inflated one. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 8.6 and aligns cleanly with the description: a network-reachable, low-complexity authorization bypass (CWE-639, IDOR via a user-controlled key) requiring only low privilege - a valid API caller - with no user interaction. The impact metrics VC:H/VI:H (confidentiality and integrity high, availability none) match a flaw that lets an attacker read AND modify another tenant's agents, memory, and configuration. A public exploit is confirmed (publicly available exploit code exists, reported by VulnCheck with a Lasso Security write-up), which materially raises real-world risk even though no EPSS score, KEV listing, or SSVC decision data was supplied. The absence of KEV/EPSS data means active in-the-wild exploitation is NOT confirmed and should not be assumed; the signal here is 'exploit code available,' not 'exploitation observed.' One notable aggravator the raw CVSS does not capture: the description states the bypass works 'even with LETTA_SERVER_SECURE enabled,' meaning the primary hardening control does not mitigate it. The main risk-limiting factor is PR:L - the attacker needs some legitimate API access to the Letta server - so exposure is highest for multi-tenant/shared Letta deployments rather than fully single-tenant installs.

An attacker with legitimate low-privilege API access to a shared Letta server sends normal API requests but sets the user_id HTTP header to a victim tenant's identifier. Because the server trusts this self-asserted header for identity, the attacker reads and modifies the victim's agents, stored memory, and configuration across the tenant boundary. Public exploit code for this technique already exists (VulnCheck/Lasso Security).