cPanel flaw: why, after restoring, you must look for the back door left open
In late April 2026 a critical cPanel flaw put a huge share of web servers at risk. Updating and restoring are not enough. What to look for, what to ask your hosting provider and why you need forensic analysis.

In late April 2026 cPanel fixed a critical flaw, CVE-2026-41940, that let attackers gain administrator access without knowing the password. cPanel is the control panel used to run a large share of websites and online shops. According to accounts published at the time, the flaw was probably being exploited as early as 23 February, two months before the fix. Anyone with a website on a cPanel server therefore has two jobs, not one. They must update, and they must check that nobody has already got in. A backup brings the site back online. Only forensic analysis, meaning the technical reconstruction of what happened, can tell you whether the restored copy still contains the door the attacker left open.
What happened, in brief?
Most people got through that week without noticing a thing. For those who run web servers, it was a race to update and check.
| Date (2026) | Event | Source |
|---|---|---|
| from 23 February | first exploitation, suspected by a hosting provider, before the flaw was known | Rapid7, Help Net Security |
| 28 April | cPanel releases the security update for cPanel & WHM and WP Squared | Rapid7, CyberScoop |
| 29 April | the flaw is published in the NVD database as CVE-2026-41940, with a severity of 9.8 out of 10 (CVSS 3.1) | NVD, Rapid7 |
| 30 April | CISA adds it to its catalogue of known exploited vulnerabilities | NVD, CyberScoop |
| 1 May | the Shadowserver Foundation counts about 650,000 addresses with exposed cPanel panels | Help Net Security |
Using data from the Shodan search engine, Rapid7 estimated that about 1.5 million cPanel instances could be reached from the internet. It could not say how many of them were vulnerable. Every version after 11.40 was affected. cPanel’s advice was unequivocal. Customers should update immediately, check the installed version, restart the panel service and run the script it supplied to look for signs of compromise.
How can a closed flaw leave a door open?
An update fixes the error. It does not undo what an attacker did while the error was open. With administrator access to a control panel, an attacker can create new accounts and generate access keys for programs (API tokens). They can add SSH keys to log in to the server, schedule automated tasks and upload files to the websites’ folders. Those files often include a web shell. This is a small page that runs commands on the server when someone calls it from outside.
These back doors can lie dormant for weeks, waiting to be used or sold on. This is not a textbook hypothesis. Mandiant’s M-Trends 2026 report, published in March 2026, ranks prior compromise as the third most common way in worldwide in 2025 (10% of intrusions) and as the most common in ransomware attacks (30%). Attackers often walk through a door that someone else opened months earlier.
A typical scenario: the online shop that breaks twice
This scenario is built on how these attacks unfold. It is not a real case. A company sells through an online shop hosted on a server managed with cPanel. One Saturday morning the orders stop, because the payment page sends customers somewhere else. The hosting provider updates the panel, restores the previous night’s backup and the site is back online the same day. Everyone breathes a sigh of relief.
Two weeks later the problem is back. The restored copy was clean only on the surface. It contained a web shell uploaded in March, when the flaw was already being exploited but was not yet known. The backup had saved the day. What was missing was the work that saves the next day. That work means finding out how long the attacker had been inside, what they had left behind and what they had read.
The same logic runs through the three pillars described in our article on why backup alone is not enough. A backup lets you start again. It does not tell you whether you are starting again from a healthy state.
What should you check on a cPanel server after updating?
If your hosting provider manages the server, most of the checks are its responsibility, but the company must ask for the results. If the server is managed in-house, this is the list:
- The version. The installed build must be one of the fixed ones, and the panel service must have been restarted, as cPanel instructs.
- The indicators of compromise. Run the script provided by cPanel and keep the output.
- Accounts and access. Check panel users and resellers, API tokens, SSH keys, FTP accounts and mailboxes created or changed after 23 February, the date of the first suspected exploitation.
- Scheduled tasks and processes. Look for automated jobs that nobody ever set up, and running programs that nobody recognises.
- The website files. Look for recently modified files, especially executable files in upload folders. Check the payment pages too, where a few lines of added code can copy card details.
- The logs. Review access to the panel and to the web server from 23 February onwards, if those logs still exist. This is why it pays to keep them for a long time and somewhere else, as our article on Sherlock Holmes and the log files explains.
- The credentials. Set new passwords for the panel, databases, email and any linked payment services. Close open sessions and regenerate API keys.
- Exposure. Restrict access to the panel to the company’s own addresses or to a virtual private network. It should not be open to the whole internet.
Which copy should you restore from?
Restore from the most recent one that certainly predates the attacker’s first access. The problem is that, at the start, nobody knows that date. If exploitation began in February, an April copy may already contain the back door. That is why you restore piece by piece, not all at once.
| What | Where to restore it from | What to check |
|---|---|---|
| Application (website code, theme, extensions) | original, up-to-date packages from the vendors | no files added compared with the original |
| Content and database | the latest copy, after a check | administrator users, scripts inserted into pages |
| Panel configuration | settings reviewed by hand | accounts, keys, scheduled tasks |
| Credentials | all new | no password reused from before |
The timeline reconstructed by forensic analysis shows the point from which a copy can be trusted. It also answers the question that matters to the lawyers. Which data was read or copied?
What should you ask your hosting provider?
Many companies do not run their own server, but they are still responsible for the website and for their customers’ data. Here are six questions to ask in writing:
- On what date did you install the update on our server?
- Did you run cPanel’s indicators-of-compromise script, and what did it find on our account?
- How long do you keep the access logs for the panel and the web server?
- From what date are backups available, and where are they stored?
- Who else, apart from you, has administrative access to the server?
- How, and how quickly, will you tell us if you find something?
The answers say a great deal about the quality of the provider. Keep them with the incident documentation.
Are there notification obligations?
It depends on what was touched. An online shop processes its customers’ personal data. If there has been unauthorised access, the GDPR requires the breach to be notified to the supervisory authority within 72 hours of discovery, where feasible, unless the breach is unlikely to result in a risk to people. In Italy that authority is the Italian Data Protection Authority (Garante). If the risk is high, the people affected must be told as well. Companies subject to NIS2, the EU directive on network and information security, also face deadlines for reporting significant incidents to CSIRT Italia, Italy’s national computer security incident response team. The assessment is made with the data protection officer (DPO) and the lawyers. For businesses in San Marino the framework is different and must be assessed case by case.
In brief
- CVE-2026-41940 let attackers into cPanel panels as administrators without a password. The fix was released on 28 April 2026.
- The first suspected exploitation dates back to 23 February. Updating is not enough. You must look for whatever the attacker may have left behind.
- A back door survives the update and often survives a restore from backup as well.
- The checks cover the version, indicators of compromise, accounts, keys, scheduled tasks, website files, logs and credentials.
- You restore piece by piece. The application comes from original sources, the data comes back after a check and every credential is new.
- If customer data is involved, notification to the Garante must be assessed within 72 hours.
Frequently asked questions
Our website does not use cPanel. Are we safe?
From this flaw, yes. But the lesson applies to any control panel exposed to the internet. It is worth knowing which panel your provider uses, how it is updated and who can reach it.
If our hosting provider has already updated, do we need to do anything?
Yes. Ask for the results of the indicator-of-compromise checks on your account, check the users and files on your website and change your credentials. The update closes the flaw. It does not tell you whether someone got in before.
Is antivirus on the server enough to find a back door?
Not always. A web shell can be a file of just a few lines, similar to the website’s legitimate files. You need to compare files with the originals, analyse the logs and check accounts, keys and scheduled tasks.
How far back do we need to look in the logs?
Look back at least to 23 February 2026, the date of the first suspected exploitation, and further back if earlier signs emerge. If the logs do not go back that far, the report must say so clearly. It is a limit of the investigation.
Do we need to rebuild the website from scratch?
Not always. It is often enough to reinstall the application from original packages, restore the content after a check and change every credential. The choice depends on what the analysis finds.
A widespread flaw can be closed in a day. The doors opened while it was being exploited are found only by looking for them. Strategic’s Cybersecurity division handles incident management and forensic analysis. We work out how long the attacker was inside, which copy to restore from and what to communicate. We do it together with the company’s IT team, its hosting provider and its lawyers.
Sources
Consulted on 16 September 2026.
- Rapid7, CVE-2026-41940: cPanel & WHM Authentication Bypass, 29 April 2026
- Help Net Security, cPanel zero-day exploited for months before patch release (CVE-2026-41940), 30 April 2026, updated 1 May 2026
- CyberScoop, cPanel’s authentication bypass bug is being exploited in the wild, CISA warns, 30 April 2026
- NIST, National Vulnerability Database, CVE-2026-41940
- CISA, Known Exploited Vulnerabilities Catalog
- Mandiant (Google Cloud), M-Trends 2026, March 2026
- NSA and ASD, Detect and Prevent Web Shell Malware, CISA announcement of 22 April 2020
- Regulation (EU) 2016/679 (GDPR), Articles 33 and 34, EUR-Lex
- Italian Data Protection Authority (Garante), Data breach (in Italian)
Find out moreCybersecurityTesting carried out the way an attacker would (penetration tests), incident management, business continuity and support in meeting NIS2 requirements, suppliers included.


