CVE-2026-33619
Received Received - Intake
Server-Side Request Forgery in PinchTab Scheduler Webhook Delivery

Publication date: 2026-03-26

Last updated on: 2026-04-22

Assigner: GitHub, Inc.

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-26
Last Modified
2026-04-22
Generated
2026-05-07
AI Q&A
2026-03-27
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
pinchtab pinchtab to 0.8.4 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
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.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-33619 is a blind Server-Side Request Forgery (SSRF) vulnerability in PinchTab version 0.8.3, specifically in its optional Task Scheduler's webhook delivery mechanism.

When a task is submitted to the POST /tasks endpoint with a user-controlled callbackUrl, the scheduler sends an HTTP POST request to that URL when the task reaches a terminal state.

The vulnerability arises because the webhook dispatch logic only validated the URL scheme (http or https) but did not restrict or verify the destination IP address, allowing requests to loopback, private, link-local, or other non-public IP ranges.

Additionally, the HTTP client followed redirects automatically, enabling attackers to redirect requests to internal or restricted destinations.

Exploitation requires the scheduler to be enabled and the attacker to have the ability to submit tasks, which in token-protected deployments means possessing the master API token with administrative privileges.

This issue was fixed in version 0.8.4 by validating callback URLs during task submission, rejecting unsafe IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating callback URLs before dispatch.


How can this vulnerability impact me? :

This vulnerability allows an attacker to make the PinchTab server send HTTP(S) requests to arbitrary internal or external endpoints reachable from the server, which is known as blind SSRF.

Potential impacts include interaction with internal HTTP services or cloud metadata endpoints that are not directly accessible to the attacker.

There is no direct confidentiality impact since the webhook response body is not returned to the attacker.

However, there is a possible low-integrity impact if internal services accept unauthenticated POST requests and perform state-changing operations.

The practical risk is mitigated in default deployments due to local-first design, loopback binding, token-based access, and the scheduler being disabled by default.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

CVE-2026-33619 is a blind Server-Side Request Forgery (SSRF) vulnerability that allows an attacker with task submission privileges to induce the PinchTab server to send HTTP requests to arbitrary internal or external endpoints. While the vulnerability does not directly impact confidentiality since the webhook response body is not returned to the attacker, it may allow low-integrity impact if internal services accept unauthenticated POST requests and perform state-changing operations.

From a compliance perspective, this vulnerability could pose risks related to data integrity and system security controls required by standards such as GDPR and HIPAA. For example, unauthorized internal requests could potentially lead to unauthorized changes or interactions with internal services, which may violate principles of data integrity and access control mandated by these regulations.

However, the practical risk is mitigated in default deployments due to the local-first design, loopback binding, token-based access, and the scheduler being disabled by default. The vulnerability requires possession of a master API token or an insecure tokenless deployment to be exploited, which represents administrative-level access rather than a low-privilege attack.

Therefore, while the vulnerability itself does not directly disclose personal data or cause confidentiality breaches, organizations relying on PinchTab should consider the potential indirect effects on compliance by ensuring proper access controls, secure configurations, and timely patching to prevent exploitation that could undermine system integrity and security.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves the PinchTab scheduler sending HTTP POST requests to attacker-controlled callback URLs without proper validation. Detection can focus on monitoring outbound HTTP POST requests from the PinchTab server, especially those triggered by the scheduler to callback URLs that are unusual or internal IP addresses.

You can detect potential exploitation by capturing and analyzing network traffic for unexpected POST requests to internal or non-public IP ranges originating from the PinchTab server.

Suggested commands include using network monitoring tools such as tcpdump or Wireshark to filter outbound HTTP POST requests from the PinchTab server.

  • tcpdump -i <interface> -n -s 0 -A 'tcp dst port 80 and (((ip src <pinchtab_server_ip>) and (tcp[13] & 8 != 0))' # Capture outbound HTTP POST packets
  • tcpdump -i <interface> -n -s 0 -A 'tcp dst port 443 and (((ip src <pinchtab_server_ip>) and (tcp[13] & 8 != 0))' # Capture outbound HTTPS POST packets

Additionally, reviewing PinchTab task submissions via the POST /tasks endpoint for suspicious or unexpected callbackUrl parameters can help detect attempts to exploit this vulnerability.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include disabling the optional scheduler feature if it is not required, as it is off by default and the vulnerability exists only when the scheduler is enabled.

If the scheduler must be enabled, restrict access to the master API token to trusted administrators only, since possession of this token is required to submit tasks with malicious callback URLs.

Upgrade PinchTab to version 0.8.4 or later, where the vulnerability is fixed by validating callback URLs during task submission, rejecting non-public IP ranges, pinning delivery to validated IPs, and disabling redirect following.

Implement network-level controls such as firewall rules to block outbound HTTP(S) requests from the PinchTab server to internal or private IP ranges that should not be accessed.

Consider implementing an allowlist of approved webhook destinations to limit where callback URLs can point.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart