CVE-2026-34590
Blind SSRF in Postiz Webhooks Creation Allows Internal Access
Publication date: 2026-04-02
Last updated on: 2026-04-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| gitroom | postiz | to 2.21.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-34590 is a Server-Side Request Forgery (SSRF) vulnerability in the Postiz social media scheduling tool versions prior to 2.21.4. The issue arises because the POST /webhooks/ endpoint, used to create webhooks, validates the webhook URL only by checking its format with @IsUrl(), but does not apply the @IsSafeWebhookUrl validator that blocks URLs pointing to internal or private network addresses.
This missing validation allows an attacker with low privileges to create a webhook with a URL pointing to internal services or metadata endpoints (such as cloud instance metadata services). When a post is published, the orchestrator blindly sends POST requests to the stored webhook URL without further runtime validation, enabling blind SSRF attacks against internal network resources.
The vulnerability was patched in version 2.21.4 by adding the @IsSafeWebhookUrl validator to the webhook creation endpoint, ensuring URLs must be public HTTPS addresses and cannot point to internal IP ranges or localhost.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability CVE-2026-34590 allows an attacker to perform Server-Side Request Forgery (SSRF) by creating webhooks with URLs pointing to internal or private network addresses. This can lead to unauthorized access to internal services, including cloud instance metadata that may expose sensitive credentials.
Such unauthorized access and potential exposure of sensitive information could impact compliance with standards and regulations like GDPR and HIPAA, which require protection of personal data and sensitive information from unauthorized access or disclosure.
However, the provided context does not explicitly mention compliance impacts or specific regulatory considerations.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing an attacker with authenticated access to create malicious webhooks that target internal network services, which are normally inaccessible from outside.
- Internal network scanning through timing analysis of webhook delivery attempts.
- Blind interaction with internal services, potentially manipulating unauthenticated internal APIs, caches, or message queues.
- Access to cloud instance metadata services (e.g., AWS, GCP, Azure) at 169.254.169.254, risking exposure of IAM credentials or instance configuration.
- Persistence of the SSRF primitive as the malicious webhook URL remains stored and triggered on every post publication until deleted.
Overall, this can lead to unauthorized internal network access, information disclosure, and potential manipulation of internal resources.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the creation of webhooks with URLs pointing to internal or private network addresses that bypass proper validation, enabling blind SSRF attacks when posts are published.
Detection can focus on identifying webhook URLs stored in the system that point to internal IP ranges or localhost addresses, especially those created via the POST /webhooks/ endpoint prior to version 2.21.4.
Suggested commands to detect potentially malicious webhook URLs include querying the webhook storage or database for URLs matching internal IP ranges or localhost, for example:
- Using grep or similar tools on exported webhook data or logs to find URLs containing private IP ranges such as 10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x, 127.x.x.x, or link-local addresses like 169.254.x.x.
- Example grep command: grep -E 'http://(10\.|127\.|169\.254\.|172\.(1[6-9]|2[0-9]|3[0-1])|192\.168\.)' webhooks_data.txt
- Monitoring network traffic for outbound POST requests to internal IP addresses triggered by the orchestrator when posts are published.
Since the orchestrator blindly sends POST requests to stored webhook URLs without runtime validation, network monitoring tools or packet capture utilities (e.g., tcpdump, Wireshark) can be used to detect unexpected internal network requests.
What immediate steps should I take to mitigate this vulnerability?
The primary immediate mitigation is to upgrade the postiz-app to version 2.21.4 or later, where the vulnerability has been patched by adding the @IsSafeWebhookUrl validator to the webhook creation endpoint.
Additional recommended steps include:
- Review and delete any existing webhook URLs that point to internal or private network addresses to prevent SSRF exploitation.
- Implement runtime URL validation in the sendWebhooks() function or equivalent orchestrator logic to block malicious URLs even if they bypass DTO validation or are injected directly into the database.
- Monitor network traffic for suspicious POST requests to internal IP addresses triggered by webhook executions.
These steps help prevent attackers from exploiting the SSRF vulnerability by ensuring webhook URLs are properly validated and malicious entries are removed.