Froxlor bug lets low-level users rewrite your web server's config as root
A patch for a server panel's CRLF flaw turned out to have a hole in it - here's who actually needs to worry, and who doesn't.
A vulnerability disclosed this week in Froxlor, an open-source server administration panel used to manage hosting accounts, shows why “fixed it” and “actually fixed it” aren’t always the same thing. Tracked as CVE-2026-100717, the bug lets a low-privilege customer account inject rogue commands into the web server’s own configuration file - and Froxlor then reloads that config as root.
What the bug actually does
Froxlor lets customers set up subdomains with redirect URLs, which the panel then bakes into the nginx or Apache configuration it generates for the server. An earlier flaw (patched previously) let attackers smuggle carriage-return and line-feed characters - the invisible bits that start a new line in a text file - into those URLs, letting them add extra directives into the vhost config that shouldn’t be there.
Froxlor’s fix checked for those characters in the path, query and fragment parts of the URL. Unfortunately, according to the GitHub security advisory, it forgot to check the “userinfo” bit - the user:pass@ portion that can precede the domain name in a URL. Slip a newline in there (VulnCheck’s write-up gives the example http://user%0areturn 200 "pwned";%0a@evil.com/) and it sails through validation untouched, survives Froxlor’s internal encoding, and lands verbatim in the generated server config.
Because Froxlor regenerates and reloads that config as root, whatever the attacker snuck in gets executed with full server privileges the moment the change is applied.
So who is actually at risk
This isn’t a remote, unauthenticated, drive-by exploit - you need an account on the panel. But the bar is low: VulnCheck confirms that any customer with permission to create a subdomain can trigger it, with no admin rights or special server-settings access required. On a shared hosting box running Froxlor, that could mean any paying customer, or anyone who’s compromised a customer account, has a route to hijacking how the entire web server responds - or reading files it shouldn’t.
Severity ratings vary between sources, which is itself worth noting: the GitHub advisory calls it Critical, VulnCheck scores it 8.5 (High) under CVSS v4, while NVD’s own listing for CVE-2026-100717 pegs it at a striking 9.9. Nobody disputes the mechanism; they just weigh the “needs an authenticated account” caveat differently.
What’s genuinely unclear right now is scale. There’s no public figure for how many live Froxlor installs exist, and neither advisory reports any evidence of active exploitation - this is a responsibly disclosed bug (credited to researcher arpitjain099), not a breach in progress. If you don’t run Froxlor, or don’t hand subdomain-creation rights to untrusted customers, none of this touches you.
What to do about it
The fix is out: Froxlor 2.3.12 patches the userinfo gap. If you administer a Froxlor-based hosting panel, the sensible move is to update now rather than trust that “customer accounts are basically fine” - the whole point of this bug is that a basic customer account isn’t fine. If you’re a Froxlor customer rather than the admin, there’s nothing to do on your end beyond nudging whoever runs the box.
The takeaway
A niche but real privilege-escalation bug in a hosting control panel, patched, not (as far as anyone has reported) exploited in the wild. Update if you run Froxlor; everyone else can read this as a tidy reminder that incomplete fixes are their own category of bug.