PinchTab Authentication and Injection Flaws

A command injection vulnerability (CVSS 6.7). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

PinchTab versions 0.8.3 through 0.8.5 contain a security-policy bypass that allows arbitrary JavaScript execution through the POST /wait endpoint's fn mode, even when the security.allowEvaluate setting is explicitly disabled. While the /evaluate endpoint correctly enforces the allowEvaluate guard, the /wait endpoint fails to apply the same policy check before evaluating caller-supplied JavaScript expressions, enabling authenticated users with an API token to execute arbitrary code in browser tab contexts despite the operator's intention to disable JavaScript evaluation. A proof-of-concept demonstrating this bypass has been published by the vendor, showing that side effects can be introduced in page state and confirmed through subsequent requests.

CVE-2026-33621 is a security vulnerability (CVSS 4.8). Remediation should follow standard vulnerability management procedures. Vendor patch is available.

PinchTab versions 0.7.8 through 0.8.3 accept API authentication tokens via URL query parameters (?token=...) in addition to the Authorization header, creating an unsafe credential transport pattern that exposes tokens through intermediary logs, browser history, shell history, and clipboard history. While this is not a direct authentication bypass-an attacker must obtain the token from a secondary source-the vulnerability is compounded by first-party dashboard setup flows that generate and consume tokenized URLs, increasing practical exposure likelihood. The issue was resolved in version 0.8.4 by removing query-string token authentication entirely and enforcing header-based authentication.

PinchTab v0.8.3 contains a server-side request forgery vulnerability in its optional webhook scheduler that allows authenticated attackers to trigger outbound HTTP POST requests to arbitrary destinations, including internal and non-public IP ranges. The vulnerability exists because the webhook delivery path validates only the URL scheme (http/https) without rejecting loopback, private, or link-local addresses, and the HTTP client follows redirects without re-validation. A proof-of-concept is publicly available demonstrating blind SSRF capability; however, practical exploitation requires either administrative API token access in token-protected deployments or a tokenless configuration, and the scheduler must be explicitly enabled (it is disabled by default).