Froxlor EUVD-2026-25180

Requires authenticated access to Froxlor with customer-level DNS management privileges (PR:L from CVSS vector). Specifically, the attacker must have permission to create or modify DNS records for at least one domain managed by the Froxlor instance, which is standard functionality granted to hosting customers in default configurations. The Froxlor installation must be configured to use BIND as the DNS server backend (not all installations use BIND - some may use PowerDNS or other alternatives, which would not be affected by zone file injection). Exploitation does NOT require administrative/root privileges within Froxlor, physical access to the server, or non-default feature enablement. The vulnerability is exploitable in default customer account setups where DNS self-service management is enabled. Attack is network-based (AV:N) and does not require user interaction (UI:N), meaning once credentials are obtained, exploitation is straightforward through the web interface. No race conditions or timing dependencies exist (AC:L). Limiting factors include: authentication barrier prevents anonymous internet exploitation, and BIND process permissions may restrict which files can be included via $INCLUDE directive, though DNS manipulation alone provides significant impact.

Real-world risk is moderate-to-high for multi-tenant hosting environments. CVSS 8.5 with Changed Scope (S:C) correctly reflects that authenticated customers can impact DNS resolution beyond their own account boundary - affecting all domains managed by the Froxlor instance. Attack vector is network-based (AV:N) with low complexity (AC:L), requiring only low-privilege customer credentials (PR:L) and no user interaction (UI:N). However, the CVSS integrity impact (I:H) and availability impact (A:L) align with DNS manipulation capabilities rather than system compromise. No EPSS data provided, but GitHub Security Advisory publication increases discovery likelihood. Absence from CISA KEV suggests no widespread exploitation campaigns detected yet. The authentication requirement (PR:L) significantly reduces exposure versus unauthenticated flaws - attackers need valid customer accounts, limiting this to malicious insiders, compromised credentials, or shared hosting abuse scenarios. Primary risk is DNS poisoning/hijacking in shared hosting environments where multiple untrusted customers manage domains on the same Froxlor instance. Secondary risk is service disruption via malformed BIND directives causing zone file parsing failures. Critical missing data: no information on whether default Froxlor deployments validate customer input at additional layers (web application firewall, BIND configuration restrictions), which could provide defense-in-depth beyond the application code.

An attacker with a basic Froxlor customer account navigates to the DNS record management interface for their hosted domain. They create a new DNS record selecting an uncommon type like HINFO (host information) which bypasses the if/elseif validation chain. In the content field, they enter a payload containing embedded newlines: 'CPU-INFO\n$INCLUDE /etc/passwd\nOS-INFO'. When Froxlor generates the BIND zone file, the unsanitized newlines create multiple lines, injecting the $INCLUDE directive that attempts to embed /etc/passwd into the zone (though BIND may restrict file access). Alternatively, the attacker uses $GENERATE to create thousands of subdomain records causing resource exhaustion, or manipulates $ORIGIN to hijack DNS resolution for unrelated domains managed by the same server. The modified zone file is loaded by BIND, affecting DNS queries for all users of the domain.