CVE-2026-34590: Postiz Webhook SSRF Vulnerability

CVE-2026-34590 Overview

CVE-2026-34590 is a Server-Side Request Forgery (SSRF) vulnerability identified in Postiz, an AI-powered social media scheduling tool. The flaw exists in the POST /webhooks/ endpoint responsible for creating webhooks. While the endpoint validates the url field using @IsUrl() for format checking, it fails to apply the @IsSafeWebhookUrl validator that blocks internal and private network addresses. This inconsistency allows authenticated attackers to register webhook URLs pointing to internal services.

Critical Impact

Authenticated users can exploit this blind SSRF vulnerability to probe internal network services, potentially accessing sensitive data or pivoting to other internal systems when posts are published.

Affected Products

• Postiz versions prior to 2.21.4
• Postiz webhook functionality (POST /webhooks/ endpoint)
• Self-hosted Postiz deployments with internal network exposure

Discovery Timeline

• April 2, 2026 - CVE-2026-34590 published to NVD
• April 2, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34590

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The root issue stems from an inconsistent application of security validators across the webhook API endpoints. While the update (PUT /webhooks/) and test (POST /webhooks/send) endpoints correctly implement the @IsSafeWebhookUrl validator to prevent internal network access, the create endpoint (POST /webhooks/) only performs basic URL format validation. When a user publishes a post, the orchestrator component fetches the stored webhook URL without performing runtime validation, enabling blind SSRF attacks against internal services that would otherwise be inaccessible from external networks.

Root Cause

The vulnerability originates from missing input validation in the WebhooksDto class used by the webhook creation endpoint. The url field was decorated only with @IsUrl() for format validation and @IsDefined() for presence checking, but lacked the critical @IsSafeWebhookUrl decorator that validates whether the target URL resolves to a public, non-internal IP address. This oversight creates an attack vector where malicious webhook URLs can be stored and later executed by the server-side orchestrator component.

Attack Vector

The attack exploits the network-accessible webhook creation endpoint. An authenticated attacker with low privileges can craft a malicious webhook pointing to internal network resources such as http://169.254.169.254/ (cloud metadata services), http://localhost:8080/, or private IP ranges. When posts are published through Postiz, the application's orchestrator blindly fetches these URLs, allowing the attacker to:

1. Scan internal network ports and services
2. Access cloud provider metadata endpoints
3. Interact with internal APIs not exposed to the internet
4. Potentially exfiltrate sensitive configuration data

   @IsString()
   @IsUrl()
   @IsDefined()
+  @IsSafeWebhookUrl({
+    message:
+      'Webhook URL must be a public HTTPS URL and cannot point to internal network addresses',
+  })
   url: string;
 
   @Type(() => WebhooksIntegrationDto)

Source: GitHub Commit

Detection Methods for CVE-2026-34590

Indicators of Compromise

• Webhook configurations containing internal IP addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x, 127.0.0.1)
• Webhook URLs targeting cloud metadata endpoints (e.g., 169.254.169.254, metadata.google.internal)
• Unusual outbound HTTP requests from the Postiz server to internal network segments
• Webhook creation requests with localhost or link-local addresses in the URL field

Detection Strategies

• Monitor POST /webhooks/ API requests for URL parameters containing private IP ranges or localhost references
• Implement network-level monitoring to detect outbound connections from the Postiz application server to internal network segments
• Review existing webhook configurations in the database for URLs pointing to non-public addresses
• Enable verbose logging on the orchestrator component to track webhook callback destinations

Monitoring Recommendations

• Configure network segmentation alerts for any traffic from the Postiz server to internal management interfaces
• Set up application-level logging to capture all webhook CRUD operations with full URL details
• Implement egress filtering rules to block the Postiz server from accessing internal network ranges
• Monitor for repeated failed webhook callbacks that may indicate reconnaissance activity

How to Mitigate CVE-2026-34590

Immediate Actions Required

• Upgrade Postiz to version 2.21.4 or later immediately
• Audit existing webhook configurations for URLs pointing to internal or private network addresses
• Implement network egress controls to restrict outbound connections from the Postiz server
• Review application logs for evidence of exploitation attempts targeting internal services

Patch Information

The vulnerability has been patched in Postiz version 2.21.4. The fix adds the @IsSafeWebhookUrl validator to the webhook creation endpoint's DTO class, ensuring consistent validation across all webhook-related API endpoints. The patch can be verified via the GitHub commit 5ae4c95 and is included in release v2.21.4. For additional details, refer to the GitHub Security Advisory GHSA-wc9c-7cv8-m225.

Workarounds

• Implement a Web Application Firewall (WAF) rule to inspect and block webhook creation requests containing internal IP addresses
• Configure network-level egress filtering to prevent the Postiz server from making connections to private IP ranges
• Temporarily disable webhook creation functionality via API gateway rules until the patch can be applied
• Deploy the Postiz application in an isolated network segment with strictly controlled outbound access

# Example iptables rules to block outbound connections to private networks
# Apply on the Postiz server host

# Block connections to private IPv4 ranges
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

# Allow established connections for normal operation
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT