Two Bad Weeks for the Stack Underneath Your Website: Copy Fail and the cPanel/WHM Auth Bypass

By Salvador Aguilar, Threat Research Manager — Monarx

If you run a website, you almost certainly don't run it alone. There's a Linux kernel underneath you, a control panel managing the server above that kernel, and a web application sitting on top of both. Last week, two of those three layers took serious hits — within roughly twenty-four hours of each other.

This post walks through what happened, what we're seeing in the wild, and what our team has done to keep Monarx customers protected. If you're a Monarx customer, you already received our notification on Copy Fail with the technical details and mitigation guidance — the cPanel issue isn't one we notified on directly, but we're covering it here because the two arrived together and the combination matters. Everything below is the broader picture for anyone tracking the threat landscape, plus a look at the exploit variants we've started to see hit our sensors.

Copy Fail — CVE-2026-31431
‍

‍

Disclosed April 29 by the team at Theori (with the bug surfaced by their Xint Code AI auditing tool), Copy Fail is a local privilege escalation in the Linux kernel that affects essentially every mainstream distribution shipped since 2017. The proof of concept is 732 bytes of Python. It uses no race condition, no kernel-specific offsets, and no exotic primitives — just a straight-line logic flaw in the kernel's algif_aead crypto interface, chained through AF_ALG and splice() into a 4-byte page-cache write that flips a setuid binary into giving you a root shell.

The blast radius matters. An unprivileged local user becomes root on:

• Multi-tenant Linux hosts — shared dev boxes, jump hosts, build servers
• Kubernetes and container clusters — a pod with the right primitives compromises the host node and crosses tenant boundaries
• CI runners — any system that executes untrusted PR code as a regular user
• Cloud SaaS running user-supplied code — notebook hosts, agent sandboxes, serverless functions

For the website hosting world, the second and fourth bullets are the ones that should make you sit up. Shared hosting environments, managed WordPress platforms, and any place where one customer's container shares a kernel with another customer's container — that's where Copy Fail goes from "interesting LPE" to "tenant isolation broken."

The fix is mainline kernel commit a664bf3d603d, which reverts the 2017 in-place optimization that introduced the bug. If you can't patch immediately, disabling the algif_aead module is a clean mitigation — almost nothing in a normal stack actually uses AF_ALG (dm-crypt, kTLS, OpenSSL, SSH, the kernel keyring all go through the in-kernel crypto API directly, not through this socket interface). For untrusted workloads, blocking AF_ALG socket creation via seccomp is worth doing regardless of patch state.

What we're seeing on the exploit side

The published PoC is a Python script. That isn't what's actually showing up in the wild. Once a public PoC drops, the first thing operators do is repackage it for whatever runtime their initial-access vector gives them — and that's exactly the pattern our threat research team has been tracking since they came out.

We've observed four flavors of Copy Fail exploitation attempts on customer infrastructure:

ELF binaries. ELF (Executable and Linkable Format) is the standard executable format on Linux — the same format /bin/ls and /usr/bin/su use. Compiled-from-C variants of the exploit drop a single static ELF on disk. These are the version operators reach for when the host has no Python interpreter, when they want to evade signature-based detection on the well-known PoC, or when they're chaining Copy Fail behind an initial RCE that already gives them a way to land a binary.

Shell scripts. Wrapper scripts that detect the running distribution, fetch the right exploit payload (Python or ELF), execute it, and then clean up the staging files. We've seen these chained behind webshell uploads on compromised WordPress sites — the webshell drops the wrapper, the wrapper grabs the kernel exploit, and what was a low-privileged www-data foothold turns into root on the host. This is the path that crosses the tenant boundary in shared hosting.

Python variants. Modified versions of the original PoC — same primitive, different targets. Some swap the default /usr/bin/su target for sudo, mount, or pkexec. Others remove the print statements and obvious strings to slip past naive YARA rules. A few have been merged into broader post-exploitation toolkits where Copy Fail is one of several LPEs the operator tries in sequence.

PHP variants leveraging shell_exec. This is the one most directly relevant to our customer base, and the one our team flagged on April 29 on a customer's server. Rather than landing a separate file, the attacker embeds the Python exploit body as a string inside a PHP file, then uses shell_exec (or its cousins exec, system, passthru, popen) to pipe the inlined Python directly into a python3 -c invocation — or write it to /tmp and execute it from there. This is a clever fit for the WordPress threat model: the attacker already has PHP code execution via a malicious plugin, theme file, or webshell, so the path of least resistance is to keep the privilege escalation in the same language the foothold is already running. No second-stage download, no extra network artifact, the entire kernel exploit lives inside one PHP file. We're seeing it pop up in compromised WordPress installs, which means the chain is: malicious upload → PHP execution → shell_exec → Python LPE → root.

We're continuing to track these and will share IOCs and detection logic with our customers as the picture firms up.

CVE-2026-41940 - cPanel & WHM authentication bypass

If Copy Fail wasn't enough to keep us busy, April 28 also brought CVE-2026-41940 — a critical authentication bypass in cPanel & WHM with a CVSS score of 9.8.

For anyone outside the hosting world: cPanel is the user-facing control panel that website owners use to manage individual hosting accounts — files, databases, email, DNS, the works. WHM (Web Host Manager) is the server-level administrative interface above it, with root-equivalent control over the box and every cPanel account on it. The footprint is enormous. Public estimates put the number of internet-exposed cPanel instances somewhere between 1.5 and 2 million, and the platform manages a substantial portion of all shared hosting on the public web.

The bug itself is a CRLF (Carriage Return Line Feed) injection in the login and session-loading flow. Before authentication actually happens, the cPanel service daemon cpsrvd writes a pre-auth session file to disk. By injecting raw \r\n characters via a malicious basic authorization header and manipulating the whostmgrsession cookie to skip the segment that would normally be encrypted, an attacker can write attacker-controlled properties — like user=root — directly into their own session file in plaintext. Reload the session, and you're authenticated as whoever you wrote yourself in as. No credentials needed.

It affects every supported version of cPanel & WHM (anything after v11.40), plus previous versions of WP Squared 136.1.7. And it appears it was being exploited as a zero-day for at least two months before disclosure — KnownHost reports seeing exploitation attempts as far back as February 23, 2026.

The fix shipped April 28. If you run cPanel & WHM, patch immediately and restart cpsrvd. If patching has to wait, block external access to ports 2083, 2087, 2095, and 2096 — several major hosting providers (Namecheap among them) used this tactic as a stopgap before the patches landed.

What Monarx did

Our team alerted all Monarx customers promptly with the technical details about Copy Fail, our assessment of their exposure, and clear mitigation guidance. While we couldn't remediate the CVEs themselves, we focused our efforts on helping customers detect and respond to post-exploitation activity. We did this for two reasons. The first is obvious: customers need to be able to act before attackers do. The second is that with a kernel LPE this clean and a control-panel auth bypass this severe landing in the same week, the temptation for operators to chain them is real — get into a website via a webshell, then pivot to root via Copy Fail, then move laterally across the host.

We're continuing to track exploit variants in the wild and feeding what we find into our detection logic.

Why a layered approach matters

Neither of these bugs lives at the layer Monarx primarily defends. Copy Fail is a kernel issue. The cPanel bug is a control-panel issue. Monarx focuses on the application layer — specifically, the malware and behavioral threats that live inside WordPress and PHP applications.

That's exactly the point. No single layer of security is sufficient. A defender who only patches the kernel still gets owned through cPanel. A defender who only locks down cPanel still gets owned through a vulnerable WordPress plugin. A defender who only protects the application layer still gets owned by an LPE that turns a constrained webshell into a root shell.

‍

The defenses have to overlap:

• Network layer — firewalls, port restrictions, WAFs, rate limiting, geo-blocking on admin interfaces. This is where blocking ports 2083/2087 buys you time to patch a cPanel zero-day. It's also why we built SmartWAF: a firewall tuned for the specific traffic patterns of Web Hosting environments, with rule sets that get updated continuously based on what our threat research team is seeing across the customer base. Using intelligence from Monax's global network, SmartWAF can help identify and block the bad actors trying to exploit things like CVE-2026-41940, and stop them before they can — often before the upstream patch is even available.
• Server layer — kernel patching, OS hardening, control-panel updates, seccomp profiles, container isolation, integrity monitoring on system binaries. This is where Copy Fail gets shut down. It's also where the Monarx Agent does its work: continuous scanning of on-disk files for known and behavioral malware indicators, and inspection of running processes for the patterns that signal post-exploitation activity — backdoors, droppers, cryptominers, web shells that have already landed, and the staging artifacts of exploit chains like the PHP-shell_exec Copy Fail variant. When a malicious process is identified, the agent doesn't just alert — it terminates. That's the difference between "we noticed something happened" and "we stopped it from continuing."
• Application layer — behavioral malware detection, file integrity monitoring on web roots, runtime protection against PHP backdoors and webshells, blocking the kinds of malicious uploads that give attackers their initial foothold in the first place. This is where Monarx lives, and it's where ThreatShield does its work. ThreatShield is a RASP — Runtime Application Self-Protection — that hooks directly into the PHP runtime and watches what the application actually does as it executes, rather than trying to pattern-match files at rest. That distinction matters for threats like the PHP-shell_exec-Python variant of Copy Fail we discussed above: a file-scanner might miss the obfuscated PHP wrapper, but ThreatShield sees the dangerous function call (shell_exec invoking python3 -c with an inlined exploit body) at the moment it happens and blocks it before the kernel exploit ever runs. Same story for webshells, malicious uploads, unauthorized file writes to wp-content, and the broad family of post-exploitation behaviors that sit between "attacker has a foothold" and "attacker owns the box."

Each layer catches what the others miss. Copy Fail needs an unprivileged local foothold to start with — the application layer is where most of those footholds get established, and it's where ThreatShield catches them before the attacker ever has the chance to reach for an LPE. The cPanel bug, conversely, is a reminder that when a foundational layer fails, the layers above it need to be hardened enough to limit the damage — and a tuned WAF like SmartWAF is often the difference between "exposed for two months" and "blocked at the edge on day one."

We're here to help

If you're a Monarx customer and you have questions about your exposure to either CVE, reach out — we'll walk through it with you. If you're not a customer and you're running shared hosting, managed WordPress, or any environment where multiple tenants share infrastructure, both of these vulnerabilities deserve immediate attention. Patch the kernel. Patch cPanel. Restart cpsrvd. Audit your logs for suspicious authentication activity going back to late February.

It's been a rough week for the stack underneath your website. We're doing our part to make sure the application layer above it stays defended.

‍