Security researchers have found a Linux backdoor named CWPdoor that sits inside the web server of Control Web Panel, a dashboard many small hosting providers and website owners use to run their servers.[1][2] Anyone who controls a server this way can read the data on it, so if your site, shop or email runs on a machine managed with this panel, it is worth checking now.
What happened with Control Web Panel?
On November 5, 2026, XLab, the research arm of the Chinese company QiAnXin, published its analysis of CWPdoor.[1] Control Web Panel, once called CentOS Web Panel, is a free tool for managing websites, mail and databases, comparable to cPanel and Plesk.[2] Its built in web server is a program named cwpsrv. CWPdoor is a doctored copy of that program, rebuilt with a hidden entrance.[1]
BleepingComputer reported the research the same day.[2] XLab described the malware as “exceptionally stealthy” and, according to BleepingComputer, said the evidence points to “real victims already exist in the wild.”[2]
How does CWPdoor work?
The backdoor does nothing until the attacker sends a web request carrying three special headers: an encrypted command, a timestamp and a digital signature.[1][2] The server accepts the request only if the timestamp is within five minutes of the server clock and the signature is valid. It then hands the command to a helper process, runs it and sends back the answer in encrypted form.[1][3]
It also removes that request from the access logs, so an administrator reading the logs sees nothing odd.[1][2] The installer, a script called cwpsrv_update.sh that poses as an update, resets file dates and tries to wipe the command history to cover its tracks. XLab says it rolls the change back if a health check fails.[1]
Who is affected, and how many servers?
Nobody knows how many servers carry the backdoor. XLab counted more than 340,000 Control Web Panel installations reachable from the internet over the past month, but that is the pool of possible targets, not a tally of infections.[1][3] Only two samples have been captured, built for cwpsrv versions 1.15.10 and 1.24.0.[1]
The evidence of real infections is circumstantial. XLab caught the installer script on June 29. On September 30 someone in Brazil uploaded an archive to VirusTotal containing a CWPdoor file that no antivirus engine flagged at the time, along with a sample of Ebury, a long running Linux backdoor and password stealer.[1][2] The researchers say it is unclear whether the two are related and suggest different attackers may have put them on the same machine.[1]
How did the attackers get in?
That is the biggest open question. XLab has not found a flaw in Control Web Panel that explains the infections, and it has not named the attackers or the way they spread the installer.[1][3] The installer needs root access, which means the attacker already controlled the server before CWPdoor arrived. Think of it as a master key that stays in the lock after a burglary, not as the break in itself.[3]
BleepingComputer did not find any statement from the Control Web Panel developers.[2] We found none either, so there is no vendor patch to point to.
How can you check your own server?
If you run your own server or a virtual server with Control Web Panel, ask your administrator or hosting provider to look for these signs.[1][3] Each one is a clue, and none alone settles the question.
- A Unix socket named ngx_http_integrity_helper on the machine.
- Unexpected helper processes belonging to cwpsrv.
- The text X-Ngx-Integrity inside the cwpsrv program file.
- A leftover backup file next to the cwpsrv binary, which should be treated with suspicion.
A clean result is not proof of safety, because the attacker may have removed traces.[3] If your hosting is managed by a company, contact them and ask in plain words whether they run Control Web Panel and whether they checked for CWPdoor.
What should you do if you find it?
XLab advises restoring a clean cwpsrv file, upgrading the panel, confirming the suspicious socket is gone and changing every control panel credential.[1][2] eSecurityPlanet adds a warning: upgrading alone does not prove the intruder has lost access, so the safest course is to rebuild the server from a trusted installation and change SSH, database, hosting and application passwords as well.[3]
Website owners without a server of their own can still act. Change the passwords for your hosting account, email and admin pages, turn on two step login where it is offered, and keep a recent backup off the server. Our pages on the AsyncRAT backdoor, the Quasar remote access trojan and the Gh0st RAT explain what attackers do with this kind of hidden access.
What comes next?
Expect more detail once XLab or other researchers learn how the installer reached servers and who is behind it. Antivirus tools had no detection when the sample first surfaced, so the file names and socket above matter more than a scan result for now.[1][3] Until a cause is named, treat any exposed Control Web Panel server that you cannot vouch for as a candidate for a careful check.
