CyberPanel's security history, and what it teaches operators

CyberPanel is our beachhead, and it is also a product with a documented security history. Writing honestly about both is the only version of this article worth publishing — the panel is a distribution channel for us, not a target, and the operators reading this are the people who had to clean up after October 2024.

What follows is what is verified, what is disputed, and what a host-level control does and does not change.

October 2024: three pre-auth RCEs

Three vulnerabilities were fixed in short order, all rated 9.8 by NVD and 10.0 by MITRE. Both scores are correct — the assessments differ on the CVSS Scope metric, which is exactly the kind of detail that gets flattened in press coverage.

The fix commits 5b08cd6 (07:32 UTC) and 1c0c6cb (09:40 UTC) both landed on 23 October 2024, both labelled “bug fix: pre-auth”, in the CyberPanel repository . The vendor published its own account of the issue and the patch .

Researcher attribution is split, and gets conflated constantly: refr4g (26 October 2024) is the reference for CVE-2024-51378, while DreyAnd (27 October 2024) is carried by NVD for CVE-2024-51567 and CVE-2024-51568. Attributing all three to one researcher is a common and avoidable error.

Both CVE-2024-51567 (added 7 November 2024) and CVE-2024-51378 (added 4 December 2024) are in the CISA KEV catalogue , both flagged with known ransomware use. CVE-2024-51568 is not. One caution for anyone citing the catalogue: CISA names both entries “CyberPanel Incorrect Default Permissions Vulnerability” and tags CWE-276, while NVD assigns CWE-78 and CWE-306. The NVD classification is the accurate one; these are command injection and missing authentication, not default-permissions issues.

The ransomware wave, and the numbers people conflate

Mass exploitation was confirmed on 29 October 2024. The authoritative artefact is LeakIX’s gist , created 29 October 2024 at 17:49 UTC by Gregory Boddin, which carries the indicators and a working decryptor. LeakIX never published a blog post about the campaign; anyone citing one is citing something that does not exist.

Three ransomware families were involved, per that gist:

We are currently aware of 3 separate groups encrypting CyberPanel instances. The extension they leave are:

• .psaux -> Custom ransomware, script based, decryptor available
• .encryp -> Variant from Babuk’s source, decryptor available
• .locked -> C3RB3R Conti v3-based Ransomware, decryptor status unknown

Note .encryp, not .encrypted. Trade press reported the latter; the people who reverse-engineered it wrote the former.

The counts need keeping apart, because press coverage merged them and the merged version is still circulating. Three different populations were measured in late 2024: LeakIX fingerprinted 21,761 instances as vulnerable; Censys counted 60,935 exposed CyberPanel portals on 1 November 2024 and 55,425 a week later, explicitly noting that exposure is not vulnerability because versions were not visible; and LeakIX reported roughly 20,000 instances actually compromised, carrying about 200,000 websites. Those are three questions with three answers, not one number reported three ways. (We link the primary artefact we verified directly, the LeakIX gist; the LeakIX and Censys counts were published by those organisations at the time.)

The drop-off afterwards is genuinely disputed. LeakIX describes a cliff — roughly 22,000 to about 400 overnight. Censys describes a slope, of roughly one to two thousand per day over the following week. Both are reported here because we cannot reconcile them, and the most likely explanation is that they were counting different sets.

And the figure you will see most often is wrong. “22,000 CyberPanel instances on Shodan” appears in no primary reporting we could open. It is a misattribution of LeakIX’s vulnerable count. Do not repeat it, and be sceptical of any article that does.

We also publish no CyberPanel installed-base number at all. The vendor’s homepage and its about page give figures an order of magnitude apart, neither with a methodology. The gap in the market is provable qualitatively; the market size is not.

2025 was quiet. 2026 has not been.

2025 produced zero published CyberPanel CVEs, zero KEV additions and no mass-exploitation reports. That is worth saying plainly, because it is the kind of fact a vendor selling against a platform would rather omit. It is also worth qualifying: several of the bugs disclosed in early 2026 were reported in December 2025, and absence of a published incident is not proof that nothing happened.

Of the 17 CyberPanel CVEs in NVD, ten were published in 2026. The live one is more serious than the 2024 bug:

CVE-2026-67614 , published 13 August 2026, CVSS 9.8 (v3.1) and 9.3 (v4.0), CWE-798. A hard-coded JWT secret grants an unauthenticated interactive root shell through the WebTerminal FastAPI WebSocket on port 8888. It affects versions below 3.0.0 and is fixed in 3.0.0. It was reported by Deniz Mert on 27 July 2026 and fixed on 9 August 2026. It is not in KEV and we have seen no report of exploitation in the wild — but it is arguably easier to exploit than CVE-2024-51378, and the fix is recent.

Alongside it: CVE-2026-67613 (path traversal, root file read, below 3.0.0), and from April 2026 CVE-2026-41473 (CVSS 9.1, unauthenticated database write via the AI Scanner status-webhook, fixed in 2.4.5) and CVE-2026-41472 (an unauthenticated stored XSS to RCE chain, also fixed in 2.4.5).

Two version notes for anyone building a tracker. CVE-2021-47949 is a 2021 bug published in May 2026 as part of a historical backfill — it is not a 2026 incident. And CVE-2026-65916 and CVE-2026-65917 state a range of “through 1.9.1”, which looks wrong for a 2026 bug; treat that range as unverified.

Three things that do not show up in your tooling

Advisories without CVE IDs. GHSA-h2f7-38ww-5pwc (26 August 2026, high, an API authentication bypass of two-factor authentication) and GHSA-qmwq-9cc8-x6h2 (11 August 2026, medium) carry no CVE, so they appear in no CVE-based scan.

Dependency scanners do not see CyberPanel at all. A global GitHub Advisory Database query returns zero results for it, because it is not a packaged ecosystem entry. If your vulnerability process is “the dependency scanner will tell us”, it will not.

The releases page lies about the project. The GitHub Releases tab stops at v1.9.1 in 2019 because versioning moved to branches. The project is alive — current version v3.0.5, dated 26 August 2026 — and reading the Releases tab alone leads to the wrong conclusion. Watch the change log instead.

One scope correction while we are here: the two 2026 LiteSpeed entries in KEV (CVE-2026-48172 and CVE-2026-54420) are in the cPanel plugin, which CyberPanel does not have. They do not apply to a CyberPanel stack. Actual OpenLiteSpeed exposure is three CVEs, none in KEV; the notable one, CVE-2026-31386 (CVSS v4 8.6, command injection), is post-authentication.

What host-level defence adds, and what it does not

Let us be precise, because overclaiming here would be both wrong and easy to catch.

A file scanner would not have prevented the October 2024 campaign. The entry point was a pre-authentication RCE in the panel. Patching prevents that; nothing else does. A scanner that told you about it afterwards is not a substitute for 2.3.8.

What a host-level control does change is what happens in the window between exploitation and discovery, and what you can prove afterwards:

• The second stage is usually a file. Panel RCE, plugin file-upload bug and stolen FTP credentials all converge on the same step — write a PHP file into a document root, then request it. That step is visible at the filesystem layer regardless of which of the three got the attacker in.
• It sits outside the thing that was compromised. A control inside the panel or inside the site is reachable by whoever compromised the panel or the site. That argument, made from documented incident casework and kernel documentation rather than assertion, is in why webshell detection belongs on the server .
• It produces the evidence. For a German hoster in scope of NIS2, a significant incident triggers a 24-hour early warning and a 72-hour notification including indicators of compromise. Scanner logs, quarantine manifests and an audit trail are the evidence base for that report. We cover the obligations in NIS2, GDPR and malware scanning for hosting providers .

And the honest limits. A root-level compromise beats any control running on the same box: an attacker with root can patch binaries, and no client-side check survives that. Ransomware that encrypts customer data is a different failure mode from a webshell, and backups are the answer to it. Database-resident malware leaves no file to find. A scanner narrows the window and preserves the record; it does not make a panel RCE harmless.

Finally, the structural gap on this platform is unchanged and provable from two vendors’ documentation: CyberPanel ships no first-party malware scanner, its documented Imunify360 route requires converting the OS to CloudLinux , and ImunifyAV officially supports cPanel, Plesk and DirectAdmin — not CyberPanel.

What this means for CyberPanel operators

1. Get to 3.0.0 or later. CVE-2026-67614 gives an unauthenticated root shell on port 8888 below 3.0.0. If you do nothing else from this article, do this, and confirm the version rather than assuming it.
2. Do not expose 8888 to the internet. The panel port is the attack surface in every incident above. Bind it, firewall it, or put it behind a VPN — csf is still maintained and still fine for this.
3. Track CyberPanel by hand. No dependency scanner sees it, two 2026 advisories have no CVE, and the Releases tab is misleading. Subscribe to the change log and watch NVD by keyword rather than by CPE, which misses three of the seventeen.
4. Assume the second stage is a file, and instrument for it. The panel bug is the way in; a webshell in a document root is how access is kept. Those are separate controls and you need both. What those files look like is set out in the WordPress webshell wave .
5. Write your incident evidence plan before the incident. Which logs, retained how long, exportable by whom. The 72-hour clock is not the moment to find out.

Shelltrap watches file writes under your customer roots in real time and keeps a tamper-evident, exportable audit trail of every finding and quarantine action. The installation documentation sets out the requirements; commercial terms are on the pricing page .