# Four critical cPanel CVEs in 2026. We ran all four against CorePanel > CVE-2026-41940, 29201-29203, 58048 and 65643, explained for sysadmins — what each one really lets an attacker do, and what testing the same four classes found in our own panel. Source: https://www.corepanel.net/blog/cpanel-cves-2026-tested-against-corepanel Author: CorePanel Team Published: 2026-08-30 Tags: security, cpanel, vulnerabilities, migration From the CorePanel blog — https://www.corepanel.net/blog --- > **In short:** cPanel patched four separate critical issues in 2026 — an > unauthenticated bypass now in CISA's KEV catalog that got roughly **44,000 hosts > ransomed**, three more bugs ten days later, a database rename that ran SQL as > root, and on **27 August** a domain-parking flaw that lets an ordinary hosting > customer write files anywhere on the server and execute code as **root**. Three > of the four share one shape: **the attacker is your own customer.** We took all > four classes and ran them against CorePanel's code. Three do not apply, because > the code they need does not exist here. The fourth — unsafe handling of symbolic > links in privileged file operations — did. We found one instance, fixed it, and > the audit it triggered ended up covering five code paths rather than one. In the spring of 2026, someone pointed a scanner at the open internet and found **8,859 web servers cheerfully publishing a directory listing of their own encrypted files**. Every filename ended in `.sorry`. Seven thousand of those boxes were running cPanel. They were not targeted. Nobody picked them. They were simply reachable on a Tuesday. That is where the year went, and it is only the first of four. If you administer servers for a living, 2026 has been a rough one to be responsible for a cPanel box — not because of any single bug, since everyone ships bugs, but because of the **cadence**, and because of who the attacker turned out to be almost every time. Here is the whole year on one line. ## The year in four emergencies | Date | CVE | Who can exploit it | What they get | |---|---|---|---| | **28 Apr** (exploited since **23 Feb**) | CVE-2026-41940 | Anyone on the internet. No account. | Root on the server | | **8 May** | CVE-2026-29201 / 29202 / 29203 | An authenticated account holder | Code as the account's user; arbitrary `chmod` | | **30 Jul** | CVE-2026-58048 | An account holder with a database | SQL as the **database** root | | **27 Aug** | CVE-2026-65643 | An account holder who can add a domain | Root on the server |
Timeline of cPanel and WHM's four critical patches across 2026, on an axis from February to August. Above the axis, a shaded band runs from 23 February to 28 April marked 'exploited in the wild, unpatched — 64 days', and two later events: CVE-2026-29201, 29202 and 29203 on 8 May, and CVE-2026-65643 on 27 August. Below the axis, the patches: CVE-2026-41940's emergency patch on 28 April, and CVE-2026-58048 on 30 July. Underneath, a table of the five CVEs: CVE-2026-41940 needs no account and gives root on the server via CRLF injection into the session; CVE-2026-29202 needs a customer account and turns an API call's plugin parameter into Perl; CVE-2026-29203 needs a customer account and redirects a privileged chmod through a symbolic link; CVE-2026-58048 needs a customer account and turns a database name into SQL during a rename, giving SQL as database root; CVE-2026-65643 needs a customer account and writes a file anywhere by adding a parked or addon domain, giving root on the server. Only the first needs no account at all.
Dates are public disclosure or patch release. The band is the interval between the earliest confirmed exploitation of CVE-2026-41940 and the emergency patch that closed it.
Read the third column again, slowly. **Three of the four need nothing but a customer account** — the thing you sell, for four dollars a month, to anybody with a working card and an email address. Your threat model for 2026 is not a nation-state. It is a signup form. ## February: the one that actually burned servers Check this one first, especially if you have inherited a server that nobody has been watching. The flaw lived in **cpsrvd**, the daemon behind cPanel's and WHM's web interfaces, in how it read the HTTP `Authorization` header. Attackers could smuggle a **CRLF** — a carriage return and a line feed, the two characters that end a line — into a value that was then written into the session. Here is why that is fatal rather than untidy. The session was a **list of facts, one per line**. Write a newline into it and you do not corrupt the list; you *extend* it. The attacker got to append a fact of their own choosing, and the fact they chose was that they were root. No credentials. No account. No exploit chain. One well-shaped HTTP request. **CVSS 9.8.** Exploitation in the wild traces back to **23 February 2026**, roughly two months before cPanel had anything to ship. The emergency fix landed **28 April**, public disclosure **29 April**, and CISA put it in the Known Exploited Vulnerabilities catalog immediately, with a remediation deadline of **3 May** — two days. Agencies do not get two days for problems anyone considers survivable. Then it stopped being a bulletin and became a news story. Proof-of-concept code went public, several unrelated groups grabbed it, and the internet-wide scanning began. The payload was a Go encryptor that renames everything it touches to `.sorry`. Around **44,000 IP addresses** were compromised. Censys counted the **8,859 hosts** from the top of this post — **7,135** of them confirmed cPanel or WHM — which is how we know that a good number of the victims were not merely encrypted, but serving the evidence over HTTP to anyone who asked. **Patched in:** 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20, 11.136.0.5, and WP Squared 136.1.7. And if your box is on an older build in its branch, patching is not the task. **The task is an incident review.** The window ran from February to April, the exploitation was automated, and it did not care who you were. ## May: ten days later, three more Barely a week and a half after the bypass, cPanel shipped a **second emergency TSR** — three more CVEs, two of them CVSS 8.8, patched **8 May**. That is not a coincidence, and it is not a dunk either. It is exactly what a serious engineering organisation does after being mass-exploited: it stops, it goes looking with fresh eyes, and it finds things. Nobody enjoys the week where that happens. The three are worth knowing apart, because they fail in three different ways: - **CVE-2026-29202** — sloppy validation of the `plugin` parameter in the `create_user` API call, ending in **arbitrary Perl execution** as the account's system user. A parameter that was supposed to *name* a thing turned out to *be* the thing. - **CVE-2026-29203** — **unsafe symbolic link handling**: an authenticated user could aim a privileged `chmod` at a file that was none of their business, simply by pointing a symlink at it. Denial of service, or privilege escalation, depending on what you pointed it at. - **CVE-2026-29201** — the third of the set, patched alongside them. Keep hold of **29203**. It is the least glamorous item in this entire post, it made no headlines, and it is the one that comes back in the second half. ## July: the database name that stopped being a name Disclosed **30 July**. **CVSS 9.4**. This one is almost pretty, in the way disasters sometimes are. cPanel's *rename database* feature failed to preserve the connection's **SQL mode** while doing the rename. SQL mode decides, among other things, what a quotation mark *means*. And a database name is an identifier — a piece of text pasted into a statement on a connection that happens to hold MySQL root. So: change the rules about what a quote means, and the name is no longer a name. It is a program. And it runs as root. An account holder with the database feature switched on — which is the default for ordinary customers on essentially every shared and reseller platform in the world — could read, alter or dump **every database on the instance**. Not their own databases. All of them. Public exploit code exists. Nothing here is theoretical. ## August: parking a domain, landing on root Disclosed **27 August 2026**, affecting **all supported versions** of cPanel & WHM. Parking a domain is the single most boring thing a hosting customer can do. You buy a second name, you point it at the site you already have, you go to lunch. Until 27 August, it was also a root shell. Any account holder with permission to add **parked or addon domains** could create arbitrary files anywhere on the server, and go from there to code execution as **root**. No chained bugs. No exploit development. Just an ordinary, legitimate, bottom-tier login — the kind you can buy for pocket change, or harvest from any customer whose WordPress fell over last month. And there is nowhere to hide from it, because **domain parking is not an optional extra**. It is on by default, on effectively every shared and reseller account in existence. Some hosting providers responded by simply switching it off: Reclaim Hosting [disabled creation of new subdomains, addon and parked domains](https://blog.reclaimhosting.com/cpanel-domain-parking-vulnerability-cve-2026-65643/) across affected servers while they patched. Breaking a routine feature for every customer is a drastic thing to do on a Thursday. It was also the right call, which tells you where the flaw left administrators. **Patched in:** 11.110.0.141, 11.134.0.53, 11.136.0.37, 11.138.0.2, and WP Squared 11.138.1.7 or later. ## The same sentence, four times Strip away the specifics and these stop being four separate bugs. They are one sentence, repeated: > **Privileged code did something on behalf of a tenant, using a value the tenant > controlled, without checking that the thing it ended up acting on was the thing it > meant to act on.** A domain name that turns into a file path. A database name that turns into SQL. A parameter that turns into Perl. A path that turns into a symlink pointing somewhere else entirely. In every one of them the panel is doing its job — performing a privileged action a customer asked for — and the whole disaster lives in the gap between **what got checked** and **what got used**. That is a class, not a coincidence. Which means the useful question, for anyone running any control panel at all, is not *"am I patched?"* It is: > **Does my panel have this class — and would anybody here know if it did?** So we went and asked it about ours. ## Three came back clean. One didn't. Not a marketing exercise: an actual audit, one class at a time, against the code, over the last days of August. Here is what came back. **CVE-2026-41940, the CRLF session injection — does not apply.** It needs a line-oriented session store that a request value can be written into. There isn't one. A CorePanel session is a **signed token**, verified in middleware before a request reaches any handler at all; alter its contents and it simply stops verifying. That middleware is **deny-by-default** — every JSON-RPC method demands authentication unless it is on an explicit exclusion list, and the list has exactly **three** entries: log in, log out, and redeem a one-time sign-in link. No header value anywhere on that path ever becomes a fact about who you are. **CVE-2026-58048, SQL smuggled through an identifier — does not apply.** Twice over, as it happens. CorePanel has **no database rename feature**; the operation the CVE describes does not exist in the code. And every identifier heading for MySQL is checked first against a **character allowlist** — letters, digits, underscore — with a length cap and an outright rejection of quoting and comment sequences. A name that could change how a statement parses never reaches the statement. **CVE-2026-29202, code execution through a plugin parameter — does not apply.** CorePanel runs no Perl anywhere, and has no API parameter that names code to run. The class needs an interpreter reachable from a request field. There isn't one to reach. **CVE-2026-29203, and the write primitive underneath 65643 — unsafe symlink handling in privileged file operations — applies.** So we stopped congratulating ourselves and went looking properly. We found one. ## What we found CorePanel's privileged daemon runs as root. Among its duties, it creates a small, fixed set of directories inside a hosting account's home — the document roots, the mail directory, the log directory. Before touching anything, it checked that the target sat inside that account's home. The check compared **strings**. And this is the thing that makes symlink bugs so durable across so many products: **a path is not a place. It is a set of directions**, and the kernel follows them fresh, from the beginning, every single time. Reading the directions and arriving at the destination are two different acts, separated by a gap — and anyone who has ever followed a road sign that somebody quietly turned around knows exactly how large that gap can be. Replace one component of those directions with a symbolic link and the check and the operation are looking at two different places. The check sees a path that is unmistakably inside the home and approves it. The kernel walks the link. Root's work lands somewhere else. That is CVE-2026-29203's defect exactly, and it is the same primitive that makes CVE-2026-65643 catastrophic instead of merely embarrassing. **We proved it end to end on a real server** — a live AlmaLinux box, running the released packages, SELinux enforcing, aimed at a deliberately harmless target directory and never at anything the system depends on. It worked. Then we pointed the same operations at the fixed build, and they refused, while the ordinary, non-malicious versions carried on working exactly as before. **Fixed in CorePanel 1.4.0.** Three things about that fix are the whole reason this section exists. **One: the audit found more than the finding did.** We went in with three suspect code paths. Fixing them shook loose two more of the same shape that nobody had flagged — including one where a privileged ownership change was quietly swallowing its own error, which is its own small horror story. **Five paths, not three.** A patch would have closed the ones we already knew about and left the other two exactly where they were. **Two: the fix is structural.** The privileged paths no longer validate a path string at all. They open the account's home and **walk down one component at a time, refusing to follow a symbolic link at any step**, then act on the resulting file descriptor instead of on a name. We stopped reading the sign and started walking the road — so the thing that was checked and the thing that gets acted on are now the same object, with no gap between them for anything to change. That lives in one place, `safefs`, and every privileged operation touching tenant-owned space goes through it: not just the five we fixed, but every one written from here on. **Three: the class is tested against, not just fixed.** The new tests plant a hostile symlink and then assert on the **filesystem** — what actually exists, and who actually owns it — rather than on whether some function got called. Then we ran them against a deliberately broken build to watch them fail. A regression test that cannot fail is decoration. One behaviour change rides along, and administrators should hear it from us rather than discover it: **an account whose home contains a symbolic link where one of those standard directories belongs will now fail provisioning, instead of silently following the link.** That is the right answer. A tenant does not get to redirect root's work by rearranging their own home directory, and an operation that cannot be done safely should stop instead of proceeding hopefully. ## Why we're telling you at all The obvious move here is to write three thousand words about someone else's CVEs and quietly skip the part where we have our own. We would rather not, for a reason that is more useful to you than it is flattering to us. Every panel that manages a multi-tenant server has this class permanently available to it. Privileged code acting on tenant-controlled input is not a mistake in the design; it *is* the design. A vendor with a spotless public record is telling you about their disclosure policy, not their code. So "who has bugs" is the wrong comparison. The two that matter are **how much a single mistake costs you**, and **whether what gets closed is the instance or the class**. On cost, CorePanel's answer is architectural, and it predates all of this: - **One root component, with a narrow door.** The web-facing service does not run as root and cannot touch the system directly. Privileged work happens in a separate daemon, reachable only over a local socket, through a fixed set of typed operations. There is no generic "run this" anywhere on that interface. - **Accounts are isolated by the operating system, not by good manners.** Every account gets its own PHP process pool running as its own user, its own `open_basedir`, and file modes a neighbour cannot read through. There is **no shared web server user** to pivot through — which is the single mechanism that turns one hacked account into everybody's data on a conventional stack. - **SELinux stays enforcing.** CorePanel ships its own policy and installs onto a server with SELinux switched on — a pointed contrast with a stack whose standard advice for two decades has been to turn it off. Note that the finding above was reproduced *with SELinux enforcing*. That is precisely why we fixed it properly instead of quietly deciding the mandatory access controls probably had it covered. - **Deny-by-default authorisation.** A method is unreachable by customers until somebody explicitly registers it as customer-reachable. Adding an API method does not silently widen the attack surface; forgetting to register one produces a visible "not available", not an invisible hole. None of that would have prevented the finding. All of it is why the finding was a directory-creation bug and not an incident. ## If you run cPanel today, do these four things Today, not at the weekend: 1. **Check your build against the 65643 fix list** — 11.110.0.141, 11.134.0.53, 11.136.0.37, 11.138.0.2, WP Squared 11.138.1.7. Every supported version was affected. `/usr/local/cpanel/cpanel -V` will tell you where you stand. 2. **Confirm 41940 was patched — then confirm you weren't already hit.** Patching in May does precisely nothing about February. Go looking for files ending in `.sorry`, for web-accessible directories you did not create, and for root-owned files and cron entries carrying timestamps from that window. 3. **Assume your customers are hostile**, because 58048 and 65643 both start there. Any account compromised through a tired WordPress install in the last six months was also, on an unpatched box, a root shell that happened to be pointed somewhere else. 4. **Consider turning domain creation off** until you have finished patching. It is disruptive, your customers will notice, and it is completely reversible. Root is none of those things. ## And once the patching is done There is a version of this post that ends here, having explained four CVEs and left the obvious conclusion politely implied. We would rather say it out loud, because the arithmetic has changed since most administrators last checked. **A cPanel server becomes a CorePanel server in place, on the same machine, in about ten minutes.** That is measured, not aspirational. On **29 August** we transformed a real cPanel box — **45 accounts, 51 domains, 84 mailboxes, 43 databases, 48 DNS zones**, WordPress homes running from 4,400 to 64,400 files — on a thoroughly unremarkable 2 vCPU, 3.5 GB server. The whole run took **616 seconds**. The window in which websites were actually down was **28 seconds**. All **51 of 51 sites** came back. It is that fast for exactly one reason: **the data never moves.** Home directories, maildirs and the MySQL data directory are **adopted where they already sit** — not copied, not exported, not re-imported. The mail layout is already byte-for-byte the one CorePanel uses. The IP address does not change, so there is no DNS ceremony and nothing to wait out. What you are paying for in downtime is a service cutover, not a data transfer. That is the difference between 28 seconds and an evening. There is also a read-only analysis mode that inspects a live cPanel server, tells you exactly what it found and exactly what it would do, and changes nothing at all. The analysis and the transformation are both **free**, and so is CorePanel Personal, forever. Run the analysis on the box you were about to spend the weekend patching. It takes minutes, it touches nothing, and it will tell you what the other option looks like on *your* server rather than on ours. --- *Sources: [The Hacker News on CVE-2026-65643](https://thehackernews.com/2026/08/critical-cpanel-flaw-could-let-one.html) · [Reclaim Hosting's advisory](https://blog.reclaimhosting.com/cpanel-domain-parking-vulnerability-cve-2026-65643/) · [Rapid7 on CVE-2026-41940](https://www.rapid7.com/blog/post/etr-cve-2026-41940-cpanel-whm-authentication-bypass/) · [BleepingComputer on the "Sorry" ransomware campaign](https://www.bleepingcomputer.com/news/security/critrical-cpanel-flaw-mass-exploited-in-sorry-ransomware-attacks/) · [CyberScoop on the CISA KEV listing](https://cyberscoop.com/cpanel-authentication-bypass-vulnerability-cve-2026-41940-exploited/) · [The Hacker News on CVE-2026-58048](https://thehackernews.com/2026/08/new-cpanel-critical-flaw-could-let.html) · [InMotion Hosting on the May TSR](https://www.inmotionhosting.com/support/news/cpanel-cve-2026-29201-29202-29203-patch-advisory/)*