Dear Client,

read with extra caution and take necessary action if required.

⚠️ On 28 April 2026, cPanel disclosed a critical authentication bypass vulnerability CVE-2026-41940 (CVSS 9.8) affecting all supported versions of cPanel & WHM. The flaw had been actively exploited in the wild for weeks before the public advisory. info at : https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026

✅ Before doing anything else make sure to update cPanel to latest version or close all your WHM & cPanel ports . to update cpanel run :

/scripts/upcp --force

if you cannot update right now, block inbound traffic on ports 2083, 2087, 2095, and 2096 at the firewall or run : 

whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && whmapi1 configureservice service=cpdavd enabled=0 monitored=0 && /scripts/restartsrv_cpsrvd --stop && /scripts/restartsrv_cpdavd --stop

During our review on some servers provided to us, we confirmed that hackers are scanning servers (which have not updated to latest cpanel version) and inserting a botnet called nuclear.x86 , the hacker did :

  1. Downloaded a Linux botnet binary called nuclear.x86 from

     hxxp://87.121.84.78/nuclear.x86 and hxxp://45.148.120.23/nuclear.x86

  2. Made it executable (chmod 777) and ran it as ./nuclear.x86 xd

  3. Deleted the binary from disk to hide their tracks (rm -rf nuclear.x86)

  4. Re-downloaded and re-ran the binary multiple times across the day

  5. Then performed full reconnaissance on your account.

The command history shows the attacker read the contents of the following files. You must assume everything in them is now in the attacker's possession:

  • /etc/shadow - all local account password hashes

  • /root/.ssh/authorized_keys - list of who can SSH in as root

  • /root/.ssh/authorized_keys2

  • /root/.ssh/id_rsa - PRIVATE SSH KEY (RSA)

  • /root/.ssh/id_ed25519 - PRIVATE SSH KEY (Ed25519)

  • /root/.ssh/id_ecdsa - PRIVATE SSH KEY (ECDSA)

  • /root/.ssh/id_dsa - PRIVATE SSH KEY (DSA)

  • /root/.ssh/config - your SSH connection shortcuts

  • /root/.ssh/known_hosts - every server you have ever SSH'd into

  • All shell history files (.bash_history / .zsh_history / .sh_history /

    .fish_history) under /root and /home

  • /proc/1/environ - environment variables

  • Full process list, network interfaces, listening ports, Docker images

    and containers, login records (lastlog / last / w).

This means: any SSH key on the server, any password stored on the server, and anything you ever typed on the command line (including passwords pasted inline) must now be considered compromised.

WHY wget google.com AND curl google.com and even license commands like LcLicenseCP SHOW "Killed"

If you tried running:

    wget google.com

    curl google.com

or any wget and curl related commands from SSH and got back the response Killed, that is the malware itself doing it. The nuclear.x86 binary actively monitors the system for wget, curl and similar tools and kills them on sight. This is standard behaviour for this family of Linux botnets. it is how the malware prevents rival botnets, and you, from downloading anything that could clean it off.

In other words: as long as Killed appears, nuclear.x86 is still running on your account. Once it is killed, wget and curl work normally again. That is the fastest way for you to confirm the cleanup worked.

⚠️ WHAT YOU MUST DO RIGHT NOW

1) KILL THE RUNNING MALWARE (this is also what fixes wget/curl)

   Log into SSH and run:

pkill -9 -f "./nuclear.x86"

pkill -9 -f "nuclear.x86"

ps auxf | grep -i nuclear

   The first two commands force-kill the malware. The third confirms

   nothing is left running. if it shows any matching process other than

   the grep itself, contact us immediately.

   To verify the kill worked, run:

  wget google.com

   If it now downloads instead of saying Killed, the malware process

   is gone. (The binary on disk is already deleted by the attacker, so

   there is no file to remove - only the running process.)

after that you can enable your cpanel license by running : LcLicenseCP

2) REMOVE THE STOLEN SSH KEYS AND GENERATE NEW ONES

The attacker has copies of your private SSH keys. Those keys must be

   considered burned. they can be used to log into anywhere you have ever

   pushed them (GitHub, GitLab, Bitbucket, other servers, deployment

   targets, backup servers, etc.).

   On the affected server, as root, run:

       # Back up the old .ssh folder before wiping it

cp -a ~/.ssh ~/.ssh.compromised.$(date +%Y%m%d)

       # Remove every stolen key file

rm -f ~/.ssh/authorized_keys ~/.ssh/authorized_keys2

rm -f ~/.ssh/id_rsa ~/.ssh/id_rsa.pub

rm -f ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

rm -f ~/.ssh/id_ecdsa ~/.ssh/id_ecdsa.pub

rm -f ~/.ssh/id_dsa ~/.ssh/id_dsa.pub

rm -f ~/.ssh/known_hosts

       # Generate a new key

ssh-keygen -t ed25519 -C "new-key-$(date +%Y%m%d)"

   Then add the NEW public key (~/.ssh/id_ed25519.pub) to:

     - GitHub / GitLab / Bitbucket. and DELETE the old key there

     - Any other server you log into from this one

     - Any deployment / CI service that trusted the old key

3) ROTATE EVERY PASSWORD AND TOKEN

     - cPanel password

     - All FTP / SFTP user passwords

     - All email account passwords

     - All MySQL / database user passwords (and update wp-config.php,

       .env files, config.php, etc. accordingly)

     - Any API key, SMTP password, or webhook secret stored in

       config files, .env files, or environment variables

     - WordPress / Joomla / admin panel passwords for every site

4) AUDIT YOUR ACCOUNT FOR PERSISTENCE

   The attacker may have left back doors. Please check:

     - cPanel → Email Forwarders (any forwarder you didn't create)

     - cPanel → Cron Jobs (any cron you didn't create)

     - cPanel → FTP Accounts (any account you didn't create)

     - cPanel → SSH Access (any extra keys)

     - File manager: anything new in public_html, especially .php files

       with random names, or files modified in the last 7 days that you

       didn't change

5) IF YOU REUSED YOUR CPANEL/SSH PASSWORD ANYWHERE ELSE

   Change it on those other services too. The attacker has the hash and

   will attempt to crack it.

????‍???? IF YOU NEED HELP

If you are not comfortable running the commands above, open a support ticket and we will perform the cleanup for you. Please do not ignore this notice - the SSH key theft in particular extends beyond this server.

⚠️⚠️⚠️ The root cause was a zero-day security issue by cPanel.net's development team . no hack/access/attack was happened to LC servers as we already blocked WHM and cPanel logins on our servers using our own LC lib files , we used this to protect our servers from any cpanel staff member access backdoor (if existed) . the mentioned issue is happening to many servers even with original cpanel license (so please ignore any false information stating that this only happened to users of shared licensing products). We already discovered this botnet in cPanel servers with original licenses and cPanel has confirmed the issue on their side.

share this info to anyone who you think has been effected by cPanel security issue.

Kind Regards,

https://licensecage.com