Froxlor 2.3.14 ships four security fixes
Floxlor released 2.3.14 today, and it is a security update through and through. All four of the changes carry a [Security] tag in the changelog.
The open-source server-control panel pushed this version to GitHub today. Maintainer Michael Kaufmann, who posts under the handle d00p, shipped it as the latest step in a coordinated hardening campaign across the 2.3.x branch. Keep in mind that 2.3.10, 2.3.11, and 2.3.13 all shipped their own security fixes.
What's in this release
The release notes read like a short checklist of the usual web-panel attack surface.
First is authorization enforcement on server-wide reads. The MySQL server and cron-job listing commands now demand both admin status and the specific change_serversettings permission flag. An admin account without that flag can no longer reach server-wide database or cron data through these paths. Froxlor applied the same guard to Customers, Admins, and Domains too.
Second is a theme allowlist. The theme input is now validated against installed themes only, then escaped whenever a listing renders it. That closes a classic stored or reflected XSS vector.
Third, control characters get rejected when you add FTP members. The move targets CRLF and header-injection abuse.
Fourth, the mail-body lookup while editing templates is now scoped to the requesting admin. One admin can no longer read another's mail content, or a customer's.
There are also two regular bug-fixes for good measure. One restores a valid CSRF token for table-column AJAX requests, closing a real forgery gap in the sortable-columns JavaScript. The other restores support for using an FQDN redirect URL as a documentroot, undoing a usability regression that had blocked it.
Why it matters
Some commit messages deserve a second read. A couple lean on phrases like "narrow (not close)" for an SSH-key time-of-check-time-of-use race. That is the maintainer essentially admitting these are layered defenses, not one-shot patches.
The rest is more of the same: authorization and injection bugs in software that often fronts production web, DNS, and mail infrastructure. That's exactly what attackers are hunting for.
If you're running a public-facing instance or handing the panel to hosting customers, updating sooner rather than later is sensible. One wrinkle to expect: at least one fix path invalidates active sessions and 2FA tokens, and nudges you to rotate API keys. Plan for a brief re-authentication cycle after you upgrade.
Across the 2.3.x line, Froxlor has been quietly stripping private keys from API responses, adding CRLF rejection to URL validation, rejecting multi-line SSH public keys, and scoping 2FA remember-tokens per user. It's a steady drip of hardening rather than a single big fix.
Downloads for froxlor-2.3.14.tar.gz and froxlor-2.3.14.zip are attached to today's GitHub release. You can see the eight commits against the previous stable by checking the 2.3.13 to 2.3.14 diff.
Floxlor is a mature project now. It launched in March 2012 and its repository carries roughly 1,748 stars and 469 forks, all under the LGPL-2.1 license. It is a full Laravel codebase aimed at people running their own web, DNS, and mail stacks without handing over control.
