plaincve:~$

// threat brief

CVE-2026-108863

Katanemo Plano Envoy admin interface has no authentication: anyone who can reach the admin port (9901, or 19901 on the host with plano up) can read configured LLM API keys in plaintext

CVSS
7.5 HIGH
CISA KEV
Not listed
Weakness
CWE-306 · CWE-522 · CWE-200
Topics
AI security · Infrastructure

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

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

Plano's Envoy admin page is open on all interfaces with no login; anyone who reaches it can read your LLM API keys in plaintext. No fix known yet.

Who is affectedAnyone running Katanemo Plano (PyPI package planoai) 0.4.37 or earlier with a real LLM provider key configured, where the Envoy admin port (9901 in the container, published as host port 19901 by plano up or the development Compose file) is reachable from untrusted networks.
What happensAn attacker with no account can read the LLM provider API keys you configured. A third-party, AI-generated analysis says leaked keys may be used for unauthorized LLM usage, depending on each key's privileges.
What to do nowNo fixed version is known. Publish the admin port to localhost only (for example 127.0.0.1:19901:9901) or remove that port publication; ports published by Docker bypass ufw/iptables INPUT rules, so a host firewall alone may not block them (per Docker's official documentation). If the port was ever exposed, rotate your LLM provider keys (PlainCVE's suggestion).
Affected versionsAll versions up to and including 0.4.37 (the CNA range starts at version 0; the researcher confirmed only 0.4.37, at commit 72002a62, by static code review, without running it)
Fixed versionsUnknown: no primary source names a patched release (the CVE record lists no fixed version, and the latest PyPI release is still 0.4.37); OSV marks commit 72002a62 (0.4.37) as fixed, but the CNA records 0.4.37 as still affected
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Timeline
  • First public 2026-10-11

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

    Run this on the host or in the Python virtual environment where the planoai CLI is installed (activate that virtual environment first). planoai 0.4.37 and earlier fall in the CNA's affected range. No fixed version is known, so the version number can only tell you that you are affected, not that you are safe. If you installed it with pipx, pip show will not find the package; use pipx list to see the planoai version instead. If you used uv tool or another installer, check with that tool's list feature; a "not found" result does not mean it is not installed.

    Read-only check
    pip show planoai | grep -i '^version'
  2. 02Check whether the admin port is exposed

    Check whether anything listens on port 9901 or 19901 on the host, and whether containers publish those ports. A listen address of 0.0.0.0 rather than 127.0.0.1 means other machines may be able to reach it.

    Read-only check
    ss -ltnp | grep -E ':(9901|19901)\b'; docker ps --format '{{.Names}} {{.Ports}}' | grep -E '9901|19901'
    Step 1Step 2
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Publish the admin port to localhost only, or not at all

    On setups started with plano up or the development Compose file, the container's 9901 is published as host port 19901. Change the publication to bind 127.0.0.1 only (for example 127.0.0.1:19901:9901), or remove it. According to Docker's official documentation, published container ports are diverted in the nat table before reaching the INPUT/OUTPUT chains that ufw uses, so restricting 19901 with ufw/iptables INPUT rules alone may not work; adding 127.0.0.1 means only the Docker host itself can reach the port (Docker's documentation also warns that in releases older than 28.0.0, hosts on the same L2 segment can still reach ports published to localhost). This is PlainCVE's suggestion based on Docker's documentation, not a vendor fix.

    Step 1
  2. 02Allow admin access from localhost only

    Envoy's own documentation recommends admin access only from localhost or a secure network, optionally limiting paths with allow_paths. This is general guidance for the Envoy component, not a Plano vendor fix for this flaw.

    Step 2Step 3
RESPONDRespondIf you find signs of compromise
  1. 01Rotate exposed LLM provider keys

    If the admin port was ever reachable from an untrusted network, assume the keys leaked: revoke and reissue them in each LLM provider's console, and check for unusual usage. This is PlainCVE's suggestion; no source has reported exploitation in the wild.

    Step 4Step 5
HARDENHardenPrevent the next one
  1. 01Don't use the development setup on exposed hosts

    The researcher notes that plano up and the shipped development Compose file publish the admin port as host port 19901. On internet-facing hosts, review which ports are published.

    Step 1
  2. 02Least privilege and spending limits for keys

    If a key leaks anyway, privilege and usage limits cap the damage (PlainCVE's suggestion).

    Step 5
Full remediation steps and notes

No primary source names a vendor fix or vendor security advisory (OSV marks the 0.4.37 commit as fixed, but the CNA records 0.4.37 as still affected; the GitHub entry is an unreviewed database record that does not link to a maintainer advisory). Order matters here:

  1. Close the door before changing the locks. First publish the admin port to localhost only (for example 127.0.0.1:19901:9901) or remove that port publication, so only the local machine can reach it, and only then rotate keys. If you do it the other way round, the new keys may be read straight away. (PlainCVE’s suggestion)
  2. Check both ports, and don’t rely on the host firewall alone. Which port is open on the host (9901 or 19901) depends on how you deploy. According to Docker’s official documentation, published container ports are diverted in the nat table and bypass ufw/iptables INPUT rules, so blocking 19901 in the host firewall alone may not work; change how the port is published instead (bind 127.0.0.1 only, or don’t publish it). Docker’s documentation also warns that in releases older than 28.0.0, hosts on the same L2 segment can still reach ports published to localhost.
  3. Rotate keys. If the admin port was ever reachable from an untrusted network, revoke and reissue the keys in each LLM provider’s console and check for unusual usage. (PlainCVE’s suggestion)
  4. Watch for a fix. Look out for a Plano release after 0.4.37 and whether its release notes mention the admin interface.

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.

Katanemo Plano Envoy admin interface has no authentication: anyone who can reach the admin port (9901, or 19901 on the host with plano up) can read configured LLM API keys in plaintext: 1. The attacker connects to the Envoy admin port on the host → 2. The admin interface has no login check → 3. The attacker reads the configuration dump → 4. The configuration contains LLM provider keys in plaintext → 5. Stolen keys may be used to access LLM provider services without authorizationCVE-2026-108863 · Katanemo Plano Envoy admin interface has no authentication: anyone who can reach the adminport (9901, or 19901 on the host with plano up) can read configured LLM API keys in plaintextAttackerYour systemExternalThe attacker connects to the Envoy admin port on the host — The CNA describes port 9901; the researcher notes that plano up and the shipped development Compose file publish it as host port 19901. No Plano account or role is needed. 1The attackerconnects to theEnvoy admin porton the hostThe admin interface has no login check — Plano 0.4.37's Envoy template binds the admin interface to 0.0.0.0 (every network interface), and the interface itself asks for no authentication. 2The admininterface has nologin checkThe attacker reads the configuration dump — The admin interface offers a /config_dump feature that returns Envoy's full current configuration. 3The attacker readsthe configurationdumpThe configuration contains LLM provider keys in plaintext — The keys sit unmasked in the WASM filter configuration. This requires at least one provider whose access_key resolves to a real key. 4The configurationcontains LLMprovider keys inplaintextStolen keys may be used to access LLM provider services without authorization — This comes from a third-party, AI-generated analysis: it may lead to unauthorized use, depending on the key's privileges.5Stolen keys may beused to access LLMprovider serviceswithou…Attack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-108863-plano-envoy-admin-key-exposure · CC BY 4.0
Katanemo Plano Envoy admin interface has no authentication: anyone who can reach the admin port (9901, or 19901 on the host with plano up) can read configured LLM API keys in plaintext: 1. The attacker connects to the Envoy admin port on the host → 2. The admin interface has no login check → 3. The attacker reads the configuration dump → 4. The configuration contains LLM provider keys in plaintext → 5. Stolen keys may be used to access LLM provider services without authorizationCVE-2026-108863 · Katanemo Plano Envoyadmin interface has no authentication:anyone who can reach the admin port(9901, or 19901 on the host with plan…The attacker connects to the Envoy admin port on the host — The CNA describes port 9901; the researcher notes that plano up and the shipped development Compose file publish it as host port 19901. No Plano account or role is needed. 1AttackerThe attacker connects tothe Envoy admin port onthe hostThe admin interface has no login check — Plano 0.4.37's Envoy template binds the admin interface to 0.0.0.0 (every network interface), and the interface itself asks for no authentication. 2Your systemThe admin interface hasno login checkThe attacker reads the configuration dump — The admin interface offers a /config_dump feature that returns Envoy's full current configuration. 3AttackerThe attacker reads theconfiguration dumpThe configuration contains LLM provider keys in plaintext — The keys sit unmasked in the WASM filter configuration. This requires at least one provider whose access_key resolves to a real key. 4Your systemThe configurationcontains LLM providerkeys in plaintextStolen keys may be used to access LLM provider services without authorization — This comes from a third-party, AI-generated analysis: it may lead to unauthorized use, depending on the key's privileges.5ExternalStolen keys may be usedto access LLM providerservices withoutauthorizationAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-108863-plano-envoy-admin-key-exposure
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    The attacker connects to the Envoy admin port on the host

    The CNA describes port 9901; the researcher notes that plano up and the shipped development Compose file publish it as host port 19901. No Plano account or role is needed.

    Defense: Publish the port to 127.0.0.1 only (for example 127.0.0.1:19901:9901) or remove the publication. Ports published by Docker are diverted before ufw/iptables INPUT rules apply, so a host firewall may not block them (per Docker's official documentation).

  2. Your system

    The admin interface has no login check

    Plano 0.4.37's Envoy template binds the admin interface to 0.0.0.0 (every network interface), and the interface itself asks for no authentication.

    Defense: Envoy's documentation recommends allowing admin access only via localhost.

  3. Attacker

    The attacker reads the configuration dump

    The admin interface offers a /config_dump feature that returns Envoy's full current configuration.

    Defense: Envoy's documentation mentions allow_paths to limit which admin paths are reachable.

  4. Your system

    The configuration contains LLM provider keys in plaintext

    The keys sit unmasked in the WASM filter configuration. This requires at least one provider whose access_key resolves to a real key.

  5. External

    Stolen keys may be used to access LLM provider services without authorization

    This comes from a third-party, AI-generated analysis: it may lead to unauthorized use, depending on the key's privileges.

    Defense: Rotate any exposed keys and give each key least privilege and usage limits (PlainCVE's suggestion).

Who is affected

Plano is an open-source tool from Katanemo that sits between applications and LLM (large language model) services and forwards requests. Internally it uses a proxy program called Envoy to handle network traffic. The affected package is planoai on PyPI.

ConditionAffected?
Plano 0.4.37 or earlier + a real LLM provider key configured + admin port reachable from an untrusted networkAffected
Plano 0.4.37 or earlier, but the admin port is reachable only from localhost or trusted hostsThe flaw is still there, but an attacker first has to reach the port
Versions after 0.4.37Unknown: no primary source names a fixed version (PyPI has no release after 0.4.37)

Some details:

  • Version range. The CNA (the organization that issued the CVE, here VulnCheck) starts the range at version 0, and OSV lists releases back to 0.1.0 as affected. The researcher hieuPenguinnn’s write-up (that page contains attack code; we do not link to it) confirmed only 0.4.37 (commit 72002a62, Envoy v1.37.0 base image), and only by static code review, without running it: the researcher states that no Plano instance was started, the admin interface was never contacted, and no /config_dump response was captured. The claim that /config_dump does not mask the keys is the researcher’s inference from Envoy’s documentation. Whether older versions are affected comes from the CNA’s range, not from anyone’s tests.
  • Port number. The CNA describes port 9901. The researcher notes that plano up and the shipped development Compose file publish the container’s 9901 as host port 19901. Which port is open on your host depends on how you deploy.
  • No fixed version known. Our analysis: the vendor’s releases page, captured on 2026-10-12, showed 0.4.37 (released 28 September) as the latest release. That is the last affected version, so no patched release seems to exist yet; the latest planoai release on PyPI is likewise 0.4.37, published 2026-09-28. The CVE record (CNA) lists no fixed version, and the GitHub entry does not link to a maintainer advisory. A third-party CVE tracker also reports no fix. Note that since 2026-10-15 OSV has marked commit 72002a62 (that is, 0.4.37) as fixed, but the CNA records 0.4.37 as still affected; this is not an official fix.

How it works

Envoy has a built-in admin interface that lets operators inspect its state and export its configuration. The interface has no login of its own, which is why Envoy’s documentation recommends allowing access only from localhost or a secure network.

Plano 0.4.37’s Envoy configuration template (the vendor’s own file) binds the admin interface to 0.0.0.0 on port 9901. 0.0.0.0 means “every network interface”, so other machines may be able to connect too.

The admin interface has a /config_dump feature that returns Envoy’s full configuration. Plano writes the LLM provider API keys (the secret strings a program uses to prove its identity to an AI service) into the configuration of a WASM filter (a plug-in that runs inside Envoy), in plaintext. According to the CVE record (CNA), the result is that anyone who can reach the admin port can read your keys without an account. (The researcher reached this conclusion from static code review and Envoy’s documentation, not from observing a live system.) This requires at least one provider whose access_key resolves to a real key.

The CNA classifies this as CWE-306 (missing authentication for critical function); the researcher also lists CWE-200 (exposure of sensitive information) and CWE-522 (insufficiently protected credentials). The CVSS vectors score only confidentiality (High), with no integrity or availability impact.

The problematic configuration (conceptual illustration, not Plano’s full source file):

Show code example(yaml)
admin:
  address:
    # The admin interface is reachable on every network interface, with no authentication
    socket_address: { address: 0.0.0.0, port_value: 9901 }

A safer configuration (general guidance from Envoy’s documentation, not a vendor fix):

Show code example(yaml)
admin:
  address:
    # Only the local machine can reach the admin interface
    socket_address: { address: 127.0.0.1, port_value: 9901 }

Timeline

DateEvent
2026-10-11VulnCheck reserves and publishes CVE-2026-108863
2026-10-11NVD receives the record (status “Received”, not yet analysed)
2026-10-11GitHub publishes unreviewed advisory GHSA-54m9-qc5w-93rc
2026-10-12Not yet in CISA’s Known Exploited Vulnerabilities (KEV) catalog
2026-10-13CISA ADP (Vulnrichment) adds an SSVC assessment to the CVE record: Exploitation poc, Automatable yes, Technical Impact partial
2026-10-15OSV updates its entry to mark commit 72002a62 (0.4.37) as fixed; the CNA’s CVE record still lists 0.4.37 as affected with no fixed version

Further reading

  • Scoring differences. The CNA gives CVSS 4.0 8.7 and CVSS 3.1 7.5, both High; this page displays the 3.1 score. The researcher’s write-up (that page contains attack code; we do not link to it) labels the severity Medium, so the sources disagree. NVD has not published its own score.
  • Exploitation. As of 2026-10-12 it is not in KEV. No source reports exploitation in the wild, and there is no evidence it was exploited as a zero-day. Not being in KEV does not rule exploitation out. In the CVE record, the CISA ADP (Vulnrichment) SSVC assessment of 2026-10-13 rates Exploitation as poc, meaning a public proof of concept (PoC) exists, and tags the researcher’s write-up as an exploit (that page contains attack code; we do not link to it). An SSVC rating of poc does not mean the flaw has been exploited in the wild; whether it has is still unknown.
  • What leaked keys mean. A third-party, AI-generated analysis says leaked keys may lead to unauthorized use of LLM services, depending on the key’s privileges. This is not a vendor statement.
  • Credit. The CVE record credits hieuPenguinnn as the finder.
  • Related weakness types: CWE-306, CWE-200, CWE-522.

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-18 · 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-108863 record (CVE Services API) · CVE Program / VulnCheck (CNA), 2026-10-11 · accessed 2026-10-12
  2. CVE / NVD / OSVNVD API - CVE-2026-108863 · NIST, 2026-10-11 · accessed 2026-10-12
  3. AdvisoryKatanemo Plano through 0.4.37 Missing Authentication on Envoy Admin Interface · VulnCheck, 2026-10-11 · accessed 2026-10-12
  4. AdvisoryGitHub Advisory Database - GHSA-54m9-qc5w-93rc (unreviewed) · GitHub, 2026-10-11 · accessed 2026-10-12
  5. OtherOSV - CVE-2026-108863 · OSV · accessed 2026-10-18
  6. OtherPyPI - planoai release history (JSON API) · PyPI · accessed 2026-10-18
  7. Vendorplano 0.4.37 config/envoy.template.yaml · Katanemo (GitHub) · accessed 2026-10-12
  8. OtherEnvoy documentation: Administration interface · Envoy Proxy · accessed 2026-10-12
  9. OtherDocker documentation: Packet filtering and firewalls · Docker · accessed 2026-10-17
  10. OtherDocker documentation: Port publishing and mapping · Docker · accessed 2026-10-17
  11. OtherCVE-2026-108863 (OffSeq Threat Radar) · OffSeq · accessed 2026-10-12
  12. OtherCVE-2026-108863 (HOL Guard) · HOL · accessed 2026-10-12
  13. NewsCVE-2026-108863 (The Hacker Wire) · The Hacker Wire · accessed 2026-10-12

Press brief

In one sentence

Plano, an open-source tool from Katanemo for connecting applications to AI model services, runs a proxy called Envoy internally. CVE-2026-108863 says Plano 0.4.37 and earlier leave Envoy's admin interface open on every network interface with no login, so anyone who can reach it can read the configured AI service API keys. VulnCheck published the CVE on October 11, 2026, and no primary source (the CVE record or the PyPI release history) names a fixed version.

Key facts

Severity (CNA)
CVSS 4.0 8.7; CVSS 3.1 7.5 cveawg.mitre.org
Affected versions
0.4.37 and earlier cveawg.mitre.org
CVE published
2026-10-11 (VulnCheck) cveawg.mitre.org
Admin interface binding
0.0.0.0:9901 (vendor template, 0.4.37) github.com
Finder
hieuPenguinnn cveawg.mitre.org

Confirmed

  • The CVE record (CNA, VulnCheck) states that in Plano 0.4.37 and earlier the Envoy admin interface requires no authentication and that LLM provider keys can be read in plaintext via /config_dump.
  • The vendor's 0.4.37 Envoy template binds the admin interface to 0.0.0.0 on port 9901.
  • As of 2026-10-12 it was not in CISA's Known Exploited Vulnerabilities catalog.
  • In the CVE record, the CISA ADP (Vulnrichment) SSVC assessment of 2026-10-13 rates Exploitation as poc (public proof of concept available).

Unconfirmed / disputed

  • No primary source names a fixed version (the CVE record lists none, and the latest PyPI release is still 0.4.37), and there is no vendor security advisory; OSV marks commit 72002a62 (0.4.37) as fixed, but the CNA records 0.4.37 as still affected.
  • Severity is disputed: the CNA (VulnCheck) rates it High, while the researcher's write-up labels it Medium.
  • Whether it has been exploited in the wild is unknown; not being in KEV does not rule it out.
  • Whether versions before 0.4.37 are affected comes from the CNA's range; nobody has reported testing them.

Quotable line

Nobody had to crack the keys; they were sitting behind an admin door that faced the street and had no lock.

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). "Katanemo Plano Envoy admin interface has no authentication: anyone who can reach the admin port (9901, or 19901 on the host with plano up) can read configured LLM API keys in plaintext". PlainCVE. https://plaincve.date/en/vulns/cve-2026-108863-plano-envoy-admin-key-exposure (accessed YYYY-MM-DD)
BibTeX
@misc{cve2026108863planoenvoyadminkeyexposure2026,
  title  = {Katanemo Plano Envoy admin interface has no authentication: anyone who can reach the admin port (9901, or 19901 on the host with plano up) can read configured LLM API keys in plaintext},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-108863-plano-envoy-admin-key-exposure},
  note   = {Updated 2026-10-18}
}