CVE-2026-33621: 
vulnerability analysis and mitigation

CVE-2026-33621 is a missing/incomplete rate-limiting vulnerability in PinchTab, a standalone HTTP server that gives AI agents direct control over a Chrome browser. It affects PinchTab versions v0.7.7 through v0.8.4 and was published on March 26, 2026. The flaw allows unauthenticated attackers to perform unbounded brute-force attempts against the API authentication token, particularly via the /health endpoint. The NVD assigns a CVSS v3.1 base score of 6.5 (Medium), while the GitHub Security Advisory rates it 4.8 (Moderate) with higher attack complexity (GitHub Advisory).

The vulnerability encompasses three related weaknesses classified as CWE-290 (Authentication Bypass by Spoofing) and CWE-770 (Allocation of Resources Without Limits or Throttling). In v0.7.7–v0.8.3, a fully implemented RateLimitMiddleware existed in internal/handlers/middleware.go but was never inserted into the production HTTP handler chain, leaving all endpoints completely unthrottled. Additionally, the original limiter keyed clients by the X-Forwarded-For header without validating that the request came from a trusted proxy, meaning an attacker could spoof their IP to bypass any per-IP throttle. Version v0.8.4 wired the limiter into the handler chain and switched to the immediate peer IP, but explicitly exempted /health and /metrics from rate limiting even though /health remained an auth-checkable endpoint when a token was configured (GitHub Advisory).

Successful exploitation allows an unauthenticated network attacker to perform high-speed brute-force guessing of the PinchTab API authentication token — the PoC demonstrates 180 requests/second with no HTTP 429 responses. If a weak or human-chosen token is in use, an attacker who discovers it gains full control over the Chrome browser instance managed by PinchTab, enabling arbitrary browser actions, data exfiltration from browser sessions, and potential lateral movement within the user's local environment. Deployments using the default local-first posture with a generated high-entropy token have substantially lower practical risk, but intentionally exposed or misconfigured deployments face meaningful exposure (GitHub Advisory).

A proof-of-concept Python script is publicly available in the GitHub Security Advisory, demonstrating token brute-forcing against the /health endpoint by sending HTTP requests with crafted Authorization: Bearer headers — the PoC achieved 151 attempts in 0.84 seconds with no rate-limit responses. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is 0.000410 (approximately 0.04%), indicating low probability of near-term exploitation. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory).

1. Reconnaissance: Identify a reachable PinchTab instance (default port 9867). In the default local-first configuration this is 127.0.0.1:9867; in exposed deployments, scan for the port externally.
2. Confirm target version: Check response headers or error messages to infer the PinchTab version is v0.7.7–v0.8.4.
3. Probe the /health endpoint: Send an unauthenticated GET /health request to confirm the endpoint is auth-checkable (returns HTTP 401 without a valid token).
4. Build a token wordlist: Prepare a list of candidate tokens (common passwords, short strings, or tokens derived from known patterns if the operator used a human-chosen value).
5. Execute brute-force: Run the PoC script (or equivalent) that iterates through the wordlist, sending GET http://<target>:9867/health with Authorization: Bearer <candidate> for each token. In v0.7.7–v0.8.3, no rate limiting is active at all; in v0.8.4, the /health exemption means no HTTP 429 is returned.
6. Identify valid token: A HTTP 200 response indicates the correct token has been found.
7. Authenticate and control Chrome: Use the discovered token in subsequent API calls to issue commands to the Chrome browser instance, enabling arbitrary browsing actions, data access, or further exploitation (GitHub Advisory).

• Network: High-volume HTTP requests to GET /health (or /metrics) on port 9867 from a single IP in a short time window; requests with sequential or dictionary-pattern Authorization: Bearer header values; absence of HTTP 429 responses in server logs during rapid request bursts.
• Logs: PinchTab access logs showing hundreds of 401 responses to /health followed by a single 200 response from the same source IP; unusual access patterns outside normal agent activity hours.
• Process/Behavior: Unexpected browser actions (new tabs, navigation, form submissions) initiated via the PinchTab API following a period of authentication probing; Chrome performing actions not initiated by the legitimate user or configured AI agent (GitHub Advisory).

Upgrade PinchTab to version v0.8.5 or later, which fully addresses all three issues: RateLimitMiddleware is wired into the production handler chain, the rate-limit key is derived from the immediate peer IP (not X-Forwarded-For), and the /health and /metrics exemptions are removed so auth-checkable endpoints are throttled. As an interim measure, restrict network access to the PinchTab API to trusted networks or localhost only, and ensure the API token is a randomly generated high-entropy value rather than a human-chosen password. Consider adding network-level rate limiting (e.g., via a WAF or reverse proxy) in front of any externally exposed PinchTab instance (GitHub Advisory, GitHub Commit).

The vulnerability was reported by researcher mean3374 and published by PinchTab maintainer luigi-agosti via GitHub Security Advisory on March 22, 2026. A technical write-up was published at infinitsec.net covering the unapplied rate-limiting middleware. No significant broader media coverage or notable social media discussion has been identified beyond the advisory and vulnerability database entries (GitHub Advisory).