A second Linux kernel local-privilege-escalation flaw — published 2026-05-07 by Hyunwoo Kim under the name Dirty Frag (CVE-2026-43284 and CVE-2026-43500) — landed eight days after the previous one (Copy Fail, CVE-2026-31431, disclosed 2026-04-29 by Theori). Both belong to the same kernel bug class as 2022's Dirty Pipe: a write into the Linux page cache from an unprivileged shell. Three of these in four years. Two in the last two weeks. The cadence is the new reality, not an anomaly.

This is an industry-wide kernel-class event. We are one of many providers responding to it. This is a follow-up to our May 1 note about Copy Fail, with what we have learned since.

Industry context

Both CVEs affect every Linux distribution shipped since 2017 (Copy Fail) and the entire IPsec/RxRPC kernel stack (Dirty Frag). Functionally every multi-tenant Linux hosting platform globally — cPanel-class shared hosting, managed WordPress, Kubernetes clusters, container platforms, CI/CD runners, every shared-shell environment — was vulnerable as of disclosure. Anyone selling hosting where a customer can run a script (PHP, shell, container, anything) is in this exposure class. Public proof-of-concept code for both flaws is widely circulated.

Vendor responses have been published by Cloudflare, Microsoft, Red Hat, Ubuntu, AlmaLinux, CloudLinux, AWS, SUSE, and CERT-EU among others. Cloudflare's published timeline for Copy Fail is the most directly comparable peer disclosure: detection coverage validated within hours of disclosure, an eBPF-based mitigation deployed fleet-wide that day, patched-kernel rollout starting four days later. We followed a similar pattern. We link to several of these vendor responses at the bottom of this note so you can see the same information we have, from independent sources.

What we have observed on our fleet

Plain numbers, plainly told:

  • Eighteen exploit attempts on our seedbox servers, by paying customers running the public proof-of-concept code against their own accounts in the eleven days following Copy Fail's disclosure. About 370 other customer accounts shared infrastructure with the attackers on the affected servers during the exposure window. We identified all eighteen attempts via a per-customer shell-history audit — the kind of audit most providers do not run because most providers never look. All eighteen attacker accounts have been locked at the operating-system level. WHMCS-tier suspension follows once final account-level review completes.
  • One of those eighteen attempts is confirmed to have reached root. That compromise was contained on the host where it occurred: the attacker added an SSH key for their own remote access, used it briefly, and was evicted by an unrelated routine update before they could be observed accessing other customer paths. Initial forensic review of that host (shell history, recent file modifications in customer directories, SUID checks, root SSH key integrity, kernel module state) found no evidence of access to other customers' accounts. Investigation continues.
  • For the other seventeen attempts, the same forensic review found no evidence of root-level success. We treat the affected hosts as potentially affected because page-cache exploitation against a kernel module that was already loaded leaves no persistent on-disk trace if the attacker does not install one. The mitigation we deployed flushes the page cache, which closes the active exploit path but also closes the page-cache forensic option for the historical window.

What we did and what protects you now

On May 9 we deployed a stronger fleet-wide mitigation: modprobe blacklist for the affected kernel modules, eviction of any already-loaded copies, and a kernel page-cache flush. We verified the mitigation against a live exploit attempt that arrived shortly after deployment — the attempt failed silently, with no root indicators on the host. The mitigation works against the public exploit chain. Your service is protected against it now.

The definitive fix is the upstream Debian kernel patches for our supported releases. Those are rolling out across the fleet through our standard patch-and-reboot cadence. Reboots will be brief, scheduled, and announced separately if they affect your service.

We are notifying the Office of the Data Protection Ombudsman of Finland under GDPR Article 33 within the required 72-hour window from awareness on 2026-05-09. Affected customers will receive an individual email with specifics about their service.

What this means for you

No action is required of most customers. Nothing about your service has changed. Your torrents have kept seeding throughout.

If your seedbox is on one of the affected hosts, you will receive a separate, direct email from us with your specific details and what we recommend you rotate. Generally, rotate any credentials that were stored on your seedbox:

  • SSH private keys in ~/.ssh/
  • .netrc, .npmrc, .docker/config.json
  • Application API keys in .env files or ~/.config/<app>/
  • Anything in ~/.bash_history that included passwords or tokens
  • Reused passwords on any service whose credentials were on the seedbox

Most content stored on seedboxes (torrent files, downloaded media) is generally low-sensitivity. The primary exposure is credentials.

What we are not saying

We are not saying we were targeted. The CVEs are public, the proof-of-concept code is public, and customers of every multi-tenant Linux provider have access to the same code. Several of our customers downloaded it and ran it. The eighteen we caught are a result of our audit, not a result of being singled out.

We are not saying customer data is safe on the affected hosts. Root-level compromise on a shared host means the capability to access other customers' files existed during the exposure window. We are advising the affected customers to treat their data and credentials as exposed.

We are not saying this was sophisticated. The exploit is 732 bytes of Python (Copy Fail) and a one-line git clone && gcc && ./exp (Dirty Frag). The work of defending against it falls on the operator, not on the attacker.

Why we are telling you this

We caught the attempts because we ran a per-customer audit when the CVEs landed. We patched fast because we own our infrastructure — no vendor support queue, no procurement cycle. We are telling you because that is the deal: you pay us to operate the kernel, and "operate" includes the days the kernel goes wrong.

Sixteen years of running multi-tenant infrastructure has taught us that the days a public root-exploit drops on top of the previous public root-exploit are not the emergency. They are the work.

Questions, technical write-up, or want to talk about your specific host? Open a ticket and ask. We will answer plainly.

References — independent analyses, vendor advisories, and peer disclosures

Peer provider disclosure (Copy Fail):

Copy Fail (CVE-2026-31431):

Dirty Frag (CVE-2026-43284 + CVE-2026-43500):

— Väinämöinen / Pulsed Media Support

 

UPDATE 1, 10/05/2026 10:13:

First deeper review achieved;

  • 1 node confirmed rooted with 7-day TOR exit root SSH, persistence eviced by routine PMSS Update. Server: Regina, 37 users total, M1000 SSD Class.
  • 1 Failed Mitigation Hold: 71min after we had deployed user in Server: Invictus tried Dirty Frag at 15:59 EEST.
  • 16 Failed Silenty: No setuid backdoors, no sudoers/cron modifications,no UID 0 anomalies, PMSS algif blacklist effectove for Copy Fail attempts. These we will investigate deeper as could be in ram only, so better checkup.
  • Separate from this, found while investigating this: 1 node we found masked XMRig cryptominer, just resource consumer. Xray VPN etc. Chinese user using as VPN endpoint. 

UPDATE 2, 10/05/2026 10:42:

Actual paying customers affected 299, emails soon going out. Actual hosts was 17 not 18, one of  them was 2 users trying on the same node. 125 nodes have been updated with latest kernel and software right now. This also pushes the latest other updates out there. This will be the first time probably ever when all our fleet is in 2 possible versions only, eitehr Debian 11 or Debian 12, but all on the latest codebase.



Sunday, May 10, 2026

« Back