CVE-2026-41234: Froxlor TXT Record Newline Injection & DNS Hijacking (CVSS 7.6)

Technical summary

CVE-2026-41234 is a newline injection vulnerability in Froxlor's `DomainZones.add` API endpoint. The endpoint fails to sanitize newline characters (`\n`, `\r\n`) in TXT record content before writing to BIND zone files. When an authenticated customer initiates a DNS rebuild, the unsanitized input is written to the zone file by a cron job, resulting in multi-line TXT records that break out of their intended record boundary. An attacker can then inject BIND directives (`$INCLUDE` to load external files, `$GENERATE` for bulk record creation) or craft arbitrary DNS records, fundamentally corrupting the zone file's integrity. This represents an incomplete remediation of CVE-2026-30932, which patched the same issue for LOC, RP, SSHFP, and TLSA record types but overlooked TXT records—a more commonly used record type and therefore higher-impact gap.

Business impact

Successful exploitation enables DNS hijacking, poisoning, and service disruption. An attacker can redirect DNS queries to attacker-controlled IP addresses, intercept mail (via injected MX records), or perform phishing attacks. The ability to inject `$INCLUDE` directives could allow loading of external zone files, potentially exposing sensitive configuration. For organizations hosting multiple customer domains on a single Froxlor instance, one compromised customer account can corrupt zone files affecting other customers' DNS availability and security. DNS-layer attacks are particularly difficult to detect and remediate quickly, often causing prolonged outages or subtle service degradation before discovery.

Affected systems

Froxlor versions prior to 2.3.7 are affected. The vulnerability requires an authenticated user with DNS editing permissions enabled by the administrator. Typically this means a customer-tier account or tenant in a multi-tenant hosting environment, rather than system administrators. Organizations running Froxlor for DNS management of any number of domains are at risk if they permit customers to edit DNS records.

Exploitability

Exploitability is moderate to high. The attack requires valid authentication and explicit DNS editing permissions—barriers that limit the attacker pool to trusted or compromised customer accounts rather than unauthenticated internet users. However, the attack requires no special tools or complex technique: an attacker simply includes a newline character in a TXT record value via the API. Once submitted, the malicious payload persists in the zone file and is live each time DNS is queried. The attack surface is broad in shared hosting environments where many customers have editing permissions.

Remediation

Upgrade Froxlor to version 2.3.7 or later, which implements input validation to strip or reject newline characters in TXT record values (as well as other record types). Organizations should verify the patch is applied to all Froxlor instances and confirm via DNS query that zone files are syntactically correct after upgrade. Immediate actions include reviewing DNS record edit logs to identify any suspicious newline-containing entries, exporting and auditing zone files for unauthorized directives or records, and considering temporary restriction of customer DNS editing permissions until patching is complete.

Patch guidance

Apply Froxlor version 2.3.7 or later via the standard update mechanism. Test the patch in a non-production environment first to confirm zone file integrity and that existing DNS records render correctly. After patching, trigger a manual DNS rebuild if the system supports it, to regenerate zone files without any residual malicious entries. If zone files were corrupted prior to patching, manually remove injected directives or records before or after the upgrade. Review the Froxlor security advisory for any deprecated API endpoints or configuration changes in version 2.3.7.

Detection guidance

Monitor API logs for `DomainZones.add` calls containing unusual characters, especially newline sequences (`\n`, `\r\n`, `%0A`, `%0D%0A`) in the TXT record field. Audit generated BIND zone files for multi-line TXT records, unexpected `$INCLUDE` or `$GENERATE` directives, and out-of-place DNS records (especially MX, CNAME, or A records added by customers who should only manage subdomains). Check DNS query responses for unexpected redirects or record values. Correlate zone file modifications with API edit timestamps to identify anomalies. BIND itself may log parsing warnings or errors if a corrupted zone file is detected.

Why prioritize this

This vulnerability merits immediate attention because it combines authenticated but widely-available access (customer-level DNS editing is common in hosting environments) with high impact (DNS hijacking, mail interception, service disruption). The bypass of an earlier CVE patch indicates the vendor's initial fix was incomplete, raising questions about whether the version 2.3.7 fix addresses all record types comprehensively. In multi-tenant scenarios, a single compromised customer account puts all hosted domains at risk. The CVSS score of 7.6 (HIGH) reflects the integrity and availability damage, though the authentication requirement prevents it from reaching CRITICAL.

Risk score, explained

CVSS 3.1 score 7.6 (HIGH) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L reflects: network-accessible API (AV:N), low attack complexity—no special technique needed (AC:L), authenticated attacker with low privilege (customer account, PR:L), no user interaction required (UI:N), scope unchanged (S:U), low confidentiality impact (C:L, information exposure via zone file inspection), high integrity impact (I:H, DNS record injection), and low availability impact (A:L, zone file corruption may cause intermittent DNS failures). The authentication requirement and customer-level privilege prevent a higher score, but the high integrity impact reflects the severity of DNS manipulation.

Frequently asked questions