# Is CyberPanel safe in 2026? Its security record, checks and hardening

> Is CyberPanel safe in 2026? Its CVE record from the 2024 ransomware wave to 2026, how to check a server for compromise, and how to harden it.

Source: https://zopanel.net/blog/is-cyberpanel-safe  
Updated: 2026-10-21

## Key takeaways

- CyberPanel can be run safely in 2026 only if you stay on the latest 3.0.x release and keep its ports closed to the public internet.
- In October 2024 unauthenticated root-level flaws were mass-exploited and about 22,000 exposed servers were hit, mostly by PSAUX ransomware.
- In 2026 more critical issues were disclosed, including a hard-coded Web Terminal secret that gave an unauthenticated root shell before 3.0.0.
- Check old servers for ransom files, unknown SSH keys and requests to the exploited endpoints, and rebuild rather than clean a compromised host.

Is CyberPanel safe? In 2026 it can be run safely if you keep it on the latest release (3.0.8 at the time of writing, October 2026) and never expose its admin port 8090 or Web Terminal port 8888 to the whole internet. Its record shows why both conditions matter: in October 2024 unauthenticated flaws gave attackers root on about 22,000 servers, and in 2026 several more critical bugs were disclosed and fixed, including one that gave an unauthenticated root shell. CyberPanel's developers fix issues quickly, but the panel runs with root privileges, so every bug in it is a bug in your whole server.

This article goes through the record with primary sources (NVD, CISA, the vendor's changelog and advisories), then shows how to check whether a CyberPanel server was compromised, how to harden it if you stay, and when moving is the better choice. If you have already decided to leave, our [CyberPanel alternative guide](/blog/cyberpanel-alternative) compares six panels and walks through the migration.

## The October 2024 pre-auth RCE and the PSAUX wave

Three CVEs from October 2024 are the reason most people search this question.

- **CVE-2024-51567** and **CVE-2024-51378**: the `upgrademysqlstatus`, DNS and FTP `getresetstatus` endpoints could be reached without logging in, because the security middleware only checked POST requests, and a `statusfile` value with shell metacharacters ran as a command. NVD scores both 9.8 (the CVE assigner gave 10.0) and lists versions through 2.3.6 and an unpatched 2.3.7 as affected ([NVD CVE-2024-51567](https://nvd.nist.gov/vuln/detail/CVE-2024-51567), [NVD CVE-2024-51378](https://nvd.nist.gov/vuln/detail/CVE-2024-51378)).
- **CVE-2024-51568**: unauthenticated command injection through the file manager upload in versions before 2.3.5 ([NVD](https://nvd.nist.gov/vuln/detail/CVE-2024-51568)).

According to [SecurityWeek](https://www.securityweek.com/cyberpanel-vulnerabilities-exploited-in-ransomware-attacks-shortly-after-disclosure/), the researcher DreyAnd reported the flaws, patches were created on October 23, 2024, and technical details with proof-of-concept code were published on October 27. LeakIX saw about 22,000 exposed instances on October 28; a day later only a few hundred were still reachable. [Help Net Security](https://www.helpnetsecurity.com/2024/10/30/vulnerable-cyberpanel-psaux-ransomware/) reported that files were encrypted with the `.psaux` extension, that `.encryp` and `.locked` variants were also seen, and that LeakIX published a decryptor for PSAUX. Up to three groups attacked the same servers, and some also installed cryptocurrency miners.

CISA added CVE-2024-51567 to its [Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) on November 7, 2024 and CVE-2024-51378 on December 4, 2024. CyberPanel says it shipped the patch within 30 minutes of the report ([vendor statement](https://cyberpanel.net/blog/detials-and-fix-of-recent-security-issue-and-patch-of-cyberpanel)), and its [changelog](https://cyberpanel.net/KnowledgeBase/home/change-logs/) lists **2.3.8 (November 1, 2024)** as the security release that fixes CVE-2024-51567 and CVE-2024-51378.

The problem was not that the fix was slow. As Help Net Security noted, the fixes were first committed without a new version number, so 2.3.7 stayed vulnerable until the owner ran the upgrade, and many owners did not know they were exposed. The attacks also only reached servers whose panel port was open to the whole internet.

## CyberPanel CVEs in 2025 and 2026

We searched NVD for every CVE that names CyberPanel. Many 2026 records are marked "Deferred" by NVD, so the scores below come from the CVE assigner (mostly VulnCheck). We list only what NVD or a vendor advisory confirms.

| CVE | Disclosed | Fixed in | What it allowed | Score |
| --- | --- | --- | --- | --- |
| [CVE-2024-51567](https://nvd.nist.gov/vuln/detail/CVE-2024-51567) | Oct 2024 | 2.3.8 | Unauthenticated command execution as root; exploited, in CISA KEV | 9.8 (NVD) |
| [CVE-2024-51378](https://nvd.nist.gov/vuln/detail/CVE-2024-51378) | Oct 2024 | 2.3.8 | Same, via DNS/FTP reset endpoints; exploited, in CISA KEV | 9.8 (NVD) |
| [CVE-2024-51568](https://nvd.nist.gov/vuln/detail/CVE-2024-51568) | Oct 2024 | 2.3.5 | Unauthenticated command injection via file manager upload | 9.8 (NVD) |
| [CVE-2024-53376](https://nvd.nist.gov/vuln/detail/CVE-2024-53376) | Dec 2024 | 2.3.8 | Logged-in users run commands through the PHP selection field | 8.8 |
| [CVE-2026-41473](https://nvd.nist.gov/vuln/detail/CVE-2026-41473) | Apr 2026 | 2.4.5 | Unauthenticated writes to the database via AI Scanner endpoints | 9.1 (NVD) |
| [CVE-2026-71965](https://nvd.nist.gov/vuln/detail/CVE-2026-71965) | Aug 2026 | after 2.4.3 | Logged-in user writes an SSH key to `/root/.ssh/authorized_keys` via remote backup | 8.8 |
| [CVE-2026-67614](https://nvd.nist.gov/vuln/detail/CVE-2026-67614) | Aug 2026 | 3.0.0 | Hard-coded Web Terminal JWT secret: unauthenticated root shell on port 8888 | 9.8 |
| [CVE-2026-67613](https://nvd.nist.gov/vuln/detail/CVE-2026-67613) | Aug 2026 | 3.0.0 | Admins read any file readable by the root-privileged panel process | 4.9 |
| [CVE-2026-87820](https://nvd.nist.gov/vuln/detail/CVE-2026-87820) | Sep 2026 | 2.4.6 | Unauthenticated disclosure of admin usernames and API-key prefixes | 5.3 |
| [CVE-2026-88895](https://nvd.nist.gov/vuln/detail/CVE-2026-88895) | Sep 2026 | 3.0.5 | API accepted password-derived tokens without the 2FA code | 7.2 |

Some notes on the table:

- The most serious 2026 issue is **CVE-2026-67614**. The [VulnCheck advisory](https://www.vulncheck.com/advisories/cyberpanel-hard-coded-jwt-secret-authentication-bypass-via-webterminal) describes a hard-coded secret in the Web Terminal service: anyone could forge a token with `ssh_user=root` and get an interactive root shell over WebSocket on port 8888. The 3.0.0 changelog (August 9, 2026) says Web Terminal authentication and token validation were hardened, and 3.0.2 added a one-time authorization for the terminal.
- **CVE-2026-88895** matters if you rely on 2FA. The [GitHub advisory GHSA-h2f7-38ww-5pwc](https://github.com/usmannasir/cyberpanel/security/advisories/GHSA-h2f7-38ww-5pwc) says 3.0.4 and earlier accepted password-derived API tokens without the TOTP code. 3.0.5 (August 26, 2026) enforces 2FA on the API, makes API keys random and rotates legacy keys during the upgrade, so integrations need the new key and an OTP header.
- Several 2026 CVEs, such as [CVE-2026-65917](https://nvd.nist.gov/vuln/detail/CVE-2026-65917), are tenant-isolation bugs: one panel user could read or delete another tenant's backups. That is important if you give customers their own CyberPanel logins.
- At the time of writing, none of the 2026 CVEs is in the CISA KEV catalog (NVD shows no KEV date for them). That means no confirmed mass exploitation has been recorded, not that they are harmless.
- We found no CVE published in calendar 2025 that names CyberPanel.

To be fair: CyberPanel now publishes GitHub security advisories, credits researchers, and released eight 3.0.x builds between August and October 2026, several of them with security fixes. That is a project that fixes things. The weak point is architectural: the panel process runs with root rights, as the CVE-2026-67613 description itself says, so an injection bug anywhere in it lands as root.

## How to check whether a CyberPanel server was compromised

Run these checks on any server that ran CyberPanel 2.3.7 or older in late 2024, or any version before 3.0.0 with port 8888 open. They are a quick triage, not a forensic investigation.

| What to look for | Command | Why |
| --- | --- | --- |
| PSAUX key files | `ls -la /var/key.enc /var/iv.enc` | PSAUX stored its encrypted AES key and IV here ([BleepingComputer](https://www.bleepingcomputer.com/news/security/massive-psaux-ransomware-attack-targets-22-000-cyberpanel-instances/)) |
| Ransom note at login | `cat /etc/motd` | The note was copied to `/etc/motd` and written as `index.html` in folders |
| Encrypted files | `find /home -name '*.psaux' -o -name '*.encryp' -o -name '*.locked' \| head` | Extensions reported for the 2024 wave |
| Requests to the exploited endpoints | `grep -E 'upgrademysqlstatus\|getresetstatus' /usr/local/lscp/logs/access.log*` | The panel runs on lscpd; these paths carried the 2024 exploit |
| Unknown root SSH keys | `cat /root/.ssh/authorized_keys` | CVE-2026-71965 wrote an attacker key here |
| Persistence | `crontab -l -u root; ls -la /etc/cron.d /etc/systemd/system` | Attackers add cron jobs and services to come back |
| Miners and odd processes | `ps aux --sort=-%cpu \| head -15` and `ss -tlnp` | Miners were seen in 2024; look for unknown listeners |
| Panel users | Users list in the CyberPanel admin | Look for admin accounts you did not create |

Old log files may already be rotated away, so an empty result is not proof the server is clean. If anything turns up, treat the server as lost: an attacker who had root can hide in places these commands do not show. Do not try to clean it in place. Build a new server, restore sites from a backup taken **before** the compromise, change every password and API key (panel, SSH, databases, mailboxes, WordPress admins), and scan the restored sites. Our [WordPress malware cleanup guide](/blog/wordpress-malware-cleanup) covers the site side.

## How to harden CyberPanel if you stay

If the server is clean and you want to keep CyberPanel, do these in order.

1. **Update to the latest release.** The official command from the [project README](https://github.com/usmannasir/cyberpanel) is:

   ```bash
   sh <(curl https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh || wget -O - https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh)
   ```

   Then compare your build with the [changelog](https://cyberpanel.net/KnowledgeBase/home/change-logs/). Anything before 3.0.5 misses the 2FA fix; anything before 3.0.0 has the Web Terminal flaw.
2. **Close ports 8090 and 8888 to the public.** Allow them only from your office IP or a VPN, in the server firewall or, better, in your provider's cloud firewall so the rule holds even if the server's firewall is changed. The 2024 attacks only worked against servers whose panel port answered anyone.
3. **Turn on 2FA** for every admin, and after upgrading to 3.0.5 or later replace the API keys used by integrations, since legacy keys are rejected.
4. **Remove panel users you do not need**, and do not give untrusted customers panel logins on a server that also hosts your own sites, given the 2026 tenant-isolation bugs.
5. **Keep backups off the server** and test a restore. Ransomware encrypts local backups too. Our [website backup strategy](/blog/website-backup-strategy) explains the 3-2-1 approach.
6. **Watch the advisories**: subscribe to the repository's security advisories on GitHub so you hear about the next fix the day it ships.

These steps apply to every control panel, ZoPanel included. A panel that is not reachable from the internet is very hard to exploit, whatever its bugs.

## When to move off CyberPanel

Staying is reasonable for a single server with your own sites, patched and firewalled. Moving makes sense when:

- **the server was exposed while vulnerable** and you cannot rule out compromise; you have to rebuild anyway, so rebuild on the panel you want;
- **you host customers** and need strong isolation between tenants, which the 2026 backup bugs put in question;
- **you cannot keep the panel firewalled**, for example because customers log in from anywhere;
- **you would rather a panel bug not mean root**. That is a question of architecture, which we cover in [why a hosting control panel should never run as root](/blog/secure-hosting-panel-architecture).

ZoPanel was built around that last point. Its web interface runs as an unprivileged user, and a separate root agent accepts only a fixed list of actions and re-validates every parameter. Each hosting account is its own Linux user with its own PHP-FPM pool and a systemd slice with CPU, memory and process limits. It includes a WAF (ModSecurity), malware scanning, 2FA with an enforceable policy, a panel IP allowlist and signed updates with automatic rollback ([security docs](/docs/security), [security features](/features/security)). Its honest limits: it is newer, so it has a shorter public audit history than older panels; it runs only on Ubuntu and Debian with nginx (Apache is optional per site); and it does **not** import CyberPanel backups, so you move sites by hand. Plan the switch with [how to migrate a website without downtime](/blog/migrate-website-without-downtime).

## Conclusion

CyberPanel is not unsafe by default in 2026, but it is unforgiving. Its developers patch fast, yet the panel runs as root and has had unauthenticated root-level bugs in both 2024 and 2026. If you stay, run the latest 3.0.x build, keep ports 8090 and 8888 closed to the public, enable 2FA and keep tested off-site backups. If a server ran unpatched and exposed, rebuild it.

If you are rebuilding anyway, you can try ZoPanel on the new server: the [Free plan](/pricing) covers 3 hosting accounts, 10 websites and 10 databases with no time limit, enough to move a few sites and compare.

## Frequently asked questions

### Is CyberPanel safe to use in 2026?

It can be, if you run the latest release (3.0.8 at the time of writing) and restrict ports 8090 and 8888 to trusted IPs. Versions before 3.0.0 have an unauthenticated root-shell flaw in the Web Terminal (CVE-2026-67614), and versions before 3.0.5 let the API skip 2FA. An old, internet-facing CyberPanel is not safe.

### Was the CyberPanel ransomware attack fixed?

Yes. The flaws used in October 2024 (CVE-2024-51567 and CVE-2024-51378) are fixed in 2.3.8, released November 1, 2024. The fix does not undo damage: servers that were hit had files encrypted and must be restored from backups or decrypted with the PSAUX decryptor where it works.

### How do I know if my CyberPanel server was hacked?

Look for `/var/key.enc` and `/var/iv.enc`, a ransom note in `/etc/motd`, files ending in `.psaux`, `.encryp` or `.locked`, unknown keys in `/root/.ssh/authorized_keys`, and requests to `upgrademysqlstatus` or `getresetstatus` in `/usr/local/lscp/logs/`. If you find any of them, rebuild the server rather than clean it.

### Which port does CyberPanel use, and should I close it?

The admin panel listens on port 8090, and the Web Terminal used port 8888. Allow both only from your own IP or a VPN, ideally in your cloud provider's firewall. This single step would have protected most servers hit in 2024.

### Is CyberPanel safer than other free panels?

Every popular free panel has had serious vulnerabilities, so the comparison that matters is how fast fixes ship, how easy updates are, and what an attacker gets when a bug is found. CyberPanel now ships fixes and advisories quickly, but its panel runs as root. Compare panels on architecture as well as features.