CVE-2026-41940: The cPanel Exploit That Could Delete Your Backups
A critical authentication bypass in cPanel gave attackers root access to millions of servers. If your backups lived on the same server as your Magento store, they were just as exposed as the site itself.
CVE-2026-41940 — CVSS 9.8 (Critical)
Disclosed April 28, 2026. Actively exploited in the wild from at least February 2026. All supported cPanel versions after 11.40 affected. Patch is available — contact your host to confirm your server has been updated.
What happened
On April 28, 2026, security researchers at WatchTowr Labs published a full technical disclosure of CVE-2026-41940 — a critical authentication bypass in cPanel and WebHost Manager (WHM). The vulnerability scores 9.8 on the CVSS scale, which puts it in the top tier of severity.
cPanel is the control panel software used by an estimated 70 million domains worldwide. If your Magento store is hosted on a shared or managed server that uses cPanel, this is directly relevant to you.
The exploit was already being used in the wild from at least February 2026 — two months before the patch was released. That means there was a window during which attackers could have accessed affected servers without leaving conventional signs of a breach.
How the exploit works
CVE-2026-41940 is a CRLF injection vulnerability — CRLF stands for Carriage Return Line Feed, the character sequence used to mark the end of a line in many protocols and file formats.
The flaw existed in cPanel's login and session handling process. By sending a specially crafted request with CRLF characters injected into an authorisation header, an attacker could manipulate the session file that cPanel wrote to disk — inserting arbitrary properties, including user=root, without needing a password.
The result: the attacker is authenticated as root. They have complete control of the server — every file, every database, every website hosted on that machine, and every cPanel account on it.
cPanel released a patch within hours of the disclosure going public. But for servers that were exploited during the February–April window, the damage may already have been done.
The backup problem nobody talks about
Most hosting providers take regular backups. Most merchants assume those backups will save them if something goes wrong. And for most scenarios — a bad deployment, a corrupted database update, an accidental file deletion — they will.
But here is the problem: on many cPanel hosting setups, the backup is stored on the same server as the live site.
If an attacker has root access, they own the backups too.
Root access means unrestricted access to every file on the server. A backup stored on the same machine as your live site is not protected — it is part of the same attack surface. An attacker with root can delete backups, encrypt them for ransom, or silently exfiltrate them before you realise anything is wrong.
This is not a theoretical concern. Ransomware operators routinely target backup directories as a first step — eliminating your recovery options before demanding payment. When the backup lives on the same server as the compromised data, a single exploit removes both your site and your safety net in one move.
CVE-2026-41940 made this risk concrete. An attacker with root access to a cPanel server had everything they needed to destroy backups before a merchant even noticed they had been breached.
What a safe backup strategy looks like
A backup only protects you if it exists somewhere that a server compromise cannot reach. That means separation — physically and logically — between your live server and your backup copy.
Layer 1 — Host backup
Your hosting provider should take automated daily backups stored on a separate backup server, not on the live machine. Ask your host explicitly: where are my backups stored? If the answer is on the same server, that is a gap worth closing.
Layer 2 — Offsite backup under your control
Separately, you should maintain your own backup copy — stored on a provider and under credentials that your hosting company does not control. If your host is compromised, your offsite backup is unaffected. Options include Backblaze B2, Amazon S3, or Dropbox Business. A weekly automated export of your Magento database and media files, pushed to a separate bucket, is sufficient for most merchants.
Layer 3 — Test your restores
A backup you have never tested is a backup you cannot trust. At minimum, once a quarter, confirm that you can actually restore from your offsite copy. The middle of a security incident is not the time to discover your restore process is broken.
What to do if your store is on cPanel hosting
If your Magento store is currently on a cPanel-based server, take these steps now:
- 1.Contact your host and ask them to confirm when CVE-2026-41940 was patched on your server and whether any unauthorised access was detected before the patch was applied.
- 2.Review your server and Magento admin logs for any unusual activity between February and April 2026 — unexpected admin account creation, file modifications, or database exports.
- 3.Check that a recent backup exists and, crucially, that it was taken from before any potential compromise window.
- 4.Verify where your backups are stored. If they are on the same server as your live site, arrange for offsite copies to be taken immediately.
- 5.Change all admin passwords — cPanel, WHM, Magento admin, FTP, database — as a precaution.
EveryHost dedicated Magento servers are not affected
Our dedicated Magento servers run a custom-managed stack built specifically for Magento Open Source — NGINX, Varnish 7.7, OpenSearch 3, Redis or Valkey 8, PHP 8.4, and NVMe SSD on physical hardware in UK data centres. CVE-2026-41940 does not affect customers on our dedicated Magento plans. If you are unsure which environment your store is on, contact us directly and we will confirm.
Access to your dedicated server is controlled and audited directly by our engineers — not provisioned through a shared web-based control panel.
That said, we always recommend that every Magento merchant — regardless of host — maintains their own offsite backup under their own control. No host is immune to security incidents. Separation is the protection.
Further reading
Frequently asked questions
What is CVE-2026-41940?+
CVE-2026-41940 is a critical authentication bypass vulnerability in cPanel and WebHost Manager (WHM) with a CVSS score of 9.8. It was caused by a CRLF injection flaw in the login and session handling process. An attacker could bypass authentication entirely and gain root-level access to the server without valid credentials.
Can hackers delete backups using CVE-2026-41940?+
Yes. Because CVE-2026-41940 grants root access to the entire server, an attacker has full control over every file on that machine — including any backups stored on the same server. Backups stored locally are not protected once an attacker has root. They can be deleted, encrypted for ransom, or exfiltrated. This is why offsite backups — stored completely separately from your hosting environment — are essential.
Am I affected if my Magento store uses cPanel hosting?+
If your Magento store is hosted on a cPanel or WHM server that was not patched before April 28, 2026, you may have been exposed. The vulnerability was exploited in the wild from at least February 2026. Contact your host to confirm when their servers were patched, check for unauthorised access or file changes, and ensure you have a recent offsite backup.
Does CVE-2026-41940 affect EveryHost customers?+
CVE-2026-41940 does not affect customers on our dedicated Magento plans. Our dedicated Magento servers run a custom-managed stack — NGINX, Varnish 7.7, OpenSearch 3, Redis/Valkey 8 and PHP 8.4. If you are unsure which environment your store is on, contact us directly and we will confirm.
What backup strategy should a Magento merchant use?+
A safe Magento backup strategy requires at least two layers: an automated server-level backup taken by your host, stored on a separate backup server; and a separate offsite backup stored completely outside your hosting environment — on a different provider, under your own control. If both backups live on the same server or account, a single security breach can eliminate them both. Supplement host backups with your own offsite copy using Backblaze B2, Amazon S3 or similar.
Move to dedicated Magento hosting without cPanel
Dedicated hardware, no shared control panels, Magento engineers who know your server. Call us or view our plans.