Linux's "Old Pipes" Burst Three Times in Three Weeks. Root-Takeover Chain Won't Stop.

Your server may already be compromised without you noticing. This is the third time in three weeks. Another "old pipe" inside the Linux kernel has burst.

CVE-2026-46300, nicknamed "Fragnesia". Disclosed on May 13, 2026, it follows Copy Fail on April 29 and Dirty Frag on May 7 — three local privilege escalation bugs in the Linux kernel, all within three weeks, all letting an unprivileged user become root. A working proof-of-concept was published alongside the disclosure. Anyone can run it on a Linux server they already have shell access to.

This is not three coincidences. Old layers of the Linux kernel are peeling off, all at once. This article covers what Fragnesia is, why three of these landed in three weeks, and whether patching actually ends it — framed as decision material for operators.

What Happened with Fragnesia

Fragnesia lives in the Linux kernel's IPsec implementation — specifically the XFRM ESP-in-TCP subsystem. IPsec is the protocol family that encrypts network traffic; it powers VPNs, internal networks, and cloud-to-cloud links.

The bug itself is in a kernel function called skb_try_coalesce(). This is the function that consolidates incoming network data across the kernel's socket buffers (skbs). During this consolidation, a flag called SKBFL_SHARED_FRAG was failing to propagate to the merged buffer.

That flag is a note that says: "this memory fragment isn't owned by the kernel — it was spliced in from somewhere else, such as a file's page cache." When the note disappears, the kernel writes to that memory thinking it owns it. What it actually overwrites is the in-memory copy of a read-only file.

According to Wiz's analysis, the attacker turns that accident into a tool. By steering the ESP-in-TCP decryption path, they overwrite the in-memory copy of /usr/bin/su — the command that promotes a session to root. The on-disk file is untouched. Only the cached memory copy is rewritten. The next time anyone invokes su, the rewritten instructions execute and root is taken.

The bug was discovered and published by William Bowling of V12 Security. The only prerequisite for exploitation is unprivileged local user access — a shared cloud account, a developer login, or a non-root shell taken from a compromised web app. From any of those starting points, an attacker climbs one rung to full administrator.

Why Three in Three Weeks

It is tempting to call this a coincidence. The structure says otherwise. The three bugs share a deeper pattern.

The first, Copy Fail, used the kernel's cryptographic API endpoint (AF_ALG) combined with splice() to write four bytes into the page cache. The second, Dirty Frag, abused the in-place decryption path of IPsec ESP and RxRPC. The third, Fragnesia, exploits the socket buffer fragment management on the ESP-in-TCP path.

In all three, the kernel mistakes a memory fragment borrowed from another region for its own — and ends up overwriting an in-memory copy of a file as a result. The attack surfaces are different, but the underlying design philosophy — "manage page-cache and kernel buffer ownership through implicit assumptions" — has been the same for roughly twenty years.

Since 2025, the tools used to find these bugs have leapt forward. syzkaller (Google's kernel fuzzer), KASAN (Kernel Address Sanitizer), and AI-assisted code analysis have made layers that "no one had eyes on" suddenly visible. The reason Dirty Frag and Fragnesia surfaced from adjacent ESP code within one week of each other is not that the attack surface is broad — it's that a spotlight has finally been pointed at that layer.

Old design, all at once on the inspection bench. That is the structural reality of what is unfolding in the Linux kernel right now. Readers should be told plainly: a fourth and a fifth bug of the same family will arrive soon.

The Lineage of Three-Week Linux LPE Bugs

Linux has produced "single bug, every major distribution affected" vulnerabilities before. Laying out the lineage shows just how unusual a three-week burst is.

From PwnKit to Looney Tunables, this kind of bug appeared once every one or two years. Starting with Copy Fail, the pace has accelerated to one every two weeks. The locations vary — authorization tool, pipe, library, crypto endpoint, IPsec — but the operational impact rhymes. "If you run Linux, an administrator takeover is possible on practically any server" has now been repeated three times in three weeks.

This site treats the Copy Fail article as the starting point of the lineage, with this piece as its sequel. When the next bug of the same family arrives, the decision frameworks from both articles should be directly reusable.

What Could Happen on Your Server Tonight

Your server may already be quietly welcoming "a new owner." This is where three privilege escalations in three weeks finally lands in everyday terms.

The first line to draw is "managed OS, or self-managed Linux." Managed host OSes where the cloud provider handles patching — AWS Bottlerocket, Google Kubernetes COS (Container-Optimized OS), Azure CBL-Mariner — receive automatic host updates within hours to days of disclosure. The other side — self-built Linux, user-managed EC2 / GCE / Azure VMs, on-prem Jenkins hosts, self-hosted GitHub Actions runners, Docker host fleets — stays bare-skin. That is exactly where attackers are looking right now.

Translated into business scenarios:

All of these start from "an unprivileged user with shell access." A non-root shell obtained through a web-app RCE, a developer bastion account, a neighboring tenant in a shared cloud environment — any one of these is a valid starting point.

How would you notice if it happened? Because files on disk are never modified, conventional file-integrity monitoring (Tripwire, AIDE) misses it entirely. Here are signals operators can plausibly feel on the ground.

Turning the front-door knob, you feel a momentary catch — SSH login pauses for a beat; an unfamiliar process appears in the post-login listing. Appointments you don't remember writing have appeared in your planner — crontab or /etc/cron.d/ contains jobs you didn't add. The diary has grown unusually thick overnight — journald log size has ballooned, and ESP-family function calls such as xfrm_state_alloc appear at anomalous frequency. This month's electric bill is three times last month's — your AWS / GCP / Azure invoices spike, and CloudTrail shows unexpected bursts of AssumeRole.

Technically: anomalous xfrm-related messages in dmesg, setuid(0) calls in auditd with unexpected parent process lineage, and unusual root-shell acquisitions surfaced in your SIEM. The reader's responsibility ends at "awareness of your own scope." Continued tracking of the lineage is something this site's editorial team takes on.

How Fragnesia Differs from Dirty Frag, One Week Earlier

Fragnesia is not a missed fix for Dirty Frag. It is a separate bug. But the attack surface and the mitigations are so close that a brief side-by-side is useful.

Dirty Frag (May 7) is a combination discovered by independent researcher Hyunwoo Kim of two flaws: CVE-2026-43284 (IPsec esp4/esp6) and CVE-2026-43500 (RxRPC). By combining them, an attacker can make in-place decryption pass over memory borrowed from outside the kernel — pipe pages reaching the socket via splice() or sendfile() — and gain a write primitive into the page cache. Both flaws score CVSS 7.8. Microsoft has suggested that exploitation in the wild may already have been observed.

Fragnesia (May 13) demonstrated that even on kernels carrying the Dirty Frag fix, a different path produces the same write primitive. The offending function is skb_try_coalesce(), sitting in the ESP-in-TCP path. According to CloudLinux's explainer, the upstream Dirty Frag patch did not close this avenue.

Side by side, the commonality is clear. Both live in code surrounding Linux's IPsec implementation. Both turn mismanaged ownership of externally borrowed memory fragments into root. The mitigations (next section) are the same procedure. The exploitation techniques are independent — but operationally, treat them as one set.

This article does not unpack Dirty Frag in depth. Tenable's Dirty Frag FAQ and Wiz's technical writeup cover the essentials.

The HVAC Ducts of a 30-Year-Old Office Building

Enough technical narrative. A different image may help.

The inside of the Linux kernel resembles the air-conditioning ducts of a 30-year-old office building. The exterior — the application layer — has been remodeled, and the interior looks modern. But above the ceiling, twenty-year-old pipes that were laid in the original construction are still in operation. The engineers who can read the blueprints have aged out, and no one has inspected the ducts for a long stretch.

In 2026, thermal cameras (next-generation fuzzers like syzkaller) and new staff (AI-assisted analysis) finally entered the ceiling. On April 29, a crack appeared in one pipe (Copy Fail). One week later, a pipe on another floor split open (Dirty Frag). Another week after that, an adjacent pipe on a different floor burst (Fragnesia). The cracks are in different places — but every one of them is "a pipe installed twenty years ago under the same design philosophy."

Patching the individual broken pipes does not remove the others. The same plumbing runs through the entire building. A fourth or fifth burst, on another floor, is coming soon. Operators have two jobs in parallel: seal the broken pipe quickly (apply the patch), and shut off the main valve on floors that don't need that plumbing at all (disable unused modules).

What Operators Should Do — A Multi-Layer Frame, Now with an "Old Layer" Layer

The Copy Fail article proposed four layers: patching, module disabling, user-privilege reduction, and detection. To that, we add a fifth — "old-layer cutoff."

Layer 1: Apply the Patch (Highest Priority)

Major distributions are already moving. AlmaLinux pushed patched kernels to its testing repository on May 13; Ubuntu and CloudLinux are on the same track. Kernel builds dated May 14, 2026 or later include the Fragnesia fix. Even if you have already applied Copy Fail and Dirty Frag patches, Fragnesia is a separate bug — you will need a new reboot.

Layer 2: Disable Unused IPsec Modules (Fast and Effective)

If patches can't land immediately — or as defense-in-depth after they do — blacklist the relevant kernel modules in /etc/modprobe.d/. The targets are esp4, esp6, and rxrpc. If you already disabled them for Dirty Frag, the public Fragnesia PoC is already blocked. Most web servers and databases never use these modules, so disabling them has no operational impact. Servers that genuinely use IPsec (VPN gateways) need Layer 1 done first.

Layer 3: Restrict User Namespaces and seccomp

The attack starts from "an unprivileged user with shell access." Disabling unprivileged user namespaces narrows the paths an attacker can leverage. Set kernel.unprivileged_userns_clone=0 via sysctl. In container environments, seccomp filters can be used to restrict the relevant system calls.

Layer 4: Detection — Distrust "the File Is Untouched"

All three bugs share an awkward property: the on-disk file is never modified. Standard file integrity checks won't catch them. Instead, watch for anomalous in-memory write patterns with eBPF, centralize setuid-binary execution logs in syslog, and alert on unexpected root shell acquisition.

Layer 5: Old-Layer Cutoff — Close the Main Valve on Subsystems You Don't Need

The lesson of three bugs in three weeks is concrete: subsystems carrying twenty-year-old design will continue to surface new bugs. Kernel subsystems that your servers don't actually need should be blacklisted from loading at boot (/etc/modprobe.d/blacklist.conf). For most servers that don't use IPsec, batch-disabling esp4 / esp6 / rxrpc / xfrm-related modules is a realistic baseline that protects against the next bug of the same family before it lands.

Preparing for Bug Four and Five — and How We're Tracking It

Is Fragnesia actually being exploited yet? At the time of writing, no fully weaponized attacks have been confirmed. That said, GreyNoise's IP telemetry is starting to show a small uptick in XFRM-related netlink probes. PoC fragments from researchers have surfaced on Hacker News, Reddit (r/netsec), and X, and turning them into a copy-paste weapon is a matter of time.

In three-step terms, the threat temperature is yellow — the eve of weaponization. Not red (widespread real-world damage), but not blue (theoretical only) either. "If you don't act between tonight and tomorrow morning, the odds of getting hit climb every day." Add to that the time pressure of Copy Fail's CISA KEV deadline landing on May 15.

Since the Fragnesia disclosure, the Linux kernel mailing list has been combing through adjacent subsystems. syzkaller reports, kernel.org commit history, and issues in torvalds/linux are filling up with crash reports in ESP, XFRM, and crypto code. The question is no longer "will another one drop?" — it's "when, and where."

For operators, here is what to do right now. Apply the three patches (Copy Fail, Dirty Frag, Fragnesia). Audit IPsec-related modules against actual business need. Add the user-namespace restriction. Wire up a vendor security notice feed (Red Hat, Ubuntu, SUSE). Treat this as the default posture for the next several weeks.

A working root-takeover PoC is in the open, so the barrier to attack has collapsed. As recent supply-chain attacks have shown, attackers move quickly on anything that works. Shared cloud environments, CI/CD runners, shared development servers, container hosts — anywhere unprivileged user accounts mingle — climb to the top of the priority list.

This article is Report #3 in the "Linux Kernel Vulnerability Chain Series." Continuation of the lineage is being tracked on this site.

References

• ▸NVD - CVE-2026-46300 Detail (NIST)
• ▸CloudLinux Blog - Fragnesia (CVE-2026-46300) Mitigation and Kernel Update (May 13, 2026)
• ▸TuxCare - Fragnesia (CVE-2026-46300): A New Linux Kernel LPE (May 13, 2026)
• ▸Wiz Blog - Fragnesia: Linux Kernel LPE via ESP-in-TCP (May 13, 2026)
• ▸AlmaLinux - Fragnesia (CVE-2026-46300): Patched kernels available in testing (May 13, 2026)
• ▸Ubuntu Security - CVE-2026-46300
• ▸Phoronix - Fragnesia Made Public As Latest Linux LPE Vulnerability (May 13, 2026)
• ▸Cybersecurity News - Fragnesia Linux Vulnerability Let Attackers Gain Root Privileges - PoC Released (May 13, 2026)
• ▸Gotekky - Fragnesia (CVE-2026-46300): The Third Linux Kernel Root Exploit in Three Weeks (May 13, 2026)
• ▸Microsoft Security Blog - Active attack: Dirty Frag Linux vulnerability expands post-compromise risk (May 8, 2026)
• ▸Tenable - Dirty Frag Linux Kernel LPE FAQ
• ▸Wiz Blog - Dirty Frag (CVE-2026-43284) Linux Privilege Escalation
• ▸This site - Linux "Copy Fail" Vulnerability Risks Worldwide Server Takeover. Three Days Left. (May 12, 2026)