This Week in Cybersecurity: cPanel Mass Exploitation, a 9-Year-Old Linux Root Bug, and APT28 Slips Through an Incomplete Patch

Share
This Week in Cybersecurity: cPanel Mass Exploitation, a 9-Year-Old Linux Root Bug, and APT28 Slips Through an Incomplete Patch
16:10

From mass cPanel exploitation to a Linux flaw that's been waiting since 2017, this week proved how long the window between exposure and remediation can stay open.

A months-old hosting vulnerability that's now being weaponized for ransomware, defacement, botnets, and nation-state espionage. A nine-year-old Linux kernel bug that gives any local user root in 732 bytes. An incomplete February patch that left APT28 a working path back into Windows for ten more weeks. One of the largest endpoint security vendors in the world disclosing that attackers got into its source code repository. And a ransomware-as-a-service operation that turned out to be functionally a wiper because of a bug in its own encryption code.

If there's a throughline this week, it's the gap between when a problem first existed, when it was disclosed, and when it was actually fixed. In every story below, attackers had time on their side. Here's what you need to know.


Explore this content with AI:

ChatGPT | Perplexity | Claude | Google AI Mode


cPanel auth bypass spirals from zero-day to mass ransomware, botnets, and SE Asia espionage

On April 28, cPanel released a patch for CVE-2026-41940, a critical authentication bypass in cPanel & WHM and WP Squared with a CVSS score of 9.8. The flaw — missing authentication on a privileged function — allows unauthenticated remote attackers to gain administrative access to the control panel and, from there, the underlying host. WatchTowr researchers, who published the technical write-up the same day, found evidence that attackers had been exploiting it as a zero-day since at least February 23 — more than two months before the patch landed.

Within 48 hours, exploratory probing turned into multi-actor mass exploitation. Shadowserver Foundation's honeypots logged more than 44,000 unique IPs scanning, exploiting, or brute-forcing cPanel installations on April 30. Censys identified 8,859 hosts exposing open directories of files renamed with a .sorry extension — the calling card of a Go-based Linux ransomware that demands payment via Tox and, in some cases, wipes backups before encrypting. A separate, parallel campaign documented by HostMyCode is dropping a Mirai variant called nuclear.x86, using compromised servers to mine cryptocurrency, run DDoS clients, and harvest credentials from the other websites hosted on the same box.

By May 2, threat researchers at Ctrl-Alt-Intel had also documented a distinct espionage campaign leveraging the same CVE—an unattributed actor using publicly available proof-of-concept code to target government and military entities across Southeast Asia, as well as MSPs and hosting providers in the Philippines, Laos, Canada, South Africa, and the United States. Exposed staging infrastructure also pointed to a separate custom exploit chain against an Indonesian defense-sector training portal and earlier exfiltration of Chinese railway-sector data.

Why it matters: cPanel runs on a substantial percentage of the world's shared web hosting infrastructure, making any single auth bypass a one-vulnerability-fits-millions event. The exposure is compounded for hosting providers and MSPs, where a single compromise can cascade to hundreds or thousands of downstream customer sites. If you operate cPanel directly, run cPanel's updated detection script, audit /var/cpanel/sessions/raw/ for pre-auth session files containing user=root, hasroot=1, tfa_verified=1, or repeated pass= entries, and verify your patched build with /usr/local/cpanel/cpanel -V. If your sites are hosted on someone else's cPanel, ask your provider for written confirmation of patch status and any IOC findings — and assume that anything that ran on a vulnerable server between February 23 and April 28 should be treated as potentially exposed.

Read more at Help Net Security

"Copy Fail": a nine-year-old Linux kernel bug puts almost every distro one syscall from root

On April 30, security researchers at Theori disclosed CVE-2026-31431, a high-severity local privilege escalation flaw in the Linux kernel that they've nicknamed "Copy Fail." The flaw stems from an in-place memory optimization introduced in 2017, in which the kernel reuses source memory as the destination during certain cryptographic operations. By chaining the AF_ALG socket interface with the splice() system call, an attacker can perform a controlled four-byte write into the kernel's page cache for any readable file — corrupting the in-memory representation of privileged binaries like /usr/bin/su without touching the on-disk version.

The result is a deterministic, race-free, ~732-byte exploit that grants root on essentially every major distribution shipped since 2017. Microsoft's own analysis notes that the bug works against Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16, and that because the page cache is shared between containers and the host, it also enables cross-container attacks and container escape. CISA added Copy Fail to its Known Exploited Vulnerabilities catalog on May 1, and SecurityWeek subsequently confirmed that exploitation in the wild has begun. Patches are available in Linux kernel 6.18.22, 6.19.12, and 7.0; distribution-specific updates are rolling out through May.

Why it matters: A 732-byte exploit that reliably grants root across nearly every Linux distribution and breaks container isolation is the kind of finding that shifts cloud threat models. For Kubernetes operators specifically, this isn't just a host-level concern — a single compromised pod can become a path to the underlying node. Patch kernel packages immediately on any host running untrusted workloads, and apply the AF_ALG socket creation block as a stopgap if a reboot window isn't available immediately. If you can't patch quickly, treat any local code execution event on a vulnerable host as potentially privileged until the kernel is updated.

Read more at Help Net Security

APT28 walked back through Microsoft's incomplete February patch for ten more weeks

On April 28, CISA and Microsoft confirmed that CVE-2026-32202, a Windows Shell spoofing vulnerability, is being actively exploited in the wild. The flaw stems from an incomplete patch for CVE-2026-21510 — one of the two LNK-file vulnerabilities Microsoft fixed in February that APT28 (Fancy Bear) chained to bypass SmartScreen and execute arbitrary code. The February patch successfully blocked the original RCE, but as Akamai researchers documented, it didn't prevent the more subtle credential-leakage path: when a user simply opens the folder containing a malicious LNK file, Windows Explorer attempts to render the shortcut's icon, which initiates an SMB connection to the attacker's server and triggers an automatic NTLM authentication handshake. The attacker walks away with the victim's Net-NTLMv2 hash — usable for NTLM relay attacks or offline cracking — without the user ever opening the file.

Microsoft pushed a fix for CVE-2026-32202 on April 14 but didn't flag it as exploited at the time, meaning many security teams had no urgent prompt to prioritize it. CISA's confirmation of active exploitation came two weeks later, on April 28, and the vulnerability was added to the Known Exploited Vulnerabilities catalog the same day. Affected systems include a range of supported Windows 10, 11, and Windows Server versions.

Why it matters: Two patterns from this story are worth carrying forward. The first is the structural risk of incomplete patches: a vulnerability that is "fixed" but still leaks credentials is operationally a different category than one that is fully closed, and a serious defense team should treat patch verification as separate from patch deployment. The second is the value of egress controls. Even with the April 14 patch applied, blocking outbound SMB at the network perimeter is the kind of control that turns a credential-leak vulnerability into a contained one. If you've delayed the April Patch Tuesday rollout for any reason, treat this as urgent — APT28 already has 10 weeks of working access.

Read more at Help Net Security

Trellix discloses source code repository breach

On May 2, Trellix confirmed that attackers had gained unauthorized access to a portion of its internal source code repository. Trellix — formed from the 2021 merger of McAfee Enterprise and FireEye — is one of the largest XDR and endpoint security vendors in the market, with more than 50,000 business and government customers and over 200 million endpoints under management. The company said it identified the compromise "recently," engaged outside forensic experts, and notified law enforcement. Based on its investigation to date, Trellix says it has found no evidence that its source code release or distribution process was tampered with, that the stolen code has been exploited, or that customer data was accessed.

What the company has not yet disclosed is the window of intrusion, the attribution, or which specific products had source code exposed — the three details that determine how worried downstream customers should be. The disclosure follows a string of source-code and developer-tooling compromises in recent weeks, including the Checkmarx and Bitwarden CLI compromise we covered last week and the Vercel breach two weeks earlier. Independent security researchers have publicly raised the question of whether the Trellix incident is connected, though no evidence of that link has been disclosed.

Why it matters: A source code breach at an endpoint security vendor poses a different threat model than one at most other software companies. Source code from a defensive product gives attackers a roadmap of detection logic, evasion opportunities, and a head start on building EDR-bypass tooling for the very environments Trellix is deployed to protect. Even if no customer data was accessed, the long-tail risk is that future attacks against Trellix-protected environments may benefit from this incident. Customers running Trellix products should ask their account teams three questions: which repositories were affected, what the dwell time before discovery was, and whether any product binaries are being recompiled and re-signed as a precaution. The lack of attribution this early is unusual and warrants paying close attention to follow-up disclosures over the next two weeks.

Read more at The Hacker News

Vect 2.0 ransomware turns out to be a wiper because of a bug in its own encryption code

On May 4, Check Point Research published a technical analysis of Vect 2.0, a ransomware-as-a-service operation that has been functionally destroying victim data rather than encrypting it. The flaw lies in Vect's own encryption routine: for any file larger than 128 KB, the malware discards the decryption material needed to reverse the operation, leaving the file permanently unrecoverable — even for victims who pay the ransom. The bug affects all three of Vect's cross-platform builds, covering Windows, Linux, and ESXi environments. Earlier reporting from Help Net Security on April 29 first surfaced the issue after Check Point researchers gained access to Vect's affiliate panel and ransomware builder by registering an account on BreachForums — Vect had announced a partnership with the forum that distributed an "affiliate key" to every registered user, which gave defenders an unusually clean view of the operation's internals.

Check Point's analysis describes Vect 2.0 as one of the more capable RaaS offerings to launch in 2026 — modular, well-documented for affiliates, with cross-platform support and a polished management panel. The encryption flaw is, in the researchers' framing, "ransomware by design, wiper by accident." Whether or not affiliates of the operation realize what's happening, every successful Vect deployment is now functionally an irrecoverable destructive attack on its target. Some Vect victims who paid the ransom this spring have been told by recovery firms that the operators are unable to decrypt their files — not because they refuse, but because the data the decryption routine needs no longer exists.

Why it matters: For victims, this changes the math on negotiation entirely. If your incident response runbook for a ransomware event includes "evaluate paying as a recovery option," that option is not actually available against Vect — pay or don't pay, files larger than 128 KB are gone. Backups and immutable storage move from "good practice" to "the only practice that matters." More broadly, this is a useful reminder that ransomware groups are software vendors, and software vendors ship bugs. Some of those bugs will continue to favor defenders, and some will produce destructive outcomes for victims that even payment can't reverse — a category of risk that needs to be reflected in every incident response plan that still treats ransomware as a recoverable event.

Read more at Check Point Research

Final thoughts

The thread tying this week's stories together is the time gap between when a problem first existed and when it actually got contained — and, in Vect's case, the gap between what attackers thought they were doing and what they were actually doing. The cPanel bug was exploited for nine weeks before a patch arrived and, within days of disclosure, had spawned ransomware, botnet, and espionage campaigns running in parallel. Copy Fail has been sitting in the Linux kernel since 2017. APT28 had a working credential-theft path for ten weeks after Microsoft's "fix." Trellix's source code window of intrusion is, as of this writing, still undisclosed. Vect's affiliates have been destroying victim data they thought they were holding hostage.

A second pattern worth noting: AI-tooling vulnerabilities are accumulating quickly. The past week alone produced a critical RCE in Google's Gemini CLI build action, a SQL injection in the LiteLLM proxy (CVE-2026-42208) that was exploited within 36 hours of disclosure, CVE-2026-26268 in the Cursor coding agent enabling RCE through a cloned malicious repository, and a Microsoft Entra ID privilege escalation flaw tied specifically to the Agent ID Administrator role. The same dynamics that made supply chain attacks the dominant story of 2024 and 2025 are now playing out one layer up, in the AI tooling layer that more and more organizations have rolled into their development pipelines.

None of those windows are going to close through better patching alone. The organizations weathering this kind of week well are the ones that assume something is already in progress — that some critical software is unpatched, that some user has clicked the wrong link, that some lateral movement has already started — and design controls that limit the blast radius regardless. Egress filtering, kernel isolation, identity-based access controls, and an inventory of every AI tool with access to a developer's environment are not glamorous, but they're what stands between a single compromise and a bad week. Check back next Tuesday for another roundup.

Ready to see how OpenVPN can help protect your organization from attacks?

Try the self-hosted Access Server solution or managed CloudConnexa service for free — no credit card required.

See Which One is Right for You

Related posts from OpenVPN

Subscribe for Blog Updates