CVE-2026-33619
Server-Side Request Forgery in PinchTab Scheduler Webhook Delivery
Publication date: 2026-03-26
Last updated on: 2026-04-22
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| pinchtab | pinchtab | to 0.8.4 (exc) |
Helpful Resources
Exploitability
| 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.