plaincve:~$

// threat brief

CVE-2026-77936

Letta's shipped compose.yaml is insecure by default: an API with no login and PostgreSQL left open with a default password

CVSS
9.3 CRITICAL
CISA KEV
Not listed
Weakness
CWE-1188
Topics
AI security · Infrastructure

PlainCVE Team · Published 2026-10-21 · AI-assisted · Press brief ↓

AI review 2026-10-21 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

Letta's compose.yaml (through 0.16.8) leaves every API route without a password and exposes PostgreSQL with default credentials; no fix is known.

Who is affectedPeople and organizations self-hosting a Letta server (PyPI package letta) with the compose.yaml shipped in versions up to and including 0.16.8, using its defaults. Sources do not say whether versions after 0.16.8 are still affected.
What happensAnyone who can reach the server, with no account, can run arbitrary Python and manage /v1/admin users (CVE record); researchers (Lasso Security) say the code runs inside the server container and that they can also read and modify every tenant's data. If the database port is reachable and the default password is unchanged, they can also run operating system commands through PostgreSQL, because researchers say the bundled role is a superuser.
What to do nowNo fixed version is known. Turn on the server's password protection, stop publishing the PostgreSQL port, replace the default database password, and keep the Letta server off untrusted networks.
Affected versionsThe compose.yaml shipped with versions up to and including 0.16.8; OSV records the range as starting from the earliest version. The status of versions after 0.16.8 is unknown.
Fixed versionsUnconfirmed: no fixed version or fix commit was found in the sources
CVSS vector
Show full vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Timeline
  • First public 2026-10-18

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check your version and compose.yaml settings

    Run in the folder holding compose.yaml (read-only) to check whether password protection is on, whether the default database password is still used, and whether port 5432 is published. Compose also loads .env, so check that file too (grep errors if it does not exist; that is fine). Version ≤ 0.16.8 deployed with defaults is affected; later versions are unknown, so check the settings anyway.

    Read-only check
    grep -nE 'SECURE|LETTA_SERVER_PASSWORD|LETTA_PG_PASSWORD|5432' compose.yaml .env
    Step 2Step 4
  2. 02Check the Letta version

    Run (read-only) where the Letta server runs: its virtual environment, or inside the server container via docker exec. The official compose uses the letta/letta:latest image, so pip show on the host will usually not find the server's version; whether pip exists in the image and shows a version depends on your environment. If it shows nothing, check the image tag and build date instead. (PlainCVE suggestion)

    Read-only check
    pip show letta | grep -i '^version'
    Step 2
  3. 03Check whether the PostgreSQL port is published

    On the Docker host, list container port mappings; 5432 bound to 0.0.0.0 means other machines may be able to reach it. (PlainCVE suggestion)

    Read-only check
    docker ps --format '{{.Names}}\t{{.Ports}}' | grep 5432
    Step 4
  4. 04Search PostgreSQL logs for suspicious activity

    TheHackerWire suggests watching for connections from unexpected IPs, logins with default credentials, and COPY PROGRAM statements. Search the log folder (including subfolders) inside the database container or on its volume; the actual path depends on your setup. PlainCVE note: the official compose.yaml sets no logging options, and Postgres in a container usually logs to stderr by default (use docker logs instead), while connection and statement logging (log_connections, log_statement) must be enabled first. Otherwise this command finds nothing, which does not mean you were not compromised.

    Read-only check
    grep -riE 'copy .*program|connection authorized|password authentication failed' /path/to/postgresql/log/
    Step 4Step 5
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Turn on server password protection

    Vendor docs: pass SECURE=true and LETTA_SERVER_PASSWORD to docker run. The CVE record names LETTA_SERVER_SECURE, and TheHackerWire recommends enabling it in compose.yaml. Which name applies to the compose deployment is unconfirmed, so after the change confirm that requests without the password are rejected.

    Step 2Step 3
  2. 02Unpublish the Postgres port and replace the default password

    Researchers (Lasso Security) suggest not publishing the Postgres port to the host and generating non-default database credentials.

    Step 4
  3. 03Restrict who can reach the server

    PlainCVE suggestion: use a firewall or bind only to internal networks so neither the Letta API nor the database is reachable from untrusted networks.

    Step 1Step 4
RESPONDRespondIf you find signs of compromise
  1. 01If it was exposed: treat it as possibly compromised

    PlainCVE suggestion: look for unknown accounts in the /v1/admin user list, change the database password and any credentials stored on the server, and rebuild the server and database containers from a clean configuration. There is no known evidence of exploitation in the wild; this is a precaution.

    Step 3Step 5
HARDENHardenPrevent the next one
  1. 01Don't run the database role as a superuser

    Suggested by researchers (Lasso Security). Then even if someone logs in to the database, they can't use superuser-only features like COPY PROGRAM.

    Step 5
  2. 02Note the Docker image is no longer supported

    The vendor docs say the Docker image is no longer an actively maintained or supported product. PlainCVE suggestion: don't wait for an official fix; review your own deployment settings or consider a still-supported way to run Letta.

Full remediation steps and notes

No fixed version is known, so for now the fix is configuration. Suggested order:

  1. Cut off outside access first, then change settings, so you aren’t exposed while editing.
  2. The password variable names differ: the vendor’s Docker docs say SECURE=true plus LETTA_SERVER_PASSWORD (for docker run); the CVE record and TheHackerWire name LETTA_SERVER_SECURE. Which one works for the compose deployment is unconfirmed, so after the change, test that requests without the password are rejected.
  3. Database: remove the database ports mapping from compose.yaml (PlainCVE’s note: in a typical Compose setup the server container can still reach it over the internal network; verify after the change) and set a new LETTA_PG_PASSWORD. Note: PostgreSQL usually applies that password only when the data volume is first created, so for an existing database change the password inside the database as well (PlainCVE’s note).

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

Letta's shipped compose.yaml is insecure by default: an API with no login and PostgreSQL left open with a default password: 1. Reaches a Letta server deployed with the default settings → 2. The password check is never installed → 3. Runs arbitrary Python through the tool-run API → 4. Logs in to the published PostgreSQL port with default credentials → 5. Runs operating system commands through COPY PROGRAMCVE-2026-77936 · Letta's shipped compose.yaml is insecure by default: an API with no login and PostgreSQLleft open with a default passwordAttackerYour systemReaches a Letta server deployed with the default settings — No account, password or privileges are needed, only network access. 1Reaches a Lettaserver deployedwith the defaultsettingsThe password check is never installed — compose.yaml does not enable LETTA_SERVER_SECURE, so the password-checking middleware is never added and every API route is unauthenticated. 2The password checkis never installedRuns arbitrary Python through the tool-run API — Researchers say the code runs inside the server container. Per the CVE record, the attacker can also manage /v1/admin users; researchers say they can also read and modify every tenant's data. 3Runs arbitraryPython through thetool-run APILogs in to the published PostgreSQL port with default credentials — The vendor's compose.yaml publishes port 5432 to the host by default with the password defaulting to 'letta'; researchers say the bundled database role is a superuser. 4Logs in to thepublishedPostgreSQL portwith defaul…Runs operating system commands through COPY PROGRAM — COPY PROGRAM is a PostgreSQL feature that lets a superuser run an external program. Researchers say the commands run on the database container; a news site says they run on the underlying host. The sources disagree. 5Runs operatingsystem commandsthrough COPYPROGRAMAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-77936-letta-insecure-default-config · CC BY 4.0
Letta's shipped compose.yaml is insecure by default: an API with no login and PostgreSQL left open with a default password: 1. Reaches a Letta server deployed with the default settings → 2. The password check is never installed → 3. Runs arbitrary Python through the tool-run API → 4. Logs in to the published PostgreSQL port with default credentials → 5. Runs operating system commands through COPY PROGRAMCVE-2026-77936 · Letta's shippedcompose.yaml is insecure by default: anAPI with no login and PostgreSQL leftopen with a default passwordReaches a Letta server deployed with the default settings — No account, password or privileges are needed, only network access. 1AttackerReaches a Letta server deployedwith the default settingsThe password check is never installed — compose.yaml does not enable LETTA_SERVER_SECURE, so the password-checking middleware is never added and every API route is unauthenticated. 2Your systemThe password check is neverinstalledRuns arbitrary Python through the tool-run API — Researchers say the code runs inside the server container. Per the CVE record, the attacker can also manage /v1/admin users; researchers say they can also read and modify every tenant's data. 3AttackerRuns arbitrary Python throughthe tool-run APILogs in to the published PostgreSQL port with default credentials — The vendor's compose.yaml publishes port 5432 to the host by default with the password defaulting to 'letta'; researchers say the bundled database role is a superuser. 4AttackerLogs in to the publishedPostgreSQL port with defaultcredentialsRuns operating system commands through COPY PROGRAM — COPY PROGRAM is a PostgreSQL feature that lets a superuser run an external program. Researchers say the commands run on the database container; a news site says they run on the underlying host. The sources disagree. 5AttackerRuns operating system commandsthrough COPY PROGRAMAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-77936-letta-insecure-default-config
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Reaches a Letta server deployed with the default settings

    No account, password or privileges are needed, only network access.

    Defense: PlainCVE suggestion: keep the Letta server off the internet and untrusted networks; restrict who can connect with a firewall or reverse proxy.

  2. Your system

    The password check is never installed

    compose.yaml does not enable LETTA_SERVER_SECURE, so the password-checking middleware is never added and every API route is unauthenticated.

    Defense: Turn on password protection. The vendor docs say to pass SECURE=true and LETTA_SERVER_PASSWORD to docker run; TheHackerWire recommends enabling LETTA_SERVER_SECURE in compose.yaml. Which variable name applies to the compose deployment is unconfirmed.

  3. Attacker

    Runs arbitrary Python through the tool-run API

    Researchers say the code runs inside the server container. Per the CVE record, the attacker can also manage /v1/admin users; researchers say they can also read and modify every tenant's data.

    Defense: Same as step 2: with password protection on, these APIs require the password.

  4. Attacker

    Logs in to the published PostgreSQL port with default credentials

    The vendor's compose.yaml publishes port 5432 to the host by default with the password defaulting to 'letta'; researchers say the bundled database role is a superuser.

    Defense: Researchers (Lasso Security) suggest not publishing the Postgres port by default and generating non-default database credentials on first run.

  5. Attacker

    Runs operating system commands through COPY PROGRAM

    COPY PROGRAM is a PostgreSQL feature that lets a superuser run an external program. Researchers say the commands run on the database container; a news site says they run on the underlying host. The sources disagree.

    Defense: Researchers (Lasso Security) suggest not running the database role as a superuser.

Who is affected

Letta is an open-source project for building AI agents that you can host yourself. The problem isn’t one piece of code but the deployment file the project ships, compose.yaml (the file Docker Compose uses to describe which containers to start).

ConditionAffected?
letta up to and including 0.16.8, deployed with the shipped compose.yaml defaultsAffected (VulnCheck, CVE record)
Same, but the database port is unreachableThe API part is still affected; the database route needs port 5432 to be reachable
Versions after 0.16.8 (Snyk lists 0.34.12 as the latest)Unknown. No source says whether later versions still ship the same file; this is our analysis
Fixed versionUnconfirmed. No fixed version, fix commit or official fix information was found (OffSeq also found none)

OSV records the affected range as starting from the earliest version. Letta’s docs say the Docker image is “no longer an actively maintained or supported” product, and the CVE record is tagged unsupported-when-assigned.

How it works

Two defaults stack up:

  1. The API is unlocked. Researchers say the server adds its password-checking middleware (a check that runs before a request reaches the feature) only when LETTA_SERVER_SECURE=true. The shipped compose.yaml does not turn it on, so every API route is unauthenticated. The CVE record says remote attackers can therefore run arbitrary Python through the tool-run API and manage /v1/admin users; researchers say the code runs inside the server container and that attackers can read and modify every tenant’s data (tenants being the separate users or organizations sharing one server).
  2. The database door is open too. The vendor’s compose.yaml publishes PostgreSQL port 5432 to the host by default with the password defaulting to letta; researchers say the bundled database role is a superuser. A superuser can use PostgreSQL’s COPY PROGRAM feature to run operating system commands. Sources disagree on where those commands run: researchers say the database container; TheHackerWire says the underlying host.

The weakness type is CWE-1188 (initialization of a resource with an insecure default).

The flawed approach (conceptual illustration, not the original file):

Show code example(yaml)
# Database: password has a default, port published to the host
POSTGRES_PASSWORD=${LETTA_PG_PASSWORD:-letta}
ports: "${LETTA_PG_PORT:-5432}:5432"
# Server: LETTA_SERVER_SECURE not set → no password check
Show code example(python)
if secure_enabled:          # only checks when explicitly turned on
    app.add_middleware(CheckPassword)
# otherwise: every route is unauthenticated

A safer approach (conceptual illustration): the database publishes no port, uses no default password, and its role is not a superuser; the server always requires a password and refuses to start without one, instead of silently staying open.

Timeline

DateEvent
2026-08-21CVE ID reserved
2026-10-18Public disclosure date given in the CVE record (datePublic)
2026-10-19VulnCheck advisory date
2026-10-20CVE record published (CNA: VulnCheck)
2026-10-21Not in CISA KEV as of this date; NVD status is currently Awaiting Analysis

Further reading

  • Scores: the CNA (VulnCheck) gives CVSS 4.0 9.3 and CVSS 3.1 9.8, both Critical; NVD has not scored it yet. GitHub’s GHSA-g524-hhf9-5x95 has not been reviewed by GitHub.
  • Exploitation: not in CISA KEV, and no evidence of exploitation in the wild or before a fix (no fix is known). EPSS (the estimated chance of exploitation within 30 days) is about 0.47%. A public proof of concept exists: CISA’s SSVC rates exploitation as poc (and automatable), and the CNA tags the researchers’ page as an exploit in the CVE record (that page contains exploit material; we do not link it). TheHackerWire only says no standalone exploit was in the repositories it monitors (GitHub, Exploit-DB, Nuclei); that scope is different, so it does not contradict the above.
  • Credit: Noy Pearl, Michael Sromin and Ophir Dror (per VulnCheck’s advisory). The CVE was assigned by VulnCheck, not by the Letta project.
  • The Lasso Security research cited on this page (code location, database role, where code runs, database advice) comes from its vulnerability database page, which is left out of our sources because it contains exploit material.

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-21 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. CVE / NVD / OSVCVE-2026-77936 Record (CVE Services API) · CVE Program (CNA: VulnCheck), 2026-10-20 · accessed 2026-10-21
  2. CVE / NVD / OSVNVD - CVE-2026-77936 · NIST · accessed 2026-10-21
  3. AdvisoryLetta through 0.16.8 Insecure Default Configuration Unauthenticated API and PostgreSQL Access · VulnCheck, 2026-10-19 · accessed 2026-10-21
  4. AdvisoryGitHub Advisory Database: GHSA-g524-hhf9-5x95 (unreviewed) · GitHub · accessed 2026-10-21
  5. OtherOSV - CVE-2026-77936 · OSV · accessed 2026-10-21
  6. Otherletta 0.16.8 (Snyk package page) · Snyk · accessed 2026-10-21
  7. VendorLetta Docker documentation · Letta · accessed 2026-10-21
  8. Vendorletta compose.yaml (commit 1131535) · letta-ai (GitHub) · accessed 2026-10-21
  9. NewsCVE-2026-77936: Letta Unauthenticated RCE and OS Command Injection via Insecure Defaults · TheHackerWire · accessed 2026-10-21
  10. NewsCVE-2026-77936: Initialization of a Resource with an Insecure Default in letta-ai letta · OffSeq Radar · accessed 2026-10-21

Press brief

In one sentence

Letta is an open-source project for building AI agents. The Docker Compose file it ships does not turn on password protection by default, so anyone who can reach the server can use every API without logging in, including running arbitrary Python code; the same file also exposes the PostgreSQL database with a default password, and researchers say its role is a superuser. VulnCheck published the CVE on October 20, 2026, covering versions up to and including 0.16.8. No fixed version has been found, and Letta's docs say the Docker image is no longer supported.

Key facts

Severity (CNA: VulnCheck)
CVSS 4.0 9.3; CVSS 3.1 9.8 cveawg.mitre.org
Affected versions
letta <= 0.16.8 vulncheck.com
CVE published
2026-10-20 cveawg.mitre.org
VulnCheck advisory date
10/19/2026 vulncheck.com
NVD status
Awaiting Analysis services.nvd.nist.gov

Confirmed

  • The compose.yaml shipped through 0.16.8 does not enable LETTA_SERVER_SECURE, so every API route is unauthenticated.
  • The vendor's compose.yaml publishes PostgreSQL port 5432 to the host by default, with the password defaulting to 'letta'.
  • The vendor docs say the Docker image is no longer an actively maintained or supported product.
  • As of 2026-10-21, the CVE was not in the CISA KEV catalog.
  • A public proof of concept exists: CISA's SSVC rates exploitation as poc; the CNA tags the researchers' page as an exploit in the CVE record (that page contains exploit material; we do not link it).

Unconfirmed / disputed

  • No fixed version or fix commit was found; whether versions after 0.16.8 are still affected is unknown.
  • Sources disagree on where COPY PROGRAM commands run: researchers say the database container, a news site says the underlying host.
  • There is no evidence of exploitation in the wild.

Quotable line

This isn't one wrong line of code; it's a config file where following the example leaves every door open.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "Letta's shipped compose.yaml is insecure by default: an API with no login and PostgreSQL left open with a default password". PlainCVE. https://plaincve.date/en/vulns/cve-2026-77936-letta-insecure-default-config (accessed YYYY-MM-DD)
BibTeX
@misc{cve202677936lettainsecuredefaultconfig2026,
  title  = {Letta's shipped compose.yaml is insecure by default: an API with no login and PostgreSQL left open with a default password},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-77936-letta-insecure-default-config},
  note   = {Updated 2026-10-21}
}