Skip to content
Fencer Vulns
medium 4.1

CVE-2026-33619 json

PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl

published 2026-03-24 7 mo ago modified 2026-06-17 4 mo ago also EUVD-2026-16400 , GHSA-xqq2-4j46-vwp7 , GO-2026-4825

cvss
4.1
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.3%
EPSS 0.3% chance of exploitation in 30 days, percentile 17%
public exploits
0
none known

Summary

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.

Patch / fix

  • go github.com/pinchtab/pinchtab 0.8.4
  • pinchtab pinchtab 0.8.4
  • govulncheck-vulndb openSUSE Leap 15.6 0.0.20260326T203309-150000.1.155.2

suse advisories SUSE-SU-2026:1135-1

  • govulncheck-vulndb openSUSE Leap 16.0 0.0.20260723T184607-160000.1.1

opensuse advisories openSUSE-SU-2026:21483-1

CISA SSVC

Exploitation
Proof of concept is public
Automatable
no
Technical impact
partial
Assessed
7 mo ago

Exploit prediction

0.26% chance of exploitation in the next 30 days, higher than 17% of all scored CVEs (FIRST EPSS, 2026-11-08).

Exploits and checks

  • github.com https://github.com/pinchtab/pinchtab/security/advisories/GHSA-xqq2-4j46-vwp7 referenced PoC, tagged "exploit" by a source, unverified

CVSS scores

assigned by version score vector
CNA 3.1 4.1 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N
GitHub 3.1 4.1 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N
NVD 3.1 5.5 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N

Affected packages

ecosystem package affected fixed in
go github.com/pinchtab/pinchtab
<0.8.4
0.8.4

Affected products

  • pinchtab pinchtab

Classification

Weakness
  • CWE-918 Server-Side Request Forgery

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.