CVE-2026-33621: PinchTab Auth Bypass Vulnerability

CVE-2026-33621 Overview

CVE-2026-33621 is an Authentication Bypass by Spoofing vulnerability (CWE-290) affecting PinchTab, a standalone HTTP server that provides AI agents with direct control over a Chrome browser. The vulnerability stems from incomplete request-throttling protections for authentication-checkable endpoints across multiple versions of the software.

In PinchTab versions v0.7.7 through v0.8.3, a fully implemented RateLimitMiddleware existed in internal/handlers/middleware.go but was never inserted into the production HTTP handler chain, effectively leaving all requests unthrottled. Additionally, the original limiter implementation keyed clients using the X-Forwarded-For header, which would have allowed attackers to spoof their IP address and bypass rate limiting even if the middleware had been enabled.

Version v0.8.4 partially addressed these issues by wiring the limiter into the live handler chain and switching the key to the immediate peer IP. However, it still exempted /health and /metrics endpoints from rate limiting, even though /health remained an auth-checkable endpoint when a token was configured.

Critical Impact

This vulnerability weakens defense-in-depth protections against brute-force attacks on authentication endpoints, particularly in deployments where an attacker can reach the API and weak human-chosen tokens are used.

Affected Products

• PinchTab versions v0.7.7 through v0.8.4
• HTTP servers with exposed authentication endpoints
• Deployments using non-default network exposure configurations

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-33621 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33621

Vulnerability Analysis

The vulnerability exists due to a fundamental disconnect between security implementation and deployment configuration. The RateLimitMiddleware was correctly implemented in the codebase but was never registered in the production HTTP handler chain, creating a false sense of security for operators who may have assumed rate limiting was active.

The secondary issue involves the trust model for client identification. By relying on the X-Forwarded-For header for client IP determination, the application trusted client-controlled data for security decisions. An attacker could trivially rotate through different IP addresses by manipulating this header, effectively nullifying any rate-limiting protections.

Even after initial remediation in v0.8.4, the /health endpoint exemption created an attack surface because this endpoint remained auth-checkable when a token was configured, allowing continued brute-force attempts against authentication.

Root Cause

The root cause is CWE-290: Authentication Bypass by Spoofing. The vulnerability manifests through two related implementation failures: (1) the rate limiting middleware was implemented but not integrated into the request processing pipeline, and (2) the client identification mechanism trusted the spoofable X-Forwarded-For header rather than the immediate peer connection IP.

Attack Vector

An attacker with network access to a PinchTab deployment could exploit this vulnerability to perform brute-force attacks against authentication endpoints without being subject to rate limiting. The attack vector is network-based with high complexity, as it requires the target deployment to be exposed beyond the default localhost configuration and ideally use a weak, human-chosen authentication token.

The attack flow would involve:

1. Identifying an exposed PinchTab instance
2. Targeting auth-checkable endpoints such as /health
3. Rotating X-Forwarded-For header values to bypass IP-based tracking
4. Performing unlimited authentication attempts without throttling

// Security patch in cmd/pinchtab/cmd_cli_clipboard.go - fix: dashboard security hardening (#363)
 var clipboardCmd = &cobra.Command{
 	Use:   "clipboard",
 	Short: "Clipboard operations",
-	Long:  "Read and write shared clipboard content.",
+	Long:  "Read and write the shared server clipboard.",
 }
 
 var clipboardReadCmd = &cobra.Command{

Source: GitHub Commit Changes

Detection Methods for CVE-2026-33621

Indicators of Compromise

• Unusually high request volumes to /health, /metrics, or authentication endpoints from single or rotating source IPs
• Multiple failed authentication attempts with varying X-Forwarded-For header values
• Access logs showing rapid successive requests without expected rate limiting delays
• Authentication failures followed by eventual successful authentication indicating credential guessing

Detection Strategies

• Monitor HTTP access logs for abnormal request patterns to auth-checkable endpoints
• Implement external WAF or reverse proxy rate limiting as a compensating control
• Alert on high volumes of 401/403 responses indicating authentication failures
• Review X-Forwarded-For header diversity in requests from single peer IPs

Monitoring Recommendations

• Deploy application-level logging to track authentication attempt frequency
• Implement network-level monitoring for connection patterns to PinchTab instances
• Establish baselines for normal API usage and alert on deviations
• Consider implementing external IP reputation services to identify malicious sources

How to Mitigate CVE-2026-33621

Immediate Actions Required

• Upgrade PinchTab to version v0.8.5 or later immediately
• Audit deployments to identify any PinchTab instances exposed beyond localhost
• Review authentication tokens and replace any weak human-chosen tokens with strong, randomly generated alternatives
• Implement network-level access controls to limit exposure of PinchTab instances

Patch Information

The vulnerability was fully addressed in PinchTab v0.8.5. The patch applies RateLimitMiddleware in the production handler chain, derives client addresses from the immediate peer IP instead of trusting forwarded headers by default, and removes the /health and /metrics exemption so all auth-checkable endpoints are properly throttled.

For detailed patch information, see the GitHub Security Advisory GHSA-j65m-hv65-r264 and the GitHub Commit Changes.

Workarounds

• Maintain PinchTab in its default local-first configuration binding to 127.0.0.1
• Deploy a reverse proxy with rate limiting in front of PinchTab instances that require network exposure
• Use strong, randomly generated authentication tokens rather than human-chosen passwords
• Implement network segmentation to restrict access to PinchTab instances

# Configuration example - Restrict PinchTab to localhost binding
# In your PinchTab configuration or startup script:
export PINCHTAB_BIND_ADDRESS="127.0.0.1"
export PINCHTAB_TOKEN="$(openssl rand -hex 32)"

# If network exposure is required, deploy behind a rate-limiting reverse proxy
# Example nginx rate limiting configuration:
# limit_req_zone $binary_remote_addr zone=pinchtab:10m rate=10r/s;
# location / {
#     limit_req zone=pinchtab burst=20 nodelay;
#     proxy_pass http://127.0.0.1:8080;
# }