Froxlor's DomainZones.add API command accepts user-controlled DNS record and type values and later writes them into generated BIND zone files without rejecting line delimiters, tab characters, or zone-file comment delimiters.

The stronger variant is in record. An authenticated customer with DNS-zone permissions can submit a normal A record request where record is:

wwwt60tINtAt6.6.6.6 ; @

with type=A and content=127.0.0.1. The current record flow trims/lower-cases/IDNA-encodes the value, but does not reject CR/LF/HTAB or semicolon. The real FroxlorDnsDnsEntry:: toString() sink renders it as:

www 60 in a 6.6.6.6 ; @ 18000 IN A 127.0.0.1

BIND accepts the generated zone file:

named-checkzone example.com froxlor dns record injected.zone zone example.com/IN: loaded serial 2026060501 OK

named-compilezone -D confirms both records are parsed as real DNS RRs:

example.com. 18000 IN A 127.0.0.1 www.example.com. 60 IN A 6.6.6.6 zone example.com/IN: loaded serial 2026060501 OK

Affected code in 2.3.7:

There is also a related type-field variant because type is not allowlisted and domain dns entries.type is varchar(10). The value NStns. @tA renders one submitted entry as multiple zone-file records.

Impact: authenticated customer with DNS-zone permissions can inject additional BIND resource-record lines into the generated zone file for a domain they can manage in Froxlor, bypassing Froxlor's DNS field-level validation. This is DNS zone integrity loss and possible DNS availability impact inside the caller's manageable zone.

Suggested remediation: allowlist DNS RR types, reject CR/LF/HTAB/control chars/spaces/semicolon in record and type, validate record as a DNS owner name while allowing intended cases such as @, *, *.label, service. proto, dmarc, and DKIM selectors. Add defense-in-depth in DnsEntry or the DNS serializer so CR/LF cannot reach generated zone lines.

Attribution: Yaohui Wang.