CVE-2026-42346: Postiz AI Social Media Tool SSRF Vulnerability

CVE-2026-42346 Overview

CVE-2026-42346 is a Server-Side Request Forgery (SSRF) vulnerability in Postiz, an AI social media scheduling tool. The flaw affects versions 2.16.6 through 2.21.6 and stems from a Time-of-Check-Time-of-Use (TOCTOU) race condition in the SSRF protections introduced in v2.21.4 through v2.21.6. The isSafePublicHttpsUrl() function resolves DNS to validate the target IP, but subsequent fetch() calls perform independent DNS resolution. An attacker controlling an authoritative DNS server can exploit this gap through DNS rebinding to redirect requests to internal network addresses. The issue is patched in version 2.21.7.

Critical Impact

Attackers can bypass URL validation through DNS rebinding to access internal network services, potentially exposing sensitive metadata endpoints and intranet resources.

Affected Products

• Postiz versions 2.16.6 through 2.21.3 (no SSRF protections)
• Postiz versions 2.21.4 through 2.21.6 (incomplete SSRF protections)
• gitroomhq/postiz-app repository

Discovery Timeline

• 2026-05-08 - CVE-2026-42346 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42346

Vulnerability Analysis

The vulnerability combines two well-known issue classes: Server-Side Request Forgery [CWE-918] and a TOCTOU race condition. Postiz accepts user-supplied URLs for webhook and integration endpoints. To prevent SSRF, the application validates URLs through isSafePublicHttpsUrl(), which resolves the hostname and checks that the resulting IP address is a public, non-internal address.

The defect is that validation and use occur as two independent DNS lookups. After the validation check passes, the application calls fetch() or axios, which performs a second DNS resolution. An attacker who controls the authoritative DNS server for the supplied hostname can return a public IP during validation and an internal IP (such as 127.0.0.1, 169.254.169.254, or RFC1918 addresses) during the fetch call.

Root Cause

The root cause is the absence of a unified resolve-and-pin mechanism. The SSRF guard resolves DNS, validates the address, then discards the resolution result. The HTTP client subsequently re-resolves the hostname, creating the time-of-check-to-time-of-use window. With short TTL values controlled by the attacker, the two lookups can return different answers.

Attack Vector

Exploitation requires the attacker to host a DNS server returning rapidly changing responses for a hostname submitted to a vulnerable Postiz endpoint. The attack proceeds without authentication or user interaction across the network. Successful exploitation yields read access to internal HTTP services reachable from the Postiz backend.

// Patch excerpt: apps/backend/src/api/routes/public.controller.ts
 import { promisify } from 'util';
 import { OnlyURL } from '@gitroom/nestjs-libraries/dtos/webhooks/webhooks.dto';
 import { isSafePublicHttpsUrl } from '@gitroom/nestjs-libraries/dtos/webhooks/webhook.url.validator';
+import { ssrfSafeDispatcher } from '@gitroom/nestjs-libraries/dtos/webhooks/ssrf.safe.dispatcher';

 const pump = promisify(pipeline);

// Patch excerpt: apps/backend/src/public-api/routes/v1/public.integrations.controller.ts
-import axios from 'axios';
 import { Readable } from 'stream';
+import { ssrfSafeDispatcher } from '@gitroom/nestjs-libraries/dtos/webhooks/ssrf.safe.dispatcher';

Source: GitHub Commit 071143d

The fix replaces direct axios and fetch usage with a custom ssrfSafeDispatcher that performs DNS resolution once and pins the connection to the validated IP address.

Detection Methods for CVE-2026-42346

Indicators of Compromise

• Outbound DNS queries from the Postiz backend to attacker-controlled domains with abnormally short TTL values
• HTTP requests originating from the Postiz process targeting 127.0.0.1, 169.254.169.254, or RFC1918 address ranges
• Webhook or integration URL submissions referencing hostnames that resolve inconsistently across rapid queries

Detection Strategies

• Inspect application logs for repeated webhook validation attempts against the same hostname with differing destination IPs
• Correlate DNS resolver logs with backend HTTP egress to identify validation versus fetch resolution mismatches
• Monitor egress firewall logs for Postiz process connections to internal subnets or cloud metadata services

Monitoring Recommendations

• Enforce egress filtering at the network layer to block backend services from reaching internal IP ranges
• Alert on DNS responses with TTLs under 5 seconds for domains supplied through user input
• Track invocations of isSafePublicHttpsUrl() followed by outbound HTTP requests to verify IP consistency

How to Mitigate CVE-2026-42346

Immediate Actions Required

• Upgrade Postiz to version 2.21.7 or later, which introduces the ssrfSafeDispatcher to pin DNS resolution
• Audit webhook and integration configurations for suspicious external URLs added since version 2.16.6
• Restrict outbound network access from the Postiz backend to required third-party endpoints only

Patch Information

The fix is available in Postiz Release v2.21.7 and documented in GitHub Security Advisory GHSA-f7jj-p389-4w45. The patch commit replaces the unsafe HTTP clients with an SSRF-safe dispatcher that resolves DNS once and connects to the verified IP.

Workarounds

• Deploy Postiz behind an egress proxy that blocks requests to private, loopback, and link-local IP ranges
• Block access to cloud metadata endpoints such as 169.254.169.254 via host firewall rules
• Disable webhook and external URL features until the upgrade to 2.21.7 is applied

# Example iptables egress rules blocking internal targets from the Postiz container
iptables -A OUTPUT -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -d 169.254.0.0/16 -j REJECT