PinchTab up to 0.8.3 /tasks server-side request forgery

Summaryinfo

A vulnerability described as critical has been identified in PinchTab up to 0.8.3. The impacted element is an unknown function of the file /tasks. The manipulation results in server-side request forgery. This vulnerability was named CVE-2026-33619. The attack may be performed from remote. There is no available exploit. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability was found in PinchTab up to 0.8.3. It has been classified as critical. Affected is an unknown code block of the file /tasks. The manipulation with an unknown input leads to a server-side request forgery vulnerability. CWE is classifying the issue as CWE-918. The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. This is going to have an impact on confidentiality, integrity, and availability. CVE summarizes:

PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab v0.8.3 contains a server-side request forgery issue in the optional scheduler's webhook delivery path. When a task is submitted to `POST /tasks` with a user-controlled `callbackUrl`, the v0.8.3 scheduler sends an outbound HTTP `POST` to that URL when the task reaches a terminal state. In that release, the webhook path validated only the URL scheme and did not reject loopback, private, link-local, or other non-public destinations. Because the v0.8.3 implementation also used the default HTTP client behavior, redirects were followed and the destination was not pinned to validated IPs. This allowed blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets reachable from the server. This issue is narrower than a general unauthenticated internet-facing SSRF. The scheduler is optional and off by default, and in token-protected deployments the attacker must already be able to submit tasks using the server's master API token. In PinchTab's intended deployment model, that token represents administrative control rather than a low-privilege role. Tokenless deployments lower the barrier further, but that is a separate insecure configuration state rather than impact created by the webhook bug itself. PinchTab's default deployment model is local-first and user-controlled, with loopback bind and token-based access in the recommended setup. That lowers practical risk in default use, even though it does not remove the underlying webhook issue when the scheduler is enabled and reachable. This was addressed in v0.8.4 by validating callback targets before dispatch, rejecting non-public IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating `callbackUrl` during task submission.

The advisory is available at github.com. This vulnerability is traded as CVE-2026-33619 since 03/23/2026. The exploitability is told to be easy. It is possible to launch the attack remotely. Additional levels of successful authentication are necessary for exploitation. Technical details are known, but there is no available exploit.

Upgrading to version 0.8.4 eliminates this vulnerability. The upgrade is hosted for download at github.com. Applying the patch c824574c3a05073dec2f5e9c219e22ffff8de445 is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Productinfo

Name

• PinchTab

Version

• 0.8.0
• 0.8.1
• 0.8.2
• 0.8.3

License

• open-source

Website

• Product: https://github.com/pinchtab/pinchtab/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Discussion