Hosting panel security incidents 2024–2026: what went wrong and what to learn

A sourced timeline of hosting control panel vulnerabilities 2024–2026 (cPanel, CyberPanel, CWP, Plesk, HestiaCP), the patterns and a defense checklist.

Timeline of hosting control panel security incidents from 2024 to 2026 with a defense checklist

Key takeaways

  • From 2024 to 2026, critical bugs hit almost every popular hosting panel, and several were exploited at scale before or right after a patch.
  • Most were command injection or login bypass bugs in code that runs as root, so one flaw meant the whole server.
  • Restricting the admin port to your own IPs would have blocked the pre-auth attacks from the internet in every case below.
  • Privilege separation limits what a bug in the web layer can reach, but it does not replace fast patching, 2FA and offsite backups.

Between 2024 and 2026, serious hosting control panel vulnerabilities were found in cPanel & WHM, CyberPanel, Control Web Panel (CWP), Plesk, HestiaCP, Webmin and aaPanel. The worst were exploited in the wild: CyberPanel servers were mass-encrypted by PSAUX ransomware in October 2024, and the cPanel login bypass CVE-2026-41940 was abused for about two months before its April 2026 patch. Almost all of these bugs were command injection or authentication bypass in code running as root, and almost all of them needed the panel's admin port to be reachable from the internet.

This article lists the verified incidents with primary sources, explains the patterns behind them, and gives a defense checklist that works for any panel, including ours. ZoPanel is software too and will have bugs; the point is to plan for that.

Timeline: major hosting control panel vulnerabilities, 2024–2026

We included only entries we could confirm on NVD, in CISA's Known Exploited Vulnerabilities (KEV) catalog or in a vendor advisory. "Pre-auth" means an attacker needs no account on the panel.

Date Panel CVE Bug Pre-auth? Impact Fix Exploited (KEV)
Oct 2024 CyberPanel 2.3.6, 2.3.7 CVE-2024-51567, CVE-2024-51378 Security check only applied to POST, then shell metacharacters in statusfile Yes Commands as root Upstream commits, applied with the upgrade function Yes, Nov and Dec 2024, ransomware
Dec 2024 Webmin CVE-2024-12828 CGI command injection No (low-privileged login) Code as root Update (ZDI-24-1725) No
Sep 2025 CWP before 0.9.8.1205 CVE-2025-48703 Command injection in the file manager's changePerm Yes, but needs a valid non-root username Remote code execution 0.9.8.1205 Yes, Nov 2025
Dec 2025 Plesk for Linux CVE-2025-66431 Flaw in domain creation No (user with site-management rights) Code as root 18.0.73.5, 18.0.74.2 No
Mar 2026 aaPanel 7.57.0 CVE-2026-29859 Arbitrary file upload Yes, per CVSS (PR:N) Code execution (CVSS 9.8) Update to a later release No
Apr 2026 cPanel & WHM after 11.40 CVE-2026-41940 CRLF injection into the session file at login Yes Root-level WHM session Patched builds from 28 April 2026 Yes, 30 Apr 2026, ransomware
May 2026 HestiaCP 1.9.0–1.9.4 CVE-2026-43633 Deserialization in the web terminal Yes (web terminal enabled) Code as root 1.9.5 No
May 2026 LiteSpeed plugin for cPanel CVE-2026-48172 Privilege escalation in the user-end plugin No (any cPanel user) Scripts as root Plugin 2.4.5 Yes, May 2026
Aug 2026 Plesk before 18.0.80 CVE-2026-64637 Privilege management in the XML-RPC API No (reseller) Admin session as root user 18.0.80 No
Aug 2026 CyberPanel before 3.0.0 CVE-2026-67614 Hard-coded JWT secret in the web terminal Yes Interactive root shell 3.0.0 No
Oct 2026 HestiaCP 1.9.7–1.10.4 CVE-2026-108390 Unescaped quote lets a user inject PATH into a root script No (any panel user with a web domain) Code as root 1.10.5 No

"Exploited (KEV)" reflects the KEV catalog as of 20 October 2026. "No" means not in KEV, not proof that nobody exploited it. For context: CWP had already been in KEV since January 2023 for CVE-2022-44877, a pre-auth command injection in its login page, so CVE-2025-48703 was the second time the same class of bug was exploited there.

The two incidents that hurt the most

CyberPanel, October 2024. Researchers published two pre-auth flaws a few days after the maintainers committed fixes, but before a new release or CVEs existed. Help Net Security reported that LeakIX counted about 22,000 exposed vulnerable instances on a Monday and around 400 the next day, after attackers had encrypted servers with PSAUX and other ransomware. CISA lists both CVEs with known ransomware use.

cPanel & WHM, April 2026. WebPros published its advisory and patches on 28 April 2026. According to Help Net Security, attackers had been exploiting the flaw since at least 23 February, and Shadowserver counted about 650,000 IPs with exposed cPanel/WHM. watchTowr's analysis shows the root cause: a password value written into the session file without stripping line breaks, so an attacker could add lines that make the server skip password checks. Patched builds include 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20 and 11.136.0.5. The interim advice was to block ports 2083, 2087, 2095 and 2096 until patched.

What about the panels with fewer headlines?

In the KEV catalog (20 October 2026) we found no entries for Plesk, DirectAdmin, HestiaCP or aaPanel, and Webmin's only entry is from 2019 (CVE-2019-15107). That does not mean those panels are clean. NVD lists a long run of 2026 Plesk CVEs where a logged-in user reaches root, HestiaCP fixed several "panel user to root" bugs, and NVD lists new aaPanel and BaoTa (the Chinese edition) command injection reports in September and October 2026. A short KEV record can reflect fewer exposed servers or less attacker attention as much as better code.

The patterns behind the incidents

Read the table again and five patterns stand out.

1. The panel's web code runs as root

In nearly every row, the impact column says "root". When the process that parses HTTP requests is root, or can run root commands with few checks, any bug in that code is a full server compromise: every site, every database, every mailbox, and the backups stored on the same disk.

2. Command injection is still the number one bug class

CyberPanel, CWP (twice), Webmin, HestiaCP, Plesk and the aaPanel reports all involve user input reaching a shell. The fix is known: never build a shell command from input; run programs directly with a fixed argument list. It takes discipline across thousands of code paths, which is why it keeps coming back.

3. Login and session code is the front door

The cPanel bypass, CyberPanel's POST-only check, CyberPanel's hard-coded JWT secret, and the HestiaCP CF-Connecting-IP spoofing bug all attacked the code that decides who is logged in. Web terminals deserve special mention: HestiaCP and CyberPanel both had pre-auth root bugs in theirs.

4. The admin port is open to the whole internet

Mass exploitation needs mass exposure. Tens of thousands of CyberPanel servers and hundreds of thousands of cPanel servers answered on their admin ports. A firewall rule allowing only your own IPs would have stopped every pre-auth attack in the table from the internet.

5. Patches arrive late, or quietly

cPanel was exploited for about two months before a patch existed. CyberPanel's fixes landed as commits with no release or CVE at first. For the September 2026 BaoTa reports, NVD's record says the vendor did not respond to the reporter. On your side, many servers run old builds for months because nobody watches for updates.

A defense checklist for any hosting panel

None of this depends on which panel you use.

Control What it stops How
Restrict the admin port to your IPs or a VPN Every pre-auth exploit from the internet Firewall rule, panel IP allowlist, or an SSH tunnel
Two-factor authentication for every admin and reseller Stolen or guessed passwords TOTP app, saved recovery codes
Automatic or same-day updates Known bugs after the fix ships Turn on auto updates, subscribe to the vendor's advisories
Offsite backups you have restored at least once Ransomware and wiped servers Copy to S3 or another server with separate credentials
Monitoring and alerts Silent compromise Alerts on new admin logins, new UID 0 users, new cron jobs, CPU spikes
Turn off what you do not use Bugs in features you never needed Web terminal, unused plugins, public phpMyAdmin
Few, scoped API tokens Leaked automation credentials Per-purpose tokens, IP limits, expiry

The firewall rule matters most. On Ubuntu with UFW, replacing PORT with your panel's port:

sudo ufw allow from 203.0.113.7 to any port PORT proto tcp
sudo ufw deny PORT/tcp

If your IP changes often, use an SSH tunnel instead: ssh -L 8443:127.0.0.1:PORT user@server, then open https://127.0.0.1:8443. For the server basics around the panel, see how to secure an Ubuntu VPS and website backup strategy.

How privilege separation limits the blast radius

Privilege separation means the code that talks to the internet does not hold root. In ZoPanel, the web panel runs as an unprivileged zopanel user under systemd hardening. Root work goes to a separate agent that accepts only a fixed list of actions, validates every parameter again and never passes user data to a shell (security docs). Each hosting account is its own Linux user with its own PHP-FPM pool and a systemd slice with CPU, memory and process limits.

Apply that to the table:

  • Command injection in the web layer (CyberPanel 2024, CWP, Webmin): code runs as the unprivileged panel user, with no shell to inject into at the root side.
  • Customer to root (Plesk, HestiaCP, the LiteSpeed plugin): a customer's processes run as the customer inside their own slice, and the root agent re-checks what they ask for.
  • Login bypass to an admin session (cPanel 2026): privilege separation helps much less. An attacker who logs in as admin can do whatever an admin can. Here only the IP allowlist, 2FA and fast patching help.

That last point is the honest limit. Architecture shrinks the damage from many bug classes; it does not make a panel unbreakable. The full design is in why a hosting control panel should never run as root.

ZoPanel is software too

We will ship bugs. What we can do is reduce what each bug can reach and fix fast. Our 0.4.22 release on 15 October 2026 shipped hardening from an external security review. Updates are signed with Ed25519 and roll back automatically if a health check fails (updating), but automatic updates are off by default, so turn them on. The installer opens the panel port 8888 in UFW; add a panel IP allowlist under Settings → General → Restrict panel access. You can report a vulnerability through our security policy. An overview of the layers is on the security features page.

Conclusion

The 2024–2026 incidents follow one script: a command injection or login bug in root-level panel code, an admin port open to the world, and a patch that came late or was installed late. You can break that script today on any panel with an IP allowlist, 2FA, quick updates and offsite backups. When you choose your next panel, also ask what a single bug in its web interface can reach.

If you want to see privilege separation in practice, ZoPanel's Free plan runs 3 hosting accounts, 10 websites and 10 databases with no time limit.

Frequently asked questions

Was CyberPanel hacked?

Yes. In October 2024, unpatched CyberPanel 2.3.6 and 2.3.7 servers were mass-exploited through CVE-2024-51567 and CVE-2024-51378 and encrypted with PSAUX and other ransomware. In 2026 more flaws were published, including CVE-2026-67614, a pre-auth root shell fixed in CyberPanel 3.0.0. Update to the latest release and restrict port 8090.

What is the 2026 cPanel vulnerability?

CVE-2026-41940 is an authentication bypass in the cPanel & WHM login flow, rated CVSS 9.8. Attackers can gain a root-level WHM session without credentials. It was exploited from at least February 2026, patched on 28 April 2026, and added to CISA's KEV list on 30 April with known ransomware use.

Which hosting control panel is the most secure?

No panel is free of bugs; every major panel appears in the table above. Compare how they limit damage: whether the web interface runs as root, how customers are isolated, how updates are verified, and how fast the vendor publishes fixes and advisories. Then configure whichever you pick with an IP allowlist and 2FA.

Should I expose my control panel port to the internet?

Avoid it. Allow only your office, home or VPN IPs, or reach the panel through an SSH tunnel. Customers who need a login can be given a fixed range or a VPN; if that is not possible, at least require 2FA and update the same day.

How do I know if my panel has been hacked?

Look for unknown admin users, extra UID 0 accounts (awk -F: '$3==0' /etc/passwd), new cron jobs, unknown processes using CPU, and files you did not upload in web folders. Vendors often publish indicator scripts after an incident, as WebPros did for CVE-2026-41940. If you find signs, restore from an offsite backup onto a clean server rather than cleaning in place.