Skip to content

SSRF via Webhook Creation Endpoint Missing URL Safety Validation

Moderate
egelhaus published GHSA-wc9c-7cv8-m225 Mar 29, 2026

Software

gitroomhq/postiz-app

Affected versions

>= 0

Patched versions

>= 2.21.4

Description

Description

The POST /webhooks/ endpoint for creating webhooks uses WebhooksDto which validates the url field with only @IsUrl() (format check), missing the @IsSafeWebhookUrl validator that blocks internal/private network addresses. The update (PUT /webhooks/) and test (POST /webhooks/send) endpoints correctly apply @IsSafeWebhookUrl. When a post is published, the orchestrator fetches the stored webhook URL without runtime validation, enabling blind SSRF against internal services.

Timeline

  • 2026-03-28 13:05 UTC - Postiz received the advisory.
  • 2026-03-29 15:55 UTC - Postiz acknowledged and verified the advisory.
  • 2026-03-29 16:00 UTC - Postiz developed the fix, verified it, created the release and published the advisory.
  • 2026-03-30 18:44 UTC - GitHub issued CVE-2026-34590 for this advisory.

Mitigations

  • Upgrade to v2.21.4 or later.

Known exploits

  • Access to internal network / ressources.

Impact

  • Impacts could include:
  • Internal network scanning: An attacker can probe internal hosts and ports via timing differences in webhook delivery. Even though responses are not returned, reachability can be inferred.
  • Blind interaction with internal services: The SSRF sends POST requests with attacker-influenced body content (serialized post data) to internal services. Services without authentication (e.g., internal APIs, caches, message queues) could be manipulated.
  • Cloud metadata access: On cloud deployments (AWS, GCP, Azure), the instance metadata service at 169.254.169.254 may be reachable, potentially exposing IAM credentials or instance configuration. While the response is not reflected to the attacker, the POST request itself reaches the metadata service.
  • Persistence: The malicious webhook URL is stored in the database and triggered on every post publication until deleted, creating a persistent SSRF primitive.

References

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

CVE ID

CVE-2026-34590

Weaknesses

Server-Side Request Forgery (SSRF)

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. Learn more on MITRE.

Credits