CWE-441
Allowed-with-ReviewUnintended Proxy or Intermediary ('Confused Deputy')
Abstraction: Class · Status: Draft
The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.
294 vulnerabilities reference this CWE, most recent first.
GHSA-X5C9-V98J-722R
Vulnerability from github – Published: 2026-09-23 18:12 – Updated: 2026-09-23 18:12Summary
9router treats local loopback requests as trusted and allows access to /v1/* without an
API key. In a documented/common reverse-proxy deployment where nginx forwards public
traffic to the backend via 127.0.0.1, external non-Origin requests are misclassified as
local. This allows unauthenticated access to /v1 APIs such as /v1/models, and may allow
abuse of configured upstream provider credentials depending on the enabled providers.
Details
- Affected version / commit: 9router
v0.4.80@b282f05. - Deployment precondition: a same-host reverse proxy (e.g. nginx) forwarding public
traffic to the backend on
127.0.0.1/localhost. This mirrors the documented cloud deployment (proxy_pass http://localhost:20128withX-Real-IP/X-Forwarded-For). - Observed behaviour:
- The direct backend (
direct-backend, port18081) returns401for/v1/modelswithout an API key. - A direct request that spoofs
X-9r-Real-IP: 127.0.0.1still returns401: the custom server deletes the client-supplied header and overwrites it with the real socket address, so naive header spoofing does not work against the direct backend. - The proxied path (
reverse-proxy, port18080) returns200with the full model catalog for the same/v1/modelsrequest without any API key. - A proxied request that carries an
Originheader returns401. The bypass therefore primarily affects curl / SDK / server-side / non-browser clients, which do not sendOrigin. - Root cause: the backend's local/remote decision relies on perceived socket/loopback
locality after reverse proxying. Because nginx connects to the backend from
127.0.0.1, the backend stamps a loopback client address for every internet client and treats the request as local, skipping the/v1API-key requirement. The forwardedX-Real-IP/X-Forwarded-Forheaders that carry the true client IP are ignored for this decision. - This is not a simple client header-spoofing issue (the direct-spoof control above proves header spoofing is rejected); it is a property of how loopback proxy traffic is trusted.
Proof of Concept
This repository is a self-contained Docker Compose reproduction. No real provider is called and no real API key is required.
- Build and start the stack:
bash docker compose up --build - Direct baseline (no API key):
bash curl -i http://127.0.0.1:18081/v1/models - Direct spoof control:
bash curl -i -H "X-9r-Real-IP: 127.0.0.1" http://127.0.0.1:18081/v1/models - Reverse-proxy bypass (no API key):
bash curl -i http://127.0.0.1:18080/v1/models - Reverse-proxy
Origincontrol:bash curl -i -H "Origin: http://evil.example" http://127.0.0.1:18080/v1/models
Expected evidence
| Request | Result |
|---|---|
Direct 18081, no key |
401 Unauthorized ({"error":"API key required for remote API access"}) |
Direct 18081, X-9r-Real-IP: 127.0.0.1 spoof |
401 Unauthorized |
Proxied 18080, no key |
200 OK with the full model catalog |
Proxied 18080, with Origin |
401 Unauthorized |
Impact
- Unauthenticated access to the
/v1API surface in the affected reverse-proxy deployment. - Model enumeration via
/v1/models. - Possible abuse of the operator's configured upstream provider credentials through
/v1/chat/completionsand other/v1proxy endpoints (the attacker spends the operator's provider quota/keys without holding any key of their own). - Actual impact depends on which providers are configured and how the instance is exposed to the public internet.
- The attacker requires no API key.
Suggested Fix
- Do not use client/proxy/socket IP locality as an authentication bypass.
- Require an API key by default for
/v1/*on public listeners. - If local trust is genuinely needed, bind it to an unguessable server-generated secret or to a Unix domain socket that is only accessible locally — not to "the connection looks like loopback".
- When running behind reverse proxies, use an explicit trusted-proxy configuration and a
real client-IP derivation (e.g. a vetted
X-Forwarded-Forchain), and never treat all loopback proxy traffic as end-user-local. - Document a secure reverse-proxy configuration for operators.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.80"
},
"package": {
"ecosystem": "npm",
"name": "9router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56675"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290",
"CWE-306",
"CWE-441"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-23T18:12:26Z",
"nvd_published_at": "2026-07-10T17:17:01Z",
"severity": "HIGH"
},
"details": "## Summary\n\n9router treats local loopback requests as trusted and allows access to `/v1/*` without an\nAPI key. In a documented/common reverse-proxy deployment where nginx forwards public\ntraffic to the backend via `127.0.0.1`, external non-`Origin` requests are misclassified as\nlocal. This allows unauthenticated access to `/v1` APIs such as `/v1/models`, and may allow\nabuse of configured upstream provider credentials depending on the enabled providers.\n\n## Details\n\n- **Affected version / commit:** 9router `v0.4.80` @ `b282f05`.\n- **Deployment precondition:** a same-host reverse proxy (e.g. nginx) forwarding public\n traffic to the backend on `127.0.0.1` / `localhost`. This mirrors the documented cloud\n deployment (`proxy_pass http://localhost:20128` with `X-Real-IP` / `X-Forwarded-For`).\n- **Observed behaviour:**\n - The **direct backend** (`direct-backend`, port `18081`) returns `401` for `/v1/models`\n without an API key.\n - A **direct request that spoofs** `X-9r-Real-IP: 127.0.0.1` still returns `401`: the\n custom server deletes the client-supplied header and overwrites it with the real socket\n address, so naive header spoofing does not work against the direct backend.\n - The **proxied path** (`reverse-proxy`, port `18080`) returns `200` with the full model\n catalog for the same `/v1/models` request **without any API key**.\n - A **proxied request that carries an `Origin` header** returns `401`. The bypass\n therefore primarily affects curl / SDK / server-side / non-browser clients, which do\n not send `Origin`.\n- **Root cause:** the backend\u0027s local/remote decision relies on perceived socket/loopback\n locality after reverse proxying. Because nginx connects to the backend from `127.0.0.1`,\n the backend stamps a loopback client address for **every** internet client and treats the\n request as local, skipping the `/v1` API-key requirement. The forwarded `X-Real-IP` /\n `X-Forwarded-For` headers that carry the true client IP are ignored for this decision.\n- This is **not** a simple client header-spoofing issue (the direct-spoof control above\n proves header spoofing is rejected); it is a property of how loopback proxy traffic is\n trusted.\n\n## Proof of Concept\n\nThis repository is a self-contained Docker Compose reproduction. No real provider is called\nand no real API key is required.\n\n1. Build and start the stack:\n ```bash\n docker compose up --build\n ```\n2. Direct baseline (no API key):\n ```bash\n curl -i http://127.0.0.1:18081/v1/models\n ```\n3. Direct spoof control:\n ```bash\n curl -i -H \"X-9r-Real-IP: 127.0.0.1\" http://127.0.0.1:18081/v1/models\n ```\n4. Reverse-proxy bypass (no API key):\n ```bash\n curl -i http://127.0.0.1:18080/v1/models\n ```\n5. Reverse-proxy `Origin` control:\n ```bash\n curl -i -H \"Origin: http://evil.example\" http://127.0.0.1:18080/v1/models\n ```\n\n### Expected evidence\n\n| Request | Result |\n|---------|--------|\n| Direct `18081`, no key | `401 Unauthorized` (`{\"error\":\"API key required for remote API access\"}`) |\n| Direct `18081`, `X-9r-Real-IP: 127.0.0.1` spoof | `401 Unauthorized` |\n| Proxied `18080`, no key | `200 OK` with the full model catalog |\n| Proxied `18080`, with `Origin` | `401 Unauthorized` |\n\n## Impact\n\n- Unauthenticated access to the `/v1` API surface in the affected reverse-proxy deployment.\n- Model enumeration via `/v1/models`.\n- Possible abuse of the operator\u0027s configured upstream provider credentials through\n `/v1/chat/completions` and other `/v1` proxy endpoints (the attacker spends the operator\u0027s\n provider quota/keys without holding any key of their own).\n- Actual impact depends on which providers are configured and how the instance is exposed\n to the public internet.\n- The attacker requires **no API key**.\n\n## Suggested Fix\n\n- Do not use client/proxy/socket IP locality as an authentication bypass.\n- Require an API key by default for `/v1/*` on public listeners.\n- If local trust is genuinely needed, bind it to an unguessable server-generated secret or\n to a Unix domain socket that is only accessible locally \u2014 not to \"the connection looks\n like loopback\".\n- When running behind reverse proxies, use an explicit trusted-proxy configuration and a\n real client-IP derivation (e.g. a vetted `X-Forwarded-For` chain), and never treat all\n loopback proxy traffic as end-user-local.\n- Document a secure reverse-proxy configuration for operators.",
"id": "GHSA-x5c9-v98j-722r",
"modified": "2026-09-23T18:12:26Z",
"published": "2026-09-23T18:12:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/decolua/9router/security/advisories/GHSA-x5c9-v98j-722r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56675"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/commit/da667836cc7584bea0edd893de1d590c9ea279dc"
},
{
"type": "PACKAGE",
"url": "https://github.com/decolua/9router"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/releases/tag/v0.5.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "9router /v1 APIs has unauthenticated access via reverse proxy locality collapse"
}
GHSA-XJV7-6W92-42R7
Vulnerability from github – Published: 2025-10-01 21:20 – Updated: 2025-11-20 17:20Summary
The /mpl/<port>/<route> endpoint, which is accessible without authentication on default Marimo installations allows for external attackers to reach internal services and arbitrary ports.
Details
From our understanding, this route is used internally to provide access to interactive matplotlib visualizations.
marimo/marimo/_server/main.py at main · marimo-team/marimo
This endpoint functions as an unauthenticated proxy, allowing an attacker to connect to any service running on the local machine via the specified <port> and <route>.
The existence of this proxy is visible in the application's code (marimo/_server/main.py), but there's no official documentation or warning about its behavior or potential risks.
Impact
CWE-441: Proxying Without Authentication
This vulnerability, as it can be used to bypass firewalls and access internal services that are intended to be local-only. The level of impact depends entirely on what services are running and accessible on the local machine.
Full Local Access: An attacker can use this proxy to connect to local services that answer to web sockets, HTTP or ASGI protocol, effectively gaining a foothold on the machine. Depending on the service, this can lead to remote code execution, data exfiltration, or further network penetration.
Exposure of Sensitive Services: Our scans of public-facing Marimo servers have shown that many are exposing sensitive internal services, including:
Old CUPS Servers: Could allow an attacker to view print jobs or configuration or depending on old vulnerabilities, allow RCE.
phpMyAdmin: Provides a web interface to a MySQL database, potentially exposing sensitive data.
RPCMapper: Can be used for network reconnaissance and enumerating services.
While you’d hope people wouldn’t expose marimo instances to the internet, we found numerous public Marimo instances using tools like Shodan. Many of these servers, some even hosted on cloud platforms like AWS GovCloud, were found to be vulnerable. This means the vulnerability isn't limited to a few isolated cases but is a widespread issue affecting production environments.
===
Notes, this was discovered by devgi. I (acepace) followed up and also created this report.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "marimo"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.20"
},
{
"fixed": "0.16.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-441"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-01T21:20:11Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe `/mpl/\u003cport\u003e/\u003croute\u003e` endpoint, which is accessible without authentication on default Marimo installations allows for external attackers to reach internal services and arbitrary ports. \n\n### Details\nFrom our understanding, this route is used internally to provide access to interactive matplotlib visualizations.\n[marimo/marimo/_server/main.py at main \u00b7 marimo-team/marimo](https://github.com/marimo-team/marimo/blob/main/marimo/_server/main.py) \nThis endpoint functions as an unauthenticated proxy, allowing an attacker to connect to any service running on the local machine via the specified `\u003cport\u003e` and `\u003croute\u003e`.\n\nThe existence of this proxy is visible in the application\u0027s code (marimo/_server/main.py), but there\u0027s no official documentation or warning about its behavior or potential risks.\n\n\n### Impact\nCWE-441: Proxying Without Authentication\n\nThis vulnerability, as it can be used to bypass firewalls and access internal services that are intended to be local-only. The level of impact depends entirely on what services are running and accessible on the local machine.\n\nFull Local Access: An attacker can use this proxy to connect to local services that answer to web sockets, HTTP or ASGI protocol, effectively gaining a foothold on the machine. Depending on the service, this can lead to remote code execution, data exfiltration, or further network penetration.\n\nExposure of Sensitive Services: Our scans of public-facing Marimo servers have shown that many are exposing sensitive internal services, including:\n\nOld CUPS Servers: Could allow an attacker to view print jobs or configuration or depending on old vulnerabilities, allow RCE.\n\nphpMyAdmin: Provides a web interface to a MySQL database, potentially exposing sensitive data.\n\nRPCMapper: Can be used for network reconnaissance and enumerating services.\n\nWhile you\u2019d hope people wouldn\u2019t expose marimo instances to the internet, we found numerous public Marimo instances using tools like Shodan. Many of these servers, some even hosted on cloud platforms like AWS GovCloud, were found to be vulnerable. This means the vulnerability isn\u0027t limited to a few isolated cases but is a widespread issue affecting production environments.\n\n===\n\nNotes, this was discovered by [devgi](https://github.com/devgi). I ([acepace](https://github.com/acepace)) followed up and also created this report.",
"id": "GHSA-xjv7-6w92-42r7",
"modified": "2025-11-20T17:20:23Z",
"published": "2025-10-01T21:20:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/marimo-team/marimo/security/advisories/GHSA-xjv7-6w92-42r7"
},
{
"type": "WEB",
"url": "https://github.com/marimo-team/marimo/commit/0312706d5e594acdb405209b2c8d87c98f46b22b"
},
{
"type": "PACKAGE",
"url": "https://github.com/marimo-team/marimo"
},
{
"type": "WEB",
"url": "https://github.com/marimo-team/marimo/releases/tag/0.16.4"
},
{
"type": "WEB",
"url": "https://marimo-team.notion.site/cve-proxy-without-authentication"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "marimo vulnerable to proxy abuse of /mpl/{port}/"
}
GHSA-XP42-V53J-R9GH
Vulnerability from github – Published: 2026-08-13 18:31 – Updated: 2026-09-05 15:30A flaw was found in the clusterclaims-controller component of Multicluster Engine (MCE). An authenticated tenant can exploit this vulnerability by manipulating ClusterClaim labels. This allows the tenant to force a cluster to join a ManagedClusterSet belonging to another tenant. Such unauthorized access could enable the injection of policies and workloads into other tenants' clusters.
{
"affected": [],
"aliases": [
"CVE-2026-73266"
],
"database_specific": {
"cwe_ids": [
"CWE-441"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T17:17:35Z",
"severity": "HIGH"
},
"details": "A flaw was found in the clusterclaims-controller component of Multicluster Engine (MCE). An authenticated tenant can exploit this vulnerability by manipulating ClusterClaim labels. This allows the tenant to force a cluster to join a ManagedClusterSet belonging to another tenant. Such unauthorized access could enable the injection of policies and workloads into other tenants\u0027 clusters.",
"id": "GHSA-xp42-v53j-r9gh",
"modified": "2026-09-05T15:30:25Z",
"published": "2026-08-13T18:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73266"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59556"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59557"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59558"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59559"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59579"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59593"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-73266"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2514217"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XWW4-PC4H-X9HJ
Vulnerability from github – Published: 2026-10-07 15:31 – Updated: 2026-10-07 18:32A Pre-authentication SSRF vulnerability exists in the SMA1000 Appliance Work Place interface due to an unintended alternate access path. By abusing this path, a remote unauthenticated attacker could potentially exploit this vulnerability to direct the appliance to issue requests on their behalf and reach internal functionality and perform unauthorized operations.
{
"affected": [],
"aliases": [
"CVE-2026-102255"
],
"database_specific": {
"cwe_ids": [
"CWE-441"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-07T13:17:16Z",
"severity": "CRITICAL"
},
"details": "A Pre-authentication SSRF vulnerability exists in the SMA1000 Appliance Work Place interface due to an unintended alternate access path. By abusing this path, a remote unauthenticated attacker could potentially exploit this vulnerability to direct the appliance to issue requests on their behalf and reach internal functionality and perform unauthorized operations.",
"id": "GHSA-xww4-pc4h-x9hj",
"modified": "2026-10-07T18:32:08Z",
"published": "2026-10-07T15:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102255"
},
{
"type": "WEB",
"url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0017"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Enforce the use of strong mutual authentication mechanism between the two parties.
Mitigation
Whenever a product is an intermediary or proxy for transactions between two other components, the proxy core should not drop the identity of the initiator of the transaction. The immutability of the identity of the initiator must be maintained and should be forwarded all the way to the target.
CAPEC-219: XML Routing Detour Attacks
An attacker subverts an intermediate system used to process XML content and forces the intermediate to modify and/or re-route the processing of the content. XML Routing Detour Attacks are Adversary in the Middle type attacks (CAPEC-94). The attacker compromises or inserts an intermediate system in the processing of the XML message. For example, WS-Routing can be used to specify a series of nodes or intermediaries through which content is passed. If any of the intermediate nodes in this route are compromised by an attacker they could be used for a routing detour attack. From the compromised system the attacker is able to route the XML process to other nodes of their choice and modify the responses so that the normal chain of processing is unaware of the interception. This system can forward the message to an outside entity and hide the forwarding and processing from the legitimate processing systems by altering the header information.
CAPEC-465: Transparent Proxy Abuse
A transparent proxy serves as an intermediate between the client and the internet at large. It intercepts all requests originating from the client and forwards them to the correct location. The proxy also intercepts all responses to the client and forwards these to the client. All of this is done in a manner transparent to the client.