I had earlier decided to just give up on Cyberpanel because I can’t deal with this headache again but I found a solution to protect myself.
systemctl stop lscpd
Ta-da! I rarely need Cyberpanel so why should it just keep running always? The website will work fine because they are powered by Litespeed. I can start CyberPanel when I need it and then shut it down.
If only I had thought of it before. Ugh
Seems to work for me. I had restored my server from a snapshot a few times now and after a short time the console kicked me out and I could no longer access it. Now I have stopped the lscpd.service with systemctl stop lscpd directly after a restore and the server is working normally again. This gives you time to wait for a working patch.
If your hoster supports it, you can setup a firewall and only allow your ip to connect to port 8090 and 7080.
For Example: https://docs.hetzner.com/robot/dedicated-server/firewall#how-do-i-activate-the-firewall
This is configured through the hetzner robot, there is not needed to access the server via ssh.
This way, no one else can access the cyberpanel and litespeed web panel.
Possible for dedicated and cloud servers.
I don’t know if other hosters are offering something like this.
I had installed ufw and left ports 21, 22, 80 and 443 open. But somehow I no longer had access after that. Stopping lscpd seems to work for me. I was also able to upgrade to v2.3.8 (yesterday), which didn’t help before. Of my four processors, one was always at 100% and I could no longer get access.
I think I’ll activate lscpd again now and see if it blows up in my face again. Trial makes perfect. 
Doesn’t look good, the patch doesn’t seem to work yet. After restarting my server with v2.3.8 the CPU load seems normal again, but I still can’t get access. So backup again and quickly stop lscpd.
Restore has worked and the server is working normally. You have to be pretty quick because the server shuts down after a short time. For whatever reason. A simple systemctl stop lscpd is not enough, because otherwise lscpd will be started again the next time the server is started. Therefore it is best to disable the autostart service with systemctl disable lscpd as well. Good luck out there.
Seems like your system is infected then most likely the miner kdevtmpfsi
If possible, do a clean reinstall of the OS + cyberpanel and restore sites. This is the path I have gone through, I was lucky to not be hit with the encrypted ransomware though
Also change cyberpanel port from 8090 should help
My backup was apparently a few hours older when the attack on my server began. After receiving the abuse notification from my hosting provider, I quickly took a snapshot on October 28th before I applied the patch v2.3.7. At first everything went well and a few hours later my server suddenly started spinning up a CPU. So I was lucky in misfortune. I was also able to back up current data later before I lost access. It doesn’t seem to be encrypted for me either. My server is now behaving normally and access is working fine. lscpd is down, now I have to wait until a working patch is available.
Hello everyone,
I’d like to share my experience regarding the recent CyberPanel vulnerabilities in case it might be useful to others. With the RCE (Remote Code Execution) vulnerability that triggered a wave of attacks, I implemented certain security configurations that, I believe, may have helped me avoid the overloads and disruptions reported by other users. Here are the measures I set up from the start to strengthen my server’s protection.
Security Measures Implemented
Reverse Proxy with OpenLiteSpeed (link for tutorial) and Additional Geographic Filtering via Cloudflare
Upon installing CyberPanel, I configured a reverse proxy with OpenLiteSpeed and added Cloudflare for additional security. Through Cloudflare, I set up strict geographic filtering to allow only connections from my home country, the server’s hosting country, and the United States (required for Cloudflare services). All other traffic is blocked, reducing exposure to threats from unauthorized regions.
Restricting Open Ports to Essentials Only
Since my server only hosts a website and a web application, I restricted open ports to:
• Ports 80 and 443 for HTTP and HTTPS traffic.
• Port 587 in TCP for outgoing email.
All other ports are blocked, which theoretically reduces the attack surface available to potential threats.
Additional Geographic Blocking via CSF (ConfigServer Security & Firewall)
To complement Cloudflare, I used CSF to block connections from high-risk regions, setting the CC_DENY directive to further limit access attempts from specific countries.
OpenLiteSpeed Realm Authentication for Panel Access
I configured the OpenLiteSpeed “Realm” authentication, adding an extra password prompt before accessing the management interface. This layer should limit unauthorized access attempts by adding an additional authentication step.
SSH Security Reinforcement with Fail2Ban and a Dedicated Sudo User
I disabled direct root access for SSH, requiring a dedicated sudo user for all SSH connections. Additionally, I configured Fail2Ban to permanently ban any IP address after three failed login attempts.
This setup allowed me to collect logs revealing thousands of brute-force attempts, with numerous IPs primarily from countries such as China, India, Vietnam, Bangladesh, Brazil, and Bulgaria, though other regions were represented as well. These were the most frequently flagged sources of access attempts on my server. With Fail2Ban, all these IPs are automatically blocked and permanently banned after three failed attempts.
Two-Factor Authentication and Robust SSH Keys
Additionally, I enabled two-factor authentication (2FA) with Google Authenticator for CyberPanel users and disabled password-based SSH access, enforcing the use of an ed25519 SSH key for enhanced connection security.
Automatic Security Updates
I also set up automatic security updates to ensure my server remains protected against newly discovered vulnerabilities.
Results and Observations
Since implementing these measures, my server has remained stable, with no overloads or downtimes. Fail2Ban logs indicate that these protections may have worked effectively, with thousands of brute-force attacks blocked automatically after three failed attempts. Filtering through Cloudflare, CSF, and enhanced authentication appear to have helped limit unauthorized connections, contributing to my server’s stability.
Recommendations for CyberPanel Users
In the hope that this might be helpful, here are a few suggestions:
• Update CyberPanel regularly to benefit from the latest patches.
• Use a reverse proxy and geographic filtering: OpenLiteSpeed as a reverse proxy, combined with Cloudflare’s geographic blocking and CSF, can help reduce unauthorized access.
• Limit open ports to essentials and add Realm authentication on OpenLiteSpeed for added protection.
• Use sudo users, strong SSH keys, and enable two-factor authentication: These measures enhance connection security and restrict unauthorized access.
These practices seem to have effectively protected my server, and I hope they may also be useful for securing your own setup.
Additionally, my passwords are never shorter than 64 characters (generated through Bitwarden for optimal security), and my server is encrypted at rest to further reduce intrusion risks, even in the case of DDoS attacks.
Ok, maybe I got a little too excited too soon. After I patched to v2.3.8. everything went well at first. And then suddenly I got the login:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
…
Fuck… I thought. Well, to test it, I restarted the server once, deleted the key and tried again. No luck, no access. Then I will probably have to set up a completely new server. 
These are great suggestions, I like the fail2ban login attempt and geographic limiting. One of my personal use site was also hacked which shouldn’t have happened at all as I only use it myself, going to use geographic filtering on that.
I also changed cyberpanel port
I made a tutorial on how to properly configure Fail2Ban if you’re interested. 
https://community.cyberpanel.net/t/quick-analysis-of-ips-blocked-for-brute-force-attempts-on-a-newly-configured-server/56341/3?u=mhdev
Info: So it turns out Cyberpanel has a habit of restarting itself. To solve this, go to
/etc/systemd/system
Edit lscpd.service (MAKE SURE YOU BACKUP THIS FILE SOMEWHERE AND KNOW ITS LOCATION === YOU WILL COMPLETELY BORK YOUR CYBERPANEL INSTALL OTHERWISE!!!)
to
[Unit]
Description = LSCPD Daemon
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
ExecStart =
ExecStop =
#ExecReload=
[Install]
WantedBy=default.target
You can just empty the file as well.
Now cyberpanel will not be able to restart itself anymore and stay offline unless you want to run it (undo the steps above by restoring the original file).
Enjoy
@mhdev
Hi, thanks for your cooperation. Does this work (Reverse Proxy with OpenLiteSpeed) with naked HTTP IP access too? Or it only works if I have a hostname domain attached to cyberpanel login?
This topic was automatically closed 3 hours after the last reply. New replies are no longer allowed.