CVE-2026-41230
Froxlor ≤ 2.3.6
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:LSummary
CVE-2026-41230 is a high-severity CRLF Injection (CWE-93) vulnerability in Froxlor Froxlor. Its CVSS base score is 8.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked at the 28th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Froxlor, an open source server administration software, contains a vulnerability (CVE-2026-41230) in versions prior to 2.3.6 affecting the `DomainZones::add()` function. This function accepts arbitrary DNS record types without a whitelist and fails to sanitize newline characters in the `content` field. For DNS types not covered by the existing if/elseif validation chain, such as NAPTR, PTR, or HINFO, content validation is completely bypassed. Embedded newlines in the content persist through `trim()` processing, get stored in the database, and are directly written into BIND zone files via `DnsEntry::__toString()`.
An authenticated customer with low privileges (PR:L) can exploit this over the network (AV:N) with low complexity (AC:L) and no user interaction (UI:N). Successful exploitation allows injection of arbitrary DNS records and BIND directives, including `$INCLUDE`, `$ORIGIN`, and `$GENERATE`, into the victim's domain zone file. The vulnerability has a CVSS v3.1 base score of 8.5, with high integrity impact (I:H), low availability impact (A:L), no confidentiality impact (C:N), and changed scope (S:C), mapped to CWE-93 (improper neutralization of CRLF sequences).
The Froxlor security advisory (GHSA-47hf-23pw-3m8c) and release notes for version 2.3.6 detail the fix, implemented in commit 47a8af5d9523cb6ec94567405cfc2e294d3a1442. Administrators should upgrade to Froxlor 2.3.6 or later to mitigate the issue, as it addresses the lack of DNS type whitelisting and improper sanitization of newlines in zone content.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-25180
Vulnerability Data
Froxlor is open source server administration software. Prior to version 2.3.6, `DomainZones::add()` accepts arbitrary DNS record types without a whitelist and does not sanitize newline characters in the `content` field. When a DNS type not covered by the if/elseif validation…
more
chain is submitted (e.g., `NAPTR`, `PTR`, `HINFO`), content validation is entirely bypassed. Embedded newline characters in the content survive `trim()` processing, are stored in the database, and are written directly into BIND zone files via `DnsEntry::__toString()`. An authenticated customer can inject arbitrary DNS records and BIND directives (`$INCLUDE`, `$ORIGIN`, `$GENERATE`) into their domain's zone file. Version 2.3.6 fixes the issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V4.2.4
Mitigating Controls (NIST 800-53 r5) AI
Input validation directly stops untrusted data containing CRLF sequences from reaching the component that treats CRLF as a delimiter.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input neutralization and validation to block CRLF injection.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect CRLF flaws but does not itself implement the neutralization.
Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
Application security requirements include rules for neutralizing special characters such as CRLF in inputs.
Secure architecture principles encourage safe handling of untrusted data but do not prescribe specific CRLF controls.
Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.