CVE-2026-77936 in Letta
Summary
by MITRE • 10/20/2026
Letta through 0.16.8 ships a compose.yaml that does not enable LETTA_SERVER_SECURE, so the password middleware is never added and all API routes are unauthenticated, and it exposes a superuser PostgreSQL port with default credentials. Remote attackers can execute arbitrary Python via POST /v1/tools/run, manage /v1/admin users, or run OS commands via COPY PROGRAM.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability in Letta versions through 0.16.8 stems from an insecure default configuration within the provided compose.yaml file, which fundamentally compromises the security posture of the deployed application by disabling critical authentication mechanisms and exposing sensitive infrastructure services to unauthenticated access. The primary technical flaw involves the LETTA_SERVER_SECURE environment variable not being enabled in this default deployment template. This omission prevents the initialization of password middleware for the API layer, effectively leaving all Application Programming Interface routes without any form of identity verification or authorization checks. Consequently, the application operates with a null security boundary where any remote actor can interact with internal endpoints as if they were an authenticated administrator or superuser.
This lack of authentication directly facilitates several severe exploitation vectors that allow for complete system compromise and data exfiltration. Attackers can exploit the unauthenticated POST /v1/tools/run endpoint to execute arbitrary Python code within the context of the application server. This capability represents a critical Remote Code Execution vulnerability, allowing adversaries to run malicious scripts, install backdoors, or pivot further into the network depending on the privileges granted to the container process. Furthermore, the absence of access controls enables unauthorized users to manage /v1/admin user accounts, potentially creating new administrative credentials that persist even if the initial vector is remediated, thereby establishing a persistent foothold within the system.
Beyond application-level exploitation, the configuration exposes a superuser PostgreSQL port with default credentials, introducing significant risks related to data integrity and confidentiality. The use of default database credentials allows attackers to bypass authentication entirely when connecting to the underlying relational database management system. This exposure permits direct SQL injection attacks or simple credential-based access to retrieve, modify, or destroy sensitive application data stored in the database. The combination of unauthenticated API endpoints and exposed database services creates a compounded risk scenario where an attacker can move laterally from executing code on the host to extracting valuable intellectual property or personal identifiable information without detection by standard perimeter defenses that rely on authentication logs for threat identification.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-521 Weak Password Requirements due to the reliance on default credentials. The ability to execute arbitrary code via API endpoints corresponds to CWE-94 Improper Control of Generation of Code or Command Injection, while the exposure of administrative functions maps to CWE-269 Improvement of Privileges if an attacker escalates their role through user management APIs. In terms of tactical behavior, these actions reflect ATT&CK techniques such as T1059 Command and Scripting Interpreter for Python execution, T1078 Valid Accounts for the use of default database credentials, and T1136 Create Account to maintain persistence via admin panel manipulation.
Mitigation strategies must prioritize immediate remediation of configuration defaults rather than relying solely on network-level restrictions. Organizations should update Letta to a version where secure defaults are enforced or manually override the compose.yaml settings to explicitly enable LETTA_SERVER_SECURE before deployment. It is imperative to rotate all default credentials for both application and database services immediately upon discovery, ensuring that strong, unique passwords are assigned to superuser accounts. Additionally, implementing network segmentation to restrict access to the PostgreSQL port from non-essential subnets adds a necessary layer of defense in depth. Security teams should also audit API gateway configurations to ensure that authentication middleware is active for all administrative and tool execution endpoints, verifying through penetration testing that unauthenticated requests are properly rejected with appropriate error codes rather than processed silently.