Description
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.
Published: 2026-03-26
Score: 4.1 Medium
EPSS: n/a
KEV: No
Impact: Unauthenticated Blind SSRF
Action: Update
AI Analysis

Impact

The vulnerability is a blind Server‑Side Request Forgery in PinchTab’s optional scheduler. When a task is posted to /tasks with a user‑controlled callbackUrl, the v0.8.3 scheduler performs an outbound POST to that URL. The implementation validates only the URL scheme, accepting loopback, private, and link‑local addresses and following redirects, which permits the server to reach any HTTP(S) target reachable from the host. This flaw is limited to the webhook path and does not affect general request handling, but it allows an attacker to exfiltrate data or manipulate internal services via blind SSRF.

Affected Systems

The affected product is PinchTab v0.8.3. The flaw appears only when the optional scheduler is enabled and reachable. Users running versions prior to v0.8.4 with the scheduler active are susceptible; the issue is mitigated by installing v0.8.4 or later, which validates callback URLs, rejects non‑public IP ranges, disables redirect following, and pins delivery to approved IPs.

Risk and Exploitability

The CVSS score is 4.1, indicating low to moderate severity. No EPSS score is available, and the vulnerability is not listed in CISA’s KEV catalog. Exploitation requires ability to submit tasks via the master API token or a tokenless deployment, which typically requires administrative or unauthenticated access. If the scheduler is exposed to the internet, an attacker can target internal hosts; if it is only exposed locally, the risk is lower but still present. The likely attack vector is through an unauthenticated or privileged POST /tasks request, making the vulnerability practical in permissive configurations.

Generated by OpenCVE AI on March 26, 2026 at 22:25 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade PinchTab to version 0.8.4 or later, which implements proper callbackUrl validation and removes redirect following.
  • If upgrading immediately is not possible, disable the optional scheduler or remove the webhook delivery endpoint so the blind SSRF path is disabled.
  • Configure the server to bind only to loopback addresses (127.0.0.1) or a restricted network interface to limit outward connectivity.
  • Enforce authentication for all API endpoints, ensuring that only authorized users can submit tasks and that the master API token is protected.

Generated by OpenCVE AI on March 26, 2026 at 22:25 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Github GHSA Github GHSA GHSA-xqq2-4j46-vwp7 PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl
History

Fri, 27 Mar 2026 08:45:00 +0000

Type Values Removed Values Added
First Time appeared Pinchtab
Pinchtab pinchtab
Vendors & Products Pinchtab
Pinchtab pinchtab

Thu, 26 Mar 2026 21:00:00 +0000

Type Values Removed Values Added
Description 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.
Title PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl
Weaknesses CWE-918
References
Metrics cvssV3_1

{'score': 4.1, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N'}


Subscriptions

Pinchtab Pinchtab
cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-03-26T20:34:01.661Z

Reserved: 2026-03-23T14:24:11.616Z

Link: CVE-2026-33619

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-03-26T21:17:06.220

Modified: 2026-03-26T21:17:06.220

Link: CVE-2026-33619

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-03-27T09:23:30Z

Weaknesses