CVE-2026-71250 in Firefly III
Summary
by MITRE • 08/05/2026
Firefly III's webhook URL validator (IsValidWebhookUrl.php) filters most private/reserved IPv4 ranges but contains an explicit early-return that allows any resolved address in 127.0.0.0/8, permitting an authenticated user (with webhooks enabled, which is off by default) to configure a webhook targeting loopback services on the server. Additionally, the validator resolves the target hostname once via gethostbyname() at validation time, but the actual outbound request (StandardWebhookSender.php, via Guzzle) re-resolves the hostname independently at send time, allowing a DNS-rebinding attacker to pass validation against a public IP and have the real request delivered to a private or internal address. The webhook response body is only written to a server-side debug log, not returned to the triggering user, so this is a blind SSRF primitive rather than one with direct response read-back.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability in Firefly III's webhook functionality represents a sophisticated server-side request forgery (SSRF) flaw that exploits a combination of network validation bypasses and DNS rebinding techniques. This issue resides within the IsValidWebhookUrl.php validator component which is designed to prevent webhooks from targeting private or reserved IP address ranges, yet contains a critical logical flaw in its implementation. The validator correctly filters most private/reserved IPv4 ranges but includes an explicit early-return mechanism that unconditionally permits any resolved address within the 127.0.0.0/8 range, effectively creating a backdoor for loopback address access regardless of the original URL structure.
The operational impact of this vulnerability is significant as it requires only authenticated access to the Firefly III application with webhooks functionality enabled, which remains disabled by default. This means that an attacker who has gained access to a valid user account can configure malicious webhook endpoints that will be processed by the application's backend infrastructure. The flaw specifically targets the StandardWebhookSender.php component that utilizes Guzzle for outbound HTTP requests, creating a race condition between validation and actual execution phases. During validation, gethostbyname() resolves hostnames once and caches this information, but the actual HTTP request processing performs independent DNS resolution at send time, enabling attackers to exploit this timing gap.
This vulnerability manifests as a blind SSRF primitive where the attacker cannot directly observe responses from internal services but can still leverage the application's network access to probe internal systems. The security implications extend beyond simple information disclosure as the attacker could potentially map internal network topology, identify running services, or even exploit vulnerabilities in internal applications that are not exposed to the public internet. The fact that webhook response bodies are only written to server-side debug logs rather than being returned to users means that the attack is blind but still potentially dangerous for reconnaissance purposes.
The technical implementation issues align with CWE-918 (Server-Side Request Forgery) and represent a specific variant of DNS rebinding exploitation patterns found in ATT&CK technique T1133 (External Remote Services). The vulnerability demonstrates poor input validation practices where the system assumes that hostname resolution at validation time will remain consistent during execution, failing to account for dynamic DNS changes or malicious manipulation of DNS records. Security controls that rely on single-point validation without considering network behavior consistency create dangerous attack vectors where legitimate security measures become ineffective due to implementation gaps.
Mitigation strategies should focus on implementing strict hostname validation that accounts for potential DNS rebinding attacks by either disabling hostname resolution during validation and requiring IP address-based configuration, or by performing consistent DNS resolution throughout the entire request lifecycle. Organizations should also implement network segmentation and outbound traffic filtering to limit what internal services can be accessed through the application's network stack, while considering implementing additional monitoring for unusual outbound requests that may indicate SSRF exploitation attempts. The default configuration should also be reviewed to ensure that potentially dangerous features like webhooks are not enabled without explicit administrator consent and proper security considerations.