Postiz CVE-2026-42346

The attacker must control an authoritative DNS server for the domain submitted to Postiz, with the ability to set TTL to 0 and swap the A record between Postiz's two DNS queries (validation query and fetch query) - typically a window of milliseconds to low seconds depending on resolver caching behavior. This DNS rebinding prerequisite is the primary limiting factor and explains SSVC's 'Automatable: no' rating. The vulnerable code paths accept user-supplied URLs at unauthenticated or low-privilege endpoints (CVSS PR:N), so no credential theft or account compromise is a prerequisite for the attacker. Exploitation impact is bounded by what internal services are reachable from the Postiz backend: environments where the backend cannot egress to RFC 1918 or link-local addresses (e.g., strict egress firewall, no cloud metadata service) have near-zero practical impact. Versions prior to 2.16.6 are not confirmed affected by the advisory; versions 2.21.7 and later are not vulnerable.

The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) correctly captures the two competing signals: fully network-accessible without authentication (AV:N/PR:N/UI:N) but requiring attacker-controlled DNS infrastructure and precise timing (AC:H). EPSS at 0.03% (8th percentile) and SSVC's 'Exploitation: none / Automatable: no' are mutually consistent - the DNS rebinding prerequisite prevents reliable at-scale automation. The High confidentiality impact is not overstated: successful exploitation can yield cloud instance metadata (e.g., AWS IMDSv1 at 169.254.169.254), IAM credentials, or internal service responses. The 'Scope: Unchanged' in CVSS 3.1 is debatable given that the attack ultimately targets systems beyond Postiz itself; CVSS 4.0 modeling (see assessed vector) treats internal service impact under subsequent-system metrics. No conflicting signals exist between CVSS, EPSS, and SSVC - all converge on a medium-priority finding requiring elevated attacker capability. Organizations running Postiz in cloud environments where the backend can reach instance metadata services should treat this as higher priority than the base score suggests.

An attacker registers a domain with a TTL-0 A record pointing to a legitimate public IP and submits this URL to a Postiz endpoint that accepts user-supplied URLs (e.g., the image-fetch or public integrations route). When Postiz calls isSafePublicHttpsUrl(), the attacker's DNS server returns the public IP, passing validation; the attacker then immediately swaps the DNS record to 169.254.169.254 (AWS instance metadata). Postiz's subsequent fetch() call resolves the same domain again, now reaching the metadata service, and the response - potentially containing IAM role credentials - is returned to or processed by the attacker-controlled request. No public proof-of-concept exploit has been identified at time of analysis.