When critical vulnerabilities collide: How recent cPanel & Linux CVEs are reshaping securing systems

29 May 2026, by Micron21

It's always been true that keeping your systems up-to-date is one of the most important things you can do to remain secure.  And as our long-time readers will know, it's a topic we cover often – not because we want to sound like a broken record, but because year after year the threat landscape continues to evolve in ways that make this advice more critical, not less.

Zero-day vulnerabilities, by their very definition, are security flaws that are potentially being actively exploited before patches have been developed and released.  Without applying security updates quickly when they do become available, you leave yourself wide open in those windows when these types of issues come to light.  And that's even more true now, as the increasing use of AI in security research is leading to more and more of these previously hidden vulnerabilities being discovered – many of which have quietly existed in widely used software for years, sometimes even decades!

Recently, several severe CVEs were disclosed for cPanel, that if exploited, could allow a server to be root-compromised without any prior foothold whatsoever.  In addition, the Linux kernel had its own critical disclosures with CopyFail and DirtyFrag – privilege escalation vulnerabilities that, while requiring some form of access first, could similarly be used to escalate to full root compromise of a server.  All of these vulnerabilities landed around the same time, and all of them were critical to our customers, so we took decisive action to help secure their systems.

That's why in this month's blog we'll be talking about these CVEs, what we did in response, as well as our suggestions about how to handle similar threats moving forward.

The cPanel CVE - CVE-2026-41940

Let's start with the cPanel issue, as it's arguably the most concerning of the three.  The vulnerability disclosed in CVE-2026-41940 was an authentication bypass in cPanel/WHM/Webmail – which in plain English means that malicious actors could gain direct access into servers running cPanel without needing valid credentials or any prior foothold on the system at all.

To put that in perspective, this is one of the rarest and most severe types of compromise possible.  There hasn't been a vulnerability like this in cPanel's history – and considering cPanel has been around since 1996 -  that's saying something!  Most security issues in mature software like this require some form of pre-existing access, valid credentials, or a chained exploit to be useful to an attacker. This one didn't.

What made the situation worse was that there was strong evidence that this vulnerability was being exploited "out in the wild" before it became known to cPanel and the wider security community.  This meant that when the disclosure was made and patches were released, many providers and their customers found themselves having to investigate whether they had already been compromised, rather than simply applying a patch to prevent a future attack.

Because cPanel is one of the most widely deployed web hosting control panels in the world, this was very much a global issue.  It affected all providers that use cPanel themselves or that host it for their clients – from large multi-national hosting companies all the way down to small, single-server operations.  Every single cPanel/WHM/Webmail endpoint on the internet was potentially vulnerable, and providers around the world had to take quick action to secure these immediately.

What we did in response

When the disclosure landed, we moved quickly.  We undertook the necessary patches as advised by cPanel at the time, took the necessary steps to block all traffic to and from affected servers, locked them down, rolled passwords, and then evaluated each of these servers for potential compromises – performing rectification work where required.

Importantly, we performed this work on affected customer servers regardless of which support plan they were on.  While our Total Care and Comprehensive Care plans are the only ones that include this kind of proactive security work as standard, we made the call that the risk to our customers was simply too high to leave anyone exposed.  The work was prioritised based on customer support tier, but no one was left waiting for an upgrade before being protected.

For customers using our Shared Web Hosting (SWH) or Mail Hosting services, this work was undertaken entirely behind the scenes by our team.  Those customers didn't need to do anything at all – Micron21 has, and continues to, work on protecting these platforms.

In addition to the immediate response work, we also made a more significant change going forward.  From the weekend following the disclosure, we introduced new authentication requirements for customers looking to access their cPanel, WHM, and Webmail portals, or accessing their server via FTP, SFTP, or MySQL. Customers now need to authenticate through our WebAuth portal, which grants access to the server for a period of 24 hours.  We'll talk more about why this matters further down in this article.

Not all providers responded the same way

It's worth noting that not all providers took such serious precautions.  We've heard from a number of customers who have moved to us in the months since after watching their previous providers respond either too slowly or too narrowly – with some only patching what was strictly required of them and leaving any compromise investigation up to the customer to discover for themselves.  The result for some of those providers was a large number of compromised customers, which understandably shook the foundations of their business.

We took this threat very seriously because we had to protect!  We saw active, ongoing attack attempts against our clients and decided to take action to prevent and remediate them, regardless of what support plan customers had with us.  It stretched our resources, we worked overtime, but this is the kind of response we believe our customers deserve when something this critical happens. 

That said, even though we performed this work without it, we'd still strongly recommend that clients who want fully proactively maintained and monitored systems take out an appropriate Customer Care plan.  With these kinds of attacks becoming increasingly likely, having a plan in place that includes this work as standard – rather than relying on us absorbing that risk on your behalf – is the right move for any business that depends on its hosted infrastructure.

CopyFail - CVE-2026-31431

Where the cPanel vulnerability allowed attackers to compromise systems from the outside, CopyFail is a different beast entirely.  CVE-2026-31431 (CopyFail) is a critical vulnerability in the Linux kernel itself, which means it affects every single Linux distribution and almost every Linux server running today.

Unlike the cPanel vulnerability, CopyFail is a privilege escalation vulnerability.  This means that a malicious actor first needs some form of access to the system before they can exploit it – typically as an unprivileged local user.  So at first glance, it might sound less serious. The reality, however, is that privilege escalation vulnerabilities are almost always paired with another initial access vulnerability to chain attacks together, and once exploited, they allow the attacker to escalate from a low-privilege account all the way up to full root access.

By exploiting this flaw, an attacker can tamper with the cached memory contents of essential system binaries (such as /usr/bin/su) or sensitive configuration files (such as /etc/passwd) directly in memory.  This effectively allows malicious code to be "injected" and executed with the highest level of privileges on the system.

What makes this vulnerability particularly dangerous is its stealth.  Because the modifications occur exclusively in RAM (within the page cache), the underlying files on disk remain completely untouched.  As a result, integrity verification tools – such as checksum comparisons – will fail to detect any tampering, and once the system is rebooted, all evidence of the exploit is wiped from memory, leaving no forensic trace behind.  For incident responders, that's about as bad as it gets.

A vulnerability hiding in plain sight – found by AI

Perhaps the most striking aspect of CopyFail is how long it had been there.  The bug was present in code that has been part of the Linux kernel for many years, used by virtually every server, desktop, embedded device, and smartphone on the planet that runs Linux.  It had been reviewed and re-reviewed by countless developers and security researchers, and it had still gone undiscovered.

What changed is that this particular vulnerability was discovered using AI assisted tooling.  This is a significant moment, because it's a strong signal of a much wider trend that we anticipate will only accelerate.  There is almost certainly a long backlog of these kinds of latent vulnerabilities sitting in widely deployed software – ones that have been there for years but simply haven't been found yet.  As AI tooling becomes more sophisticated and is increasingly applied to security research, we expect more of them to come to light.

That's a double-edged sword.  It's good news that these vulnerabilities are being found and fixed, but it's also true that the period between disclosure and exploitation is shrinking, and there's no guarantee that the good researchers will always find them first.

What we did in response

For our customers with Total Care and Comprehensive Customer Care plans, we began applying the necessary updates immediately and contacted those customers directly about the work.

For customers on Enhanced or Essentials Customer Care plans, we asked them to reach out to support@micron21.com to have the update scheduled in their nearest available maintenance window – as these plans don't include emergency patching out of cycle.
For customers using KernelCare – the live kernel patching service – this vulnerability could be remediated without a reboot at all, which is one of the reasons we recommend it for customers running production workloads where downtime is a problem.  Customers using Imunify360 are also provided protection from this exploit at the application layer.

For customers without a Customer Care plan, we strongly recommended updating their systems as soon as possible.  Alternatively, Micron21 was able to perform this work on a fee-for-service basis under our Adhoc Support plans for those who wanted us to handle it.

And once again, for customers on our Shared Web Hosting (SWH) or Mail Hosting services, this work was undertaken by Micron21 with no action required on their part.

DirtyFrag and the broader pattern

Around the same time as CopyFail, the Linux community also had to deal with DirtyFrag (CVE-2026-43284), another privilege escalation vulnerability in the kernel.  DirtyFrag exploits a race condition in how the kernel handles fragmented memory operations, and while the technical details differ, the practical impact is similar – a local unprivileged user being able to escalate to root.

What's notable about DirtyFrag, CopyFail, and the cPanel CVE all landing within such a short window is the pattern it represents.  We're not talking about a single bad month for security – we're seeing a sustained increase in the number of critical CVEs being disclosed compared to previous years.  This isn't just our perception either - the published CVE counts continue to trend upwards year-on-year, and the proportion of those that are rated critical has been climbing too.

The combination of more code being written more quickly (often with AI assistance), more researchers using AI assisted tooling to scan for vulnerabilities, and more attackers also using AI to look for and exploit them, means we're entering a period where vigilance and rapid patching matter more than they ever have.

The future and the move towards locking down sensitive services

Looking ahead, we anticipate that the increase in CVEs and zero-day disclosures will continue, driven primarily by the increasing sophistication and use of AI in security research.  Tools like Mythos – a recently announced AI-driven vulnerability discovery platform – have made bold claims about their ability to find vulnerabilities at scale.  Mythos hasn't yet been made widely available, so it's not clear how much of that is marketing and how much will translate into a genuine step-change in capability.

However, even if the more ambitious claims don't fully pan out, the more mundane reality that automated AI scanning of codebases for vulnerabilities is going to become routine, is itself enough to expect more critical CVEs in the years ahead.

In response to this, we've taken, and will continue to take, proactive steps to improve the security of our platforms.  We'd also recommend that all of our clients look to do the same – and one of the most impactful things any organisation can do today is to take a hard look at which services they have exposed directly to the internet, and start putting protective layers in front of them.

Sensitive admin services don't belong on the public internet

Previously it’s been common and standard to have administrative services – cPanel, WHM, Webmail, SSH, SFTP, FTP, MySQL, RDP, and similar – sitting wide open to the entire internet, protected by nothing more than a username and password (and sometimes, if you're lucky, MFA at the application layer).

The problem with this approach is that it leaves the service itself exposed to whatever vulnerabilities exist in that software at any given moment.  When something like the cPanel authentication bypass lands, every server with that endpoint exposed to the internet becomes a target the moment the exploit becomes known – and as we saw with CVE-2026-41940, sometimes well before that.  If an attacker can't reach the service in the first place, none of those vulnerabilities matter to them.

The solution, in most cases, is to put these services behind layers of network-level access control.  In a typical setup, it looks something like this:

•  The administrative service is bound to an internal interface only, or restricted via firewall rules so that the wider internet can't reach it directly.
• Access is allowed only from trusted IP addresses – such as your office's static IP, or the IPs of specific staff – via firewall allowlisting.
• Where staff need to reach these services from anywhere (working from home, travelling, or otherwise), access is granted by first connecting to a VPN that places you on a trusted internal network, after which the administrative service becomes reachable.
• The VPN itself is then protected with multi-factor authentication, so that even if a user's VPN credentials are stolen, the attacker still can't get in.

This is a layered model, and each layer is doing real work.  The firewall removes you from the pool of opportunistic targets entirely.  The VPN ensures only authenticated, authorised people can attempt to reach the admin service.  The MFA on the VPN ensures that stolen credentials alone aren't enough to break that chain.  And the application-layer authentication on the service itself becomes the last line of defence rather than the only one.

This isn't new – it's how we've protected RDP for years

If this approach sounds new and untested, it isn't.  The Windows world has been treating Remote Desktop Protocol (RDP) this way for a long time now, and for very good reason.  RDP – when exposed directly to the internet – has historically been one of the single most exploited initial access vectors in ransomware attacks.  Industry reports over recent years have consistently placed exposed RDP as one of the top initial access vectors in successful ransomware compromises, accounting for a significant share of all incidents.

The standard, well-understood approach to protecting RDP has been:

• Restrict access to the local network only.
• Place the service behind a firewall, with VPN access required before you can even attempt to reach RDP.
• Require MFA on the VPN connection itself.

That layered model has worked well, and it's exactly the kind of protection that all sensitive services – cPanel, WHM, Webmail, SSH, SFTP, FTP, MySQL, and other administrative interfaces – need to move toward as the threat environment continues to escalate.  There's nothing about RDP that makes it uniquely deserving of this treatment - it's simply that the industry learned that lesson with RDP first.  The same protections apply just as well to every other admin service you have, and the lessons are transferable.

What about services that the public actually needs to reach?

Of course, not every service can sit behind a VPN.  Public-facing services such as your customer-facing website, your customer login portal, public APIs, your mail servers receiving mail from the rest of the internet – these all genuinely need to be reachable by the wider public.  And for these, requiring a pre-authenticated VPN connection is going to be too hard to implement realistically.

However, similar approaches should be considered to limit access to these services to only those who should have access.  Things like application-aware authentication portals, geographic IP restrictions, MFA-protected gateways, and time-limited access tokens are all good tools in the toolbox.

This is essentially what we did with our Shared Web Hosting (SWH) platform via WebAuth – a middle ground between a fully public service and a VPN-locked private one.  Customers authenticate once through the WebAuth portal, are granted temporary access to the underlying services, and after 24 hours need to re-authenticate.  It substantially reduces the attack surface available to opportunistic attackers without making the service inaccessible to the legitimate users who need to reach it.

The cost of inaction

It's worth taking a moment to talk about what's at stake if you don't keep up with this work.  The potential consequences for failing to address critical CVEs in a timely fashion – or for leaving sensitive admin services exposed to the internet – range from the inconvenient to the existential.

At the lower end, you might be looking at unauthorised access to a single service – something that's recoverable but disruptive.  At the more serious end, you're looking at full server compromise, data theft, ransomware deployment, lateral movement into other parts of your infrastructure, regulatory and notification obligations under the Privacy Act, reputational damage, and in the worst cases, business closure!  We've seen organisations of all sizes fail to recover from significant breaches – not because the technical recovery wasn't possible, but because the loss of customer trust and the cost of dealing with the aftermath simply wasn't survivable.

Patching, layered defences, and getting your sensitive services off the public internet aren't just nice-to-haves anymore.  With the volume and severity of vulnerabilities we're seeing in 2026, they're necessary for every business.

Have any questions about how to secure your systems?

If you have any questions about the cPanel or Linux CVEs covered in this article, or you're looking to talk to someone about how to better secure your own systems, let us know!  We're happy to have a conversation about your environment and offer tailored guidance.

We can help with things like setting up WebAuth-style portals for sensitive services, designing firewall rules and IP allowlisting for admin endpoints, deploying VPN connections in front of services like cPanel/WHM/SSH/SFTP, configuring MFA on those VPN gateways, scoping a Customer Care plan that includes proactive patching for your servers, deploying KernelCare for live kernel patching, and more generally helping reduce the attack surface across your environment.

You can call us on 1300 769 972 (Option #1) or reach us via email at sales@micron21.com.