CVE-2026-33620: 
vulnerability analysis and mitigation

CVE-2026-33620 is a credential disclosure vulnerability in PinchTab (a Go-based application) where API bearer tokens are exposed through unsafe URL query parameter transport. Affecting versions 0.7.8 through 0.8.3, the flaw allows tokens passed via the ?token= query parameter to be captured by reverse proxies, browser history, shell history, clipboard history, or tracing systems that record full request URIs. The vulnerability was published on March 22, 2026, by maintainer luigi-agosti and reported by researcher mean3374, with NVD publication on March 26, 2026. It carries a CVSS v3.1 base score of 4.3 (Medium) (GitHub Advisory, PinchTab Advisory).

The root cause is classified as CWE-598 (Use of GET Request Method With Sensitive Query Strings). In internal/handlers/middleware.go (v0.7.8–v0.8.3), the authentication middleware accepted credentials from both the Authorization header and the ?token= URL query parameter — if no Authorization header was present, the middleware fell back to the query string token and compared it against the configured secret using subtle.ConstantTimeCompare. Compounding the issue, the v0.8.3 setup wizard (cmd/pinchtab/cmd_wizard.go) actively generated dashboard URLs containing the live token in the query string, and the frontend (dashboard/src/App.tsx) consumed those URLs for one-click login before attempting to scrub the token from the address bar — materially increasing the likelihood of exposure. Exploitation requires an attacker to access a secondary source (proxy logs, browser history, shell history, etc.) that captured the full request URI containing the token (GitHub Advisory, PinchTab Advisory).

Successful exploitation results in the disclosure of a valid API token, allowing an attacker who obtains it from a secondary source to authenticate to the PinchTab instance as the legitimate token holder. The confidentiality impact is limited to the token itself and whatever API access it grants; there is no direct integrity or availability impact. Deployments using only Authorization: Bearer <token> header-based authentication are not affected, and this vulnerability does not constitute a direct authentication bypass (GitHub Advisory).

A proof-of-concept is publicly available in the official security advisory, demonstrating token authentication via curl -i "http://localhost:9867/health?token=supersecrettoken" against a running PinchTab instance. As of the time of reporting, there is no evidence of active in-the-wild exploitation. The EPSS score is approximately 0.042%–0.091% (26th percentile), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and no threat actor attribution has been reported (PinchTab Advisory, GitHub Advisory).

1. Identify a vulnerable deployment: Locate a PinchTab instance running versions 0.7.8–0.8.3 that has token-based authentication configured and is accessible (locally or via network).
2. Confirm authentication is enforced: Send an unauthenticated request to confirm a 401 response: curl -i http://<target>:9867/health — expect HTTP/1.1 401 Unauthorized.
3. Obtain a leaked token: Access a secondary source that recorded full request URIs from the target system — such as reverse proxy access logs (e.g., nginx access.log), browser history, shell history (~/.bash_history or ~/.zsh_history), clipboard history, or tracing/monitoring system logs — and extract the token value from entries like GET /health?token=<token_value> HTTP/1.1.
4. Authenticate using the captured token: Use the extracted token in a query-parameter request: curl -i "http://<target>:9867/health?token=<captured_token>" — expect HTTP/1.1 200 OK, confirming successful authentication.
5. Access protected resources: Use the valid token to interact with other protected PinchTab API endpoints, impersonating the legitimate user (PinchTab Advisory).

• Network: HTTP requests to PinchTab endpoints (e.g., /health, /dashboard) containing ?token= in the query string, particularly from unexpected source IPs or user agents.
• Logs: Reverse proxy or load balancer access logs (nginx, HAProxy, Caddy, etc.) containing entries such as GET /health?token=<value> HTTP/1.1; tracing or APM system records capturing full request URIs with token query parameters.
• File System / Shell History: Entries in ~/.bash_history, ~/.zsh_history, or equivalent files containing curl commands with ?token= query parameters targeting the PinchTab instance.
• Browser History / Bookmarks: Browser history or bookmark entries containing PinchTab dashboard URLs with ?token= query parameters, potentially left by the v0.8.3 setup wizard flow (PinchTab Advisory).

Upgrade PinchTab to version 0.8.4 or later, which removes query-string token authentication entirely and requires header- or session-based authentication flows (v0.8.4 Release). For environments unable to patch immediately, disable or block requests containing the ?token= query parameter at the reverse proxy or WAF layer, and enforce exclusive use of Authorization: Bearer <token> headers. Additionally, rotate any API tokens that may have been transmitted via URL query parameters, and audit proxy logs, browser history, and shell history for evidence of prior token exposure (GitHub Advisory).

The vulnerability was reported by researcher mean3374 and published by PinchTab maintainer luigi-agosti on March 22, 2026, with a detailed advisory including code-level evidence and a PoC. A security blog post was published at infinitsec.net covering the token exposure issue. No significant broader media coverage or notable community controversy has been identified beyond standard vulnerability database indexing (GitHub Advisory).