Letta Authentication and Information Disclosure Flaws

Unauthenticated remote code execution and full administrative takeover affect Letta deployments through 0.16.8 that use the project's shipped compose.yaml, because the file leaves LETTA_SERVER_SECURE unset so the password middleware is never registered and every REST API route is reachable without credentials. A network-positioned attacker can therefore invoke POST /v1/tools/run to execute arbitrary Python, manage users via /v1/admin, and - through the same compose file's published PostgreSQL superuser port with default credentials - run operating-system commands via COPY PROGRAM. Publicly available exploit code exists and the issue has been cataloged by VulnCheck, though it is not confirmed actively exploited (CISA KEV); exploitation requires only that the instance be network-reachable in its default configuration, with no authentication or user interaction needed.

Cross-tenant impersonation in Letta through 0.16.8 allows an authenticated low-privileged API caller to read and modify another user's agents, memory, and configuration by setting the self-asserted user_id HTTP header to the victim's tenant ID, even when LETTA_SERVER_SECURE is enabled. The server trusts the client-supplied identity key during request resolution, so the bypass requires only API connectivity and a known or guessed target user_id, not credential theft or memory corruption. Publicly available exploit code exists, with no CISA KEV listing confirming active exploitation; this is a genuine high-priority issue for multi-tenant or shared Letta deployments, while single-user instances have little cross-tenant data to expose.

Authenticated users of Letta through 0.16.8 can read server secrets when the LocalSandbox tool backend is used, because tool subprocesses inherit the server process environment; calling POST /v1/tools/run or running a custom tool can expose LETTA_PG_URI, POSTGRES_PASSWORD, and provider API keys. In multi-tenant deployments sharing one Postgres instance, those leaked database credentials can be used to reach other tenants' data, although single-tenant or properly isolated sandbox deployments are much less exposed. Publicly available exploit code exists, but the provided data does not confirm active exploitation (no CISA KEV entry), and exploitation requires an authenticated account with permission to execute tools.