Common Weakness Enumeration

CWE-807

Allowed

Reliance 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.

145 vulnerabilities reference this CWE, most recent first.

GHSA-G4HG-XR8W-WM8X

Vulnerability from github – Published: 2022-05-04 00:00 – Updated: 2022-05-10 00:00

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.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "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-GXX6-H3G6-VWJH

Vulnerability from github – Published: 2026-05-12 22:23 – Updated: 2026-06-09 10:32

Summary

SillyTavern has Authentication Bypass via SSO Header Injection

Details

Resolution

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.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "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-HM36-FFRH-C77C

Vulnerability from github – Published: 2025-10-06 20:18 – Updated: 2025-10-13 15:13

Summary

Litestar X-Forwarded-For Header Spoofing Vulnerability Enables Rate Limit Evasion

Details

While 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.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "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:33

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.

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

JSON

To clipboard

{
  "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:23

Summary

Duplicate Advisory: Picklescan Allows Remote Code Execution via Malicious Pickle File Bypassing Static Analysis

Details

Duplicate 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.

Severity

5.3 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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"
}

GHSA-HXX2-7VCW-MQR3

Vulnerability from github – Published: 2024-11-01 06:30 – Updated: 2024-11-20 16:38

Summary

Sinatra vulnerable to Reliance on Untrusted Inputs in a Security Decision

Details

Versions of the package sinatra from 0.0.0 are vulnerable to Reliance on Untrusted Inputs in a Security Decision via the X-Forwarded-Host (XFH) header. When making a request to a method with redirect applied, it is possible to trigger an Open Redirect Attack by inserting an arbitrary address into this header. If used for caching purposes, such as with servers like Nginx, or as a reverse proxy, without handling the X-Forwarded-Host header, attackers can potentially exploit Cache Poisoning or Routing-based SSRF.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "sinatra"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-21510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-01T21:37:42Z",
    "nvd_published_at": "2024-11-01T05:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Versions of the package sinatra from 0.0.0 are vulnerable to Reliance on Untrusted Inputs in a Security Decision via the X-Forwarded-Host (XFH) header. When making a request to a method with redirect applied, it is possible to trigger an Open Redirect Attack by inserting an arbitrary address into this header. If used for caching purposes, such as with servers like Nginx, or as a reverse proxy, without handling the X-Forwarded-Host header, attackers can potentially exploit Cache Poisoning or Routing-based SSRF.",
  "id": "GHSA-hxx2-7vcw-mqr3",
  "modified": "2024-11-20T16:38:35Z",
  "published": "2024-11-01T06:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21510"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sinatra/sinatra/pull/2010"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-hxx2-7vcw-mqr3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/sinatra/CVE-2024-21510.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sinatra/sinatra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sinatra/sinatra/blob/b626e2d82c23b4fde0b51782fd32ca27ccde1d1a/lib/sinatra/base.rb#L319"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sinatra/sinatra/blob/b626e2d82c23b4fde0b51782fd32ca27ccde1d1a/lib/sinatra/base.rb#L323C1-L343C17"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sinatra/sinatra/blob/main/CHANGELOG.md#410--2024-11-18"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-RUBY-SINATRA-6483832"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Sinatra vulnerable to Reliance on Untrusted Inputs in a Security Decision"
}

GHSA-HXXJ-8PHW-74VW

Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2026-02-06 22:58

Summary

Mattermost Server server restarts may provide attackers with API access

Details

An issue was discovered in Mattermost Server before 3.8.2, 3.7.5, and 3.6.7. After a restart of a server, an attacker might suddenly gain API Endpoint access.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.7-0.20170420152529-0968e4079e0a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8.0"
            },
            {
              "fixed": "3.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-18915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-06T22:58:39Z",
    "nvd_published_at": "2020-06-19T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in Mattermost Server before 3.8.2, 3.7.5, and 3.6.7. After a restart of a server, an attacker might suddenly gain API Endpoint access.",
  "id": "GHSA-hxxj-8phw-74vw",
  "modified": "2026-02-06T22:58:40Z",
  "published": "2022-05-24T17:21:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18915"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/0968e4079e0aa670254f3fe3a7248d126e3cf877"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/c7bdce8a6641ed8d361a43b6004a351535c78423"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/fb325cc339eb8d8efb60dbadc48fd38897201c6f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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": "Mattermost Server server restarts may provide attackers with API access"
}

GHSA-J42Q-R6QX-XRFP

Vulnerability from github – Published: 2026-04-10 00:30 – Updated: 2026-04-18 00:48

Summary

Duplicate Advisory: OpenClaw: Google Chat Authz Bypass via Group Policy Rebinding with Mutable Space displayName

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-52q4-3xjc-6778. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.25 contains an authorization bypass vulnerability in Google Chat group policy enforcement that relies on mutable space display names. Attackers can rebind group policies by changing or colliding space display names to gain unauthorized access to protected resources.

Severity

4.2 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

2.3 (Low)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2026.3.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-18T00:48:07Z",
    "nvd_published_at": "2026-04-09T22:16:29Z",
    "severity": "LOW"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-52q4-3xjc-6778. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw before 2026.3.25 contains an authorization bypass vulnerability in Google Chat group policy enforcement that relies on mutable space display names. Attackers can rebind group policies by changing or colliding space display names to gain unauthorized access to protected resources.",
  "id": "GHSA-j42q-r6qx-xrfp",
  "modified": "2026-04-18T00:48:07Z",
  "published": "2026-04-10T00:30:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-52q4-3xjc-6778"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/11ea1f67863d88b6cbcb229dd368a45e07094bff"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-group-policy-rebinding-with-mutable-space-displayname"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Google Chat Authz Bypass via Group Policy Rebinding with Mutable Space displayName",
  "withdrawn": "2026-04-18T00:48:07Z"
}

GHSA-J88C-7M8J-3G32

Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31

Details

Reliance on untrusted inputs in a security decision in Windows Kerberos allows an authorized attacker to elevate privileges over a network.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-20849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T18:16:13Z",
    "severity": "HIGH"
  },
  "details": "Reliance on untrusted inputs in a security decision in Windows Kerberos allows an authorized attacker to elevate privileges over a network.",
  "id": "GHSA-j88c-7m8j-3g32",
  "modified": "2026-01-13T18:31:09Z",
  "published": "2026-01-13T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20849"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20849"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J9GF-VW2F-9HRW

Vulnerability from github – Published: 2026-06-12 18:28 – Updated: 2026-06-12 18:28

Summary

Appsmith: Configuration-dependent origin validation bypass in password reset and email verification link generation

Details

Summary

A configuration-dependent origin validation bypass was identified in Appsmith’s password reset and email verification flows on current release.

Both flows derive the email-link base URL from the request Origin header. The current validation only enforces a trusted base URL when APPSMITH_BASE_URL is configured. If that setting is unset, the application accepts the caller-supplied origin and uses it to generate token-bearing reset and verification links.

On deployments with email delivery enabled and APPSMITH_BASE_URL unset, this can cause Appsmith to send security-sensitive links whose clickable host is attacker-controlled, which can plausibly lead to account takeover after victim interaction.

Details

The current release head at commit e77639eca4974469c1e676904851ffdaedd38111 was reviewed.

The relevant routes are publicly reachable in SecurityConfig.java:

POST /forgotPassword is permitted without authentication at line 209
POST /resendEmailVerification is permitted without authentication at line 228

In UserControllerCE.java, both flows copy the request Origin header into the DTO field used as the email-link base URL:

forgotPasswordRequest(...) at lines 91-94
resendEmailVerification(...) at lines 189-193

In UserServiceCEImpl.java, base URL validation is conditional:

@Value("${APPSMITH_BASE_URL:}") at line 113
resolveSecureBaseUrl(...) at lines 132-145

That method explicitly documents and implements this behavior:

if APPSMITH_BASE_URL is configured, the provided URL must match it
if APPSMITH_BASE_URL is unset, the provided URL is accepted for backward compatibility

The resulting base URL is then used to construct token-bearing links:

FORGOT_PASSWORD_CLIENT_URL_FORMAT at line 149
reset URL generation at lines 282-289
EMAIL_VERIFICATION_CLIENT_URL_FORMAT at line 152
verification URL generation at lines 931-940

This means the base URL is not only used for branding or display purposes. It directly controls the clickable host of security-sensitive reset and verification links.

Note that the admin UI describes APPSMITH_BASE_URL as required for password reset and email verification links in:

app/client/src/ce/pages/AdminSettings/config/configuration.tsx at lines 41-49

The reviewed self-host material indicates this protection is not fail-closed by default, which makes the vulnerable condition realistic on existing deployments where operators have not set APPSMITH_BASE_URL.

PoC

These steps were designed for validation on an Appsmith deployment that I own or am explicitly authorized to test.

Deploy a non-production Appsmith instance from current release, or any build containing the affected code.
Enable outbound email delivery.
Leave APPSMITH_BASE_URL unset or blank.
Use a test mailbox account you control, for example victim@example.test.
Send a password reset request with a forged Origin header:

curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/forgotPassword' \
  -H 'Content-Type: application/json' \
  -H 'Origin: https://attacker.example' \
  --data '{"email":"victim@example.test"}'

Inspect the delivered email. If affected, the clickable reset link is generated under https://attacker.example/... instead of the legitimate Appsmith host.
Repeat the same validation for resend email verification using an unverified test account:

curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/resendEmailVerification' \
  -H 'Content-Type: application/json' \
  -H 'Origin: https://attacker.example' \
  --data '{"email":"victim@example.test"}'

Inspect the delivered verification email. If affected, the clickable verification link is generated under https://attacker.example/....
Set APPSMITH_BASE_URL=https://YOUR-INSTANCE, restart the server, and repeat the same requests.
The expected secure behavior is that mismatched Origin is rejected, or the generated links no longer follow the forged request header.

Live tokens, third-party data, or unsafe exploitation material was not included in this report. The attached archive contains source excerpts, data-flow proof, safe validation notes, and supporting evidence collected from the reviewed current branch.

Impact

This is a trust-boundary failure in token-bearing email authentication flows.

Affected deployments are those where:

APPSMITH_BASE_URL is unset or blank
outbound email is enabled
password reset and/or email verification flows are enabled

Attacker requirements are low:

no prior authentication is required to reach the relevant endpoints
the attacker only needs to trigger an email flow toward a target account

Security impact:

Appsmith can generate password reset or verification emails whose clickable host is attacker-controlled
victim interaction can expose security-sensitive token material
this can plausibly result in account takeover
at minimum, it enables trusted-email abuse and phishing through the application itself

mitigation

Remove the fallback behavior in resolveSecureBaseUrl(...) that accepts caller-supplied origin data when APPSMITH_BASE_URL is unset.
Fail closed for all token-bearing email flows when no trusted base URL is configured.
Use a single trusted-base-url helper across:
password reset
resend email verification
invite flows
instance admin invite flows
Add regression tests for the unset-configuration case.
Add startup or admin-level validation so security-sensitive email flows cannot operate until a trusted base URL is configured.

Attachment

appsmith-email-link-origin-validation-bypass-20260321.zip

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.appsmith:server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T18:28:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nA configuration-dependent origin validation bypass was identified in Appsmith\u2019s password reset and email verification flows on current `release`.\n\nBoth flows derive the email-link base URL from the request `Origin` header. The current validation only enforces a trusted base URL when `APPSMITH_BASE_URL` is configured. If that setting is unset, the application accepts the caller-supplied origin and uses it to generate token-bearing reset and verification links.\n\nOn deployments with email delivery enabled and `APPSMITH_BASE_URL` unset, this can cause Appsmith to send security-sensitive links whose clickable host is attacker-controlled, which can plausibly lead to account takeover after victim interaction.\n\n### Details\nThe current `release` head at commit `e77639eca4974469c1e676904851ffdaedd38111` was reviewed.\n\nThe relevant routes are publicly reachable in `SecurityConfig.java`:\n\n- `POST /forgotPassword` is permitted without authentication at line `209`\n- `POST /resendEmailVerification` is permitted without authentication at line `228`\n\nIn `UserControllerCE.java`, both flows copy the request `Origin` header into the DTO field used as the email-link base URL:\n\n- `forgotPasswordRequest(...)` at lines `91-94`\n- `resendEmailVerification(...)` at lines `189-193`\n\nIn `UserServiceCEImpl.java`, base URL validation is conditional:\n\n- `@Value(\"${APPSMITH_BASE_URL:}\")` at line `113`\n- `resolveSecureBaseUrl(...)` at lines `132-145`\n\nThat method explicitly documents and implements this behavior:\n\n- if `APPSMITH_BASE_URL` is configured, the provided URL must match it\n- if `APPSMITH_BASE_URL` is unset, the provided URL is accepted for backward compatibility\n\nThe resulting base URL is then used to construct token-bearing links:\n\n- `FORGOT_PASSWORD_CLIENT_URL_FORMAT` at line `149`\n- reset URL generation at lines `282-289`\n- `EMAIL_VERIFICATION_CLIENT_URL_FORMAT` at line `152`\n- verification URL generation at lines `931-940`\n\nThis means the base URL is not only used for branding or display purposes. It directly controls the clickable host of security-sensitive reset and verification links.\n\nNote that the admin UI describes APPSMITH_BASE_URL as required for password reset and email verification links in:\n\n- `app/client/src/ce/pages/AdminSettings/config/configuration.tsx` at lines `41-49`\n\nThe reviewed self-host material indicates this protection is not fail-closed by default, which makes the vulnerable condition realistic on existing deployments where operators have not set `APPSMITH_BASE_URL`.\n\n\n### PoC\nThese steps were designed for validation on an Appsmith deployment that I own or am explicitly authorized to test.\n\n1. Deploy a non-production Appsmith instance from current `release`, or any build containing the affected code.\n2. Enable outbound email delivery.\n3. Leave `APPSMITH_BASE_URL` unset or blank.\n4. Use a test mailbox account you control, for example `victim@example.test`.\n5. Send a password reset request with a forged `Origin` header:\n\n```bash\ncurl -i -X POST \u0027https://YOUR-INSTANCE/api/v1/users/forgotPassword\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Origin: https://attacker.example\u0027 \\\n  --data \u0027{\"email\":\"victim@example.test\"}\u0027\n```\n\n6. Inspect the delivered email. If affected, the clickable reset link is generated under `https://attacker.example/...` instead of the legitimate Appsmith host.\n7. Repeat the same validation for resend email verification using an unverified test account:\n```bash\ncurl -i -X POST \u0027https://YOUR-INSTANCE/api/v1/users/resendEmailVerification\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Origin: https://attacker.example\u0027 \\\n  --data \u0027{\"email\":\"victim@example.test\"}\u0027\n```\n\n8. Inspect the delivered verification email. If affected, the clickable verification link is generated under `https://attacker.example/....`\n9. Set `APPSMITH_BASE_URL=https://YOUR-INSTANCE`, restart the server, and repeat the same requests.\n10. The expected secure behavior is that mismatched `Origin`  is rejected, or the generated links no longer follow the forged request header.\n\nLive tokens, third-party data, or unsafe exploitation material was not included in this report. The attached archive contains source excerpts, data-flow proof, safe validation notes, and supporting evidence collected from the reviewed current branch.\n\n### Impact\nThis is a trust-boundary failure in token-bearing email authentication flows.\n\nAffected deployments are those where:\n\n- `APPSMITH_BASE_URL` is unset or blank\n- outbound email is enabled\n- password reset and/or email verification flows are enabled\n\nAttacker requirements are low:\n\n- no prior authentication is required to reach the relevant endpoints\n- the attacker only needs to trigger an email flow toward a target account\n\nSecurity impact:\n\n- Appsmith can generate password reset or verification emails whose clickable host is attacker-controlled\n- victim interaction can expose security-sensitive token material\n- this can plausibly result in account takeover\n- at minimum, it enables trusted-email abuse and phishing through the application itself\n \n### mitigation\n1. Remove the fallback behavior in `resolveSecureBaseUrl(...)` that accepts caller-supplied origin data when `APPSMITH_BASE_URL` is unset.\n2. Fail closed for all token-bearing email flows when no trusted base URL is configured.\n3. Use a single trusted-base-url helper across:\n   - password reset\n   - resend email verification\n   - invite flows\n   - instance admin invite flows\n4. Add regression tests for the unset-configuration case.\n5. Add startup or admin-level validation so security-sensitive email flows cannot operate until a trusted base URL is configured.\n\n### Attachment\n[appsmith-email-link-origin-validation-bypass-20260321.zip](https://github.com/user-attachments/files/26153718/appsmith-email-link-origin-validation-bypass-20260321.zip)",
  "id": "GHSA-j9gf-vw2f-9hrw",
  "modified": "2026-06-12T18:28:52Z",
  "published": "2026-06-12T18:28:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/security/advisories/GHSA-j9gf-vw2f-9hrw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/appsmithorg/appsmith"
    },
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/releases/tag/v2.0"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Appsmith: Configuration-dependent origin validation bypass in password reset and email verification link generation"
}

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