In brief
If your hosting panel holds the keys to all customer websites, it is the first target attackers look for. That is exactly why the current warning about Froxlor deserves a look. CERT-Bund lists it in its warning and information service under the ID WID-SEC-2026-3629.
- CERT-Bund has published a warning about Froxlor under the ID WID-SEC-2026-3629.
- It affects you if you run Froxlor yourself on a root server. Maintenance is your job, not the provider's.
- Four things belong on your list: establish the version, take the panel off the open network, apply the update, check for traces.
A note upfront: In this post we deliberately do not name CVE numbers, affected versions or attack details. The authoritative information is in the advisory itself and in the release notes of the Froxlor project. Read them before you decide whether your installation is affected. What we provide here is the order of checks that makes sense in any case.
---
## Why a hosting panel is an especially rewarding target
Froxlor manages domains, databases, FTP accounts, email addresses and web server configurations in one place. That gives the panel far-reaching rights on the server. Whoever takes over the panel can often reach more than a single website.
You know this pattern from other management interfaces. We described it for Webmin and for Virtualizor. The software is well maintained at its core, but the interface is exposed to the internet, and a single flaw in the login or in the permission system is enough.
A panel that anyone can reach from the internet will be found, usually faster than you apply an update.## Who the warning affects The answer depends on who maintains the software:
| Situation | Who updates? | Action needed |
|---|---|---|
| Froxlor on your own root server | You | High: check immediately |
| Froxlor on a server you run for customers | You | High: customer data is affected too |
| Managed web hosting without your own panel | The provider | None, just ask |
| Froxlor test installation | You | Medium: shut it down or update it |
- Establish the version. Log in to the panel and read the installed version. Compare it with the versions named in the advisory and in the release notes. If your version is listed there as affected, go straight to step 3.
- Check system packages. Show which updates are pending on the server:
A panel update does not replace operating system updates. PHP, web server and database must be up to date as well.sudo apt update apt list --upgradable - Restrict access. Until the update is done, block the panel interface for everyone except yourself. With ufw, for example, you allow only your fixed IP on the HTTPS port (adjust address and port to your installation):
If the panel runs on the same port as your customer websites, block the panel's path in the web server instead. A ufw rule on port 443 would otherwise lock out all websites.sudo ufw allow from 203.0.113.10 to any port 443 proto tcp sudo ufw status numbered - Take a backup. Back up the panel database and configuration before you update. An update that aborts halfway through is a problem without a backup.
- Apply the update. Use the method documented by the Froxlor project for your type of installation. Download packages only from the project's official sources.
- Look for traces. Check whether anyone has worked on the system in the meantime (see the next section).
- Verify the result. Check the version again and test from a foreign IP whether the panel is really no longer openly reachable.
Warning: If your panel was already openly exposed to the internet before the vulnerability became known, an update is not enough. An update closes the hole, but it does not remove anything an attacker has already planted. So be sure to do step 6 as well.
## Checking for signs of a takeover
You are looking for things you did not create yourself. Three places are enough for a first overview:
* **Logins:** Check who has logged in to the server and compare with your own times.
* **New files:** Search the web directory for recently changed PHP files.
* **New accounts:** Look in the panel's user management for administrators or customers you do not know.
The matching commands:
last -a | head -20
sudo find /var/www -name '*.php' -mtime -14 -ls
sudo awk -F: '$3 == 0 {print $1}' /etc/passwdPro: panel reachable only from the management network
- Scanners on the internet no longer find the login page.
- A new vulnerability becomes a problem for weeks instead of hours.
- Customer websites keep running unchanged.
Contra
- You need a fixed IP or a VPN to reach the panel yourself.
- Someone on the team who is on the road has to connect first.
- The rule has to be documented, otherwise someone will wonder about it later.
Practical tip: Put a fixed date in your calendar, for example the first Monday of the month, to compare the panel version and pending system updates. Ten minutes in the calendar is cheaper than a night with a hijacked server.
## Common mistakes after a warning like this
* **Updating only the panel:** PHP and the web server stay old, although they sit on the same attack path.
* **No backup before the update:** If something goes wrong, there is no way back.
* **Forgetting an old test installation:** A second, unmaintained panel on another port is just as vulnerable.
* **Not changing passwords after a suspicion:** Anyone who has been in the system often knows database passwords and keys as well.
* **Reading first, acting later:** Read the advisory, but restrict access to the panel beforehand. It takes two minutes.
## How you know it worked
You are done when all four points hold:
1. The panel version matches the fixed version named in the advisory or in the release notes, or is newer.
2. `apt list --upgradable` shows no pending security updates any more.
3. From a foreign network, such as your phone on mobile data, the panel login page no longer loads.
4. The search for new files, accounts and logins turned up nothing you do not recognize.
If you run a DNS panel or a name server on the same server, also take a look at our post on the BIND vulnerabilities. It describes a similar order of checks.
Frequently asked questions
Am I affected by the Froxlor warning if I only booked web hosting from a provider?
Only if your provider uses Froxlor. In that case the update is up to them, not you. You can ask whether and when they will update. If you run a root server with Froxlor yourself, you have to update it yourself.
Where do I find the exact affected versions?
In the CERT-Bund advisory under the ID WID-SEC-2026-3629 and in the release notes of the Froxlor project. They contain the authoritative information. Compare it with the version your panel shows after you log in.
Is it enough to block the panel with a firewall instead of updating?
As an immediate measure, yes; as a permanent solution, no. The block reduces the attack surface, but the vulnerability stays in the software. Update as soon as a fixed version is available, and keep access restricted anyway.
How do I tell whether someone has already exploited my panel?
Typical signs are unknown administrator or customer accounts, recently changed PHP files in the web directory, unfamiliar logins in the output of last, and additional accounts with root privileges. If you find anything like that, it is best to set the server up again and change all credentials.
