CVE-2026-33620: Pinchtab Information Disclosure Flaw

CVE-2026-33620 Overview

CVE-2026-33620 affects PinchTab, a standalone HTTP server that gives AI agents direct control over a Chrome browser. Versions v0.7.8 through v0.8.3 accepted the API token through a token URL query parameter as an alternative to the Authorization header. This pattern exposes valid credentials through any system that records request URIs, including reverse proxy access logs, browser history, shell history, clipboard managers, and tracing systems. The issue is an unsafe credential transport pattern rather than a direct authentication bypass. The flaw is classified under [CWE-598: Use of GET Request Method With Sensitive Query Strings]. Maintainers addressed the issue in v0.8.4 by removing query-string token authentication.

Critical Impact
API tokens transmitted via URL query parameters can leak to intermediaries and client-side tooling, enabling unauthorized control of the PinchTab-managed Chrome browser by anyone who recovers the logged URL.

Affected Products

PinchTab v0.7.8 through v0.8.3
Deployments where an API token is configured
Clients that invoke PinchTab endpoints using the ?token= query parameter form

Discovery Timeline

2026-03-26 - CVE-2026-33620 published to NVD
2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-33620

Vulnerability Analysis

PinchTab exposes an HTTP API that lets AI agents drive a Chrome browser session. Authenticated requests are expected to carry the API token in an Authorization: Bearer <token> header. In affected versions, the server also accepted the same credential when supplied as a token URL query parameter. Query strings are routinely captured by infrastructure that has no expectation of handling secrets. Reverse proxy logs, web server access logs, browser address bar history, shell command history from curl invocations, clipboard managers, and distributed tracing platforms can all retain the full request URI. Any actor with read access to those records recovers a working credential. PinchTab's own first-party flows in v0.8.3 generated and consumed URLs that embedded the token, increasing the surface for accidental disclosure even when operators followed documented header-based guidance.

Root Cause

The root cause is the acceptance of a security-sensitive value through a transport channel known to be logged and cached. The authentication middleware checked both the Authorization header and the token query parameter, treating either as equivalent proof of identity. This violates the principle that credentials should travel only through channels designed to resist incidental capture.

Attack Vector

Exploitation requires user interaction, in the form of a client or first-party flow that produces a request URL containing the token. An attacker with read access to any system that records those URLs, such as proxy logs, SIEM URI fields, or browser history on a shared workstation, can extract the token. The recovered credential grants the same browser-control capabilities as a legitimate AI agent client. No verified public proof-of-concept code is published for this issue. See the GitHub Security Advisory GHSA-mrqc-3276-74f8 for vendor technical details.

Detection Methods for CVE-2026-33620

Indicators of Compromise

Access log entries containing ?token= or &token= parameters directed at PinchTab endpoints.
Browser history or clipboard artifacts referencing PinchTab URLs with embedded token values.
Distributed tracing spans that include full request URIs for PinchTab API calls.
Requests to PinchTab from source IPs or user agents that do not match approved AI agent clients.

Detection Strategies

Grep historical reverse proxy and web server logs for the token= query parameter on PinchTab routes and treat any hits as exposed credentials.
Inspect installed PinchTab versions against the affected range v0.7.8 to v0.8.3 and flag deployments still accepting query-string authentication.
Audit AI agent client code and integration scripts for URL construction that appends the API token to the query string.

Monitoring Recommendations

Alert on any new PinchTab request that carries authentication material in the URI rather than the Authorization header.
Monitor SIEM ingestion pipelines for stored URLs containing token-shaped values and quarantine affected log segments.
Track PinchTab process startup and configuration changes to confirm upgraded versions are running across all hosts.

How to Mitigate CVE-2026-33620

Immediate Actions Required

Upgrade PinchTab to v0.8.4 or later, which removes query-string token authentication entirely.
Rotate any API token that was configured on an affected version, since prior URLs may already be in logs.
Purge or restrict access to log stores, browser histories, and clipboard caches that may contain prior PinchTab request URIs.
Update client integrations to send credentials only through Authorization: Bearer <token> or supported session-based flows.

Patch Information

The fix is delivered in PinchTab v0.8.4. The release removes the ?token= query-parameter authentication path and requires header- or session-based authentication. Release notes are published in the PinchTab v0.8.4 GitHub Release. Vendor remediation details are available in the PinchTab Security Advisory GHSA-mrqc-3276-74f8.

Workarounds

If immediate upgrade is not possible, configure clients to send the token exclusively in the Authorization header and avoid the query-parameter form.
Place PinchTab behind a reverse proxy that strips the token query parameter from inbound requests and rejects requests that rely on it.
Disable or restrict access logging of full URIs on systems handling PinchTab traffic until the upgrade is complete.

bash

# Configuration example
# Example NGINX snippet that rejects requests using the ?token= query parameter
location /pinchtab/ {
    if ($arg_token) {
        return 400;
    }
    proxy_set_header Authorization $http_authorization;
    proxy_pass http://pinchtab_backend;
}