Linux Kernel 'Fragnesia' Vulnerability (CVE-2026-46300): Which Versions Are Safe and How to Patch

The Linux kernel carries a vulnerability tracked as CVE-2026-46300, nicknamed "Fragnesia." It sits inside the kernel's IPsec network-encryption code (the XFRM ESP-in-TCP subsystem), and it lets any user who can log into the server escalate to root — the top-level administrator account that can do anything on the machine. The affected range is kernels built before the fix landed on May 13, 2026. Every currently shipping major Linux — Ubuntu, RHEL, AlmaLinux, Debian, SUSE, Amazon Linux — is already patched. If you keep your kernel updated and reboot, no extra action is needed.

The fix went into the upstream kernel as the patch "net: skbuff: preserve shared-frag marker during coalescing" on May 13, 2026, and distributions rolled it out from that day onward. The flip side: any kernel built before May 13 and never updated — self-built Linux, EC2 / GCE / Azure VMs that haven't rebooted in a while, on-prem Jenkins or bastion hosts, Docker host fleets — is still exposed. Exploitation needs nothing more than an ordinary login account; no extra password and no special configuration. A working proof-of-concept (PoC, a program that reproduces the attack) circulated at disclosure, and it has been confirmed to work on Ubuntu.

As of July 23, 2026 — roughly two months after disclosure — there is still no solid report of this hole being exploited in a real attack. But the technique is public and the population at risk is every Linux server, so that is no reason to leave old kernels running.

Which Versions Are Safe — Fixed Kernels by Distribution

Fragnesia hits kernels built before the May 13, 2026 fix; anything built after includes it. As of July 23, 2026, the kernels shipping across each series (kernel.org's stable 7.1.4 and the long-term-support lines 6.18.39 / 6.12.96 / 6.6.144 / 6.1.177 / 5.15.211 / 5.10.260, among others) all carry the Fragnesia fix. Here is where the major distributions stand.

Checking is simple. Run uname -r to see the running kernel version, update via your package manager (apt on Ubuntu/Debian, dnf on RHEL-family), and reboot. A kernel update only takes effect after a reboot, so a server that was updated but not rebooted is still running the old kernel — watch for that. Ubuntu's security page (updated July 20, 2026) and AlmaLinux's notice list the fixed version numbers for each line. Managed host OSes where the cloud provider handles patching — AWS Bottlerocket, Google Kubernetes COS (Container-Optimized OS), Azure CBL-Mariner — already received the fix through automatic updates after disclosure.

Who Targets This Hole, and What For

The people who want Fragnesia are not an abstract "hacker collective"; they are the same operators already running the earlier Copy Fail and Dirty Frag through the same workflow. Ransomware crews who buy a non-root shell on a shared cloud VPS and reach into the neighboring tenant's production database, industrial spies after a competitor's source code, customer lists, and sales material, targeted attackers who already have a non-root shell from a web app bug and are hunting for the next rung to root, and initial-access brokers (IABs) who resell rooted Linux hosts in bulk to other groups are the active customer base. What they take with root is what is sitting on the server itself: the password hashes in /etc/shadow, SSH private keys, database credentials, Kubernetes service-account tokens, AWS IAM role credentials, and the customer records in the production database. One ordinary shell account plus a single Fragnesia run is the whole stairway up to a root that can reach all of the above. Because only the in-memory copy of /usr/bin/su is rewritten and the on-disk file is left untouched, file-integrity tooling such as AIDE and Tripwire keeps reporting "no change."

In security terms this is a kernel-level "local privilege escalation (LPE)" — climbing from a low local privilege up to administrator. The attacker never has to start with root; any lower rung is enough — a non-root shell taken through a web app, their own tenant on a rented VPS, a developer's bastion SSH account — and the climb from there to root is a single step. The post-root playbook is well-rehearsed: persistence as a systemd unit, a planted file in /etc/sudoers.d/, an extra key in ~/.ssh/authorized_keys, and edits to auth.log and wtmp to erase the entry trace. A Kubernetes node pulls in the whole cluster; a container host pulls in every co-tenant; an Active Directory–joined Linux server pulls in every Windows endpoint in the domain. And because the design leaves no on-disk evidence, even after a successful compromise the box keeps "looking as if nothing happened."

CVSS (a 0–10 severity score) of 7.8 reflects only the local-vector assumption. What an organization running Linux servers actually faces is not a single root compromise; it is the fact that same-shaped bugs kept surfacing after Fragnesia, walking through the same spot again and again. That is precisely why leaving no server unpatched is the line between keeping and losing the trust of your customer data and internal network.

What Happens 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. The May 13 patch closes the hole by carrying that flag through the coalescing step.

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 a Cluster of Same-Shaped Bugs Appeared

Fragnesia was the third of three same-shaped bugs disclosed within three weeks in spring 2026. It is tempting to call this a coincidence; the structure says otherwise. The three bugs share a deeper pattern.

The first, Copy Fail (CVE-2026-31431, disclosed April 29), used the kernel's cryptographic API endpoint (AF_ALG) combined with splice() to write four bytes into the page cache. The second, Dirty Frag (CVE-2026-43284 / 43500, May 7), abused the in-place decryption path of IPsec ESP and RxRPC. The third, Fragnesia (May 13), exploits 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 differ, 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. Dirty Frag and Fragnesia surfaced from adjacent ESP code within one week of each other not because the attack surface is broad — it's that a spotlight has finally been pointed at that layer.

When this article first ran, we wrote that "a fourth and a fifth bug of the same family will arrive soon." That prediction held. In the two months since, a string of same-family flaws has landed: DirtyClone (CVE-2026-43503, June), which corrupts file-backed memory via a cloned network packet; pedit COW (CVE-2026-46331, June); GhostLock (CVE-2026-43499, July), latent since 2011 and yielding root in about five seconds with a public exploit; and RefluXFS (CVE-2026-64600, July 22), which exploits a race in the XFS filesystem. The read of "old design, all at once on the inspection bench" became plain reality.

The Lineage of Recent Linux LPE Bugs

Linux has produced "single bug, every major distribution affected" vulnerabilities before. Laying out the lineage shows just how unusual the pace since spring 2026 is.

From PwnKit to Looney Tunables, this kind of bug appeared once every one or two years. Starting with Copy Fail, the pace accelerated to one every two weeks, and it kept going — DirtyClone, pedit COW, GhostLock, Januscape (CVE-2026-53359), RefluXFS. The locations vary — authorization tool, pipe, library, crypto endpoint, IPsec, filesystem — but the operational impact rhymes. "If you run Linux, an administrator takeover is possible on practically any server" has been repeated over and over since spring 2026.

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

What Can Happen on an Unpatched Server

Now that fixes are out, the risk that remains is only on servers you haven't updated. The line to draw here is "managed OS, or self-managed Linux." Managed host OSes where the cloud provider handles patching — AWS Bottlerocket, Google Kubernetes COS, Azure CBL-Mariner — already got the fix through automatic updates after 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 until you update and reboot them yourself. That is exactly where attackers look.

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.

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

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 laid in the original construction are still in operation. The engineers who can read the blueprints have aged out, and no one had 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. The fourth and fifth bursts did, in fact, happen on other floors (DirtyClone, GhostLock, RefluXFS, and more). 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)

The rollout across major distributions is already complete. Ubuntu, AlmaLinux, RHEL, Debian, SUSE, Amazon Linux, and CloudLinux all shipped fixed kernels as of July 23, 2026. See the "Which Versions Are Safe" table above for exact numbers. Update via apt / dnf, then reboot to apply. 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 you can't reboot immediately — or as defense-in-depth after you 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"

This family of bugs shares 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 this cluster is concrete: subsystems carrying twenty-year-old design will keep surfacing new bugs — and indeed, DirtyClone, GhostLock, and RefluXFS followed Fragnesia. 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.

Current Risk Level and Preparing for What Follows

Is Fragnesia actually being exploited? As of July 23, 2026 — roughly two months after disclosure — there is still no solid report of exploitation in a real attack. The PoC is public and confirmed to run on Ubuntu, but the prevailing view is that there is no evidence of in-the-wild abuse (Tenable's FAQ). A few outlets claim in a headline that it is "exploited in attacks," but their body text offers no supporting evidence.

The US government agency CISA's KEV catalog — its list of vulnerabilities "known to be exploited in the wild" — does not list Fragnesia (CVE-2026-46300) or Dirty Frag (CVE-2026-43284 / 43500) as of July 23, 2026. Within this lineage, the only one on KEV is the first, Copy Fail (CVE-2026-31431), whose remediation deadline (May 15, 2026) has already passed. In Japan, JPCERT/CC (the country's public coordination center for security information) noted Fragnesia in its Weekly Report of May 20, 2026, calling out the public PoC and urging vendor patches.

There is no need to panic, but no reason to leave it either. The attack requires "a user who can log into the server," so it is not the kind of thing that takes over a machine on its own. On the other hand, with a root-takeover PoC in circulation, the bar drops to almost nothing once that one prerequisite is met. 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 — rise to the top of the update priority list.

Apply a current kernel that includes all three (Copy Fail, Dirty Frag, Fragnesia) and reboot. Audit IPsec-related modules against actual business need. Add the user-namespace restriction. And wire up a vendor security-notice feed (Red Hat, Ubuntu, SUSE). Because same-family bugs like DirtyClone and RefluXFS keep arriving, make this your standing baseline rather than a one-time response.

This article is part of the "Linux Kernel Vulnerability Chain Series." Continuation of the lineage is tracked on this site.

FAQ

References

• ▸NVD - CVE-2026-46300 Detail (NIST)
• ▸Tenable - Fragnesia (CVE-2026-46300) FAQ (exploitation assessment)
• ▸CloudLinux Blog - Fragnesia (CVE-2026-46300) Mitigation and Kernel Update
• ▸TuxCare - Fragnesia (CVE-2026-46300): A New Linux Kernel LPE
• ▸Wiz Blog - Fragnesia: Linux Kernel LPE via ESP-in-TCP
• ▸Ubuntu Security - CVE-2026-46300 (fixed versions, updated July 20, 2026)
• ▸AlmaLinux - Fragnesia (CVE-2026-46300)
• ▸kernel.org (current kernel series)
• ▸JPCERT/CC Weekly Report 2026-05-20 (Fragnesia mention)
• ▸Microsoft Security Blog - Dirty Frag Linux vulnerability
• ▸Tenable - Dirty Frag Linux Kernel LPE FAQ
• ▸Rescana - DirtyClone (CVE-2026-43503)
• ▸Qualys - RefluXFS (CVE-2026-64600)
• ▸This site - Linux "Copy Fail" Vulnerability Risks Worldwide Server Takeover
• ▸This site - NGINX Rift (CVE-2026-42945): Affected versions, how to check, and workaround