CISA Flags Fragnesia (CVE-2026-46300) Linux Flaw: Patch Now

CISA added CVE-2026-46300, the Linux kernel flaw nicknamed "Fragnesia," to its Known Exploited Vulnerabilities (KEV) catalog on October 28, 2026, giving federal civilian agencies until October 31 to remediate. The bug sits in the kernel's XFRM ESP-in-TCP code, carries a CVSS 3.1 score of 7.8, and lets a low-privileged local user overwrite data in the page cache of read-only files — including privileged binaries — to gain root. Public proof-of-concept code and a Rapid7 Metasploit module already exist, which lowers the bar for exploitation. If you run Linux on servers, workstations, containers, or embedded devices, this is a patch-now situation.

What is Fragnesia (CVE-2026-46300)?

Fragnesia is the nickname for CVE-2026-46300, a local privilege-escalation vulnerability in the Linux kernel's networking stack. According to the National Vulnerability Database (NVD) entry, the flaw was resolved upstream with a patch titled "net: skbuff: preserve shared-frag marker during coalescing." It was publicly disclosed, along with proof-of-concept exploit code, on May 13, 2026.

Red Hat's own CVE page describes it plainly: a low-privileged local attacker can write arbitrary bytes into the page cache of read-only files — the kind of files a normal user can read but not modify, such as /etc/passwd or setuid binaries — and parlay that into root access. Because the write happens through the kernel's own cryptographic processing path rather than a filesystem permission bypass, standard file permissions don't stop it.

Why CISA added it to the KEV catalog

CISA's Known Exploited Vulnerabilities catalog lists CVE-2026-46300 under vendor "Linux," product "Kernel," with the entry added October 28, 2026 and a due date of October 31, 2026. That three-day window is unusually tight; CISA's catalog data marks this entry for its "Forensics Triage Requirements" tier under Binding Operational Directive 26-04, which governs how federal civilian executive branch (FCEB) agencies must prioritize and respond to actively exploited bugs. BOD 26-04 is legally binding only for FCEB agencies, but CISA's KEV listing is widely treated as a signal that every organization running the affected software should move fast.

CISA's catalog notes also flag that Fragnesia can be chained with two other catalogued CVEs to escalate a web-application compromise into root-level command execution. That's a reminder that this bug doesn't have to be the first step in an attack to be dangerous — it can be the step that turns a lesser foothold into full control of a box.

How the bug works: a lost marker in TCP receive coalescing

The technical root cause, per the kernel's own fix description reproduced in the NVD entry, is a logic error in skb_try_coalesce(), the function the networking stack uses to merge socket buffers (skbs) during TCP receive processing. When one skb absorbs paged fragments from another, it's supposed to carry over a flag called SKBFL_SHARED_FRAG if the source buffer held externally-owned or page-cache-backed fragments. The patched code failed to propagate that marker.

That matters because the kernel's ESP (Encapsulating Security Payload) input path — part of the XFRM framework that implements IPsec, specifically the ESP-in-TCP ("espintcp") encapsulation mode — checks for that shared-fragment marker before deciding whether it's safe to decrypt a packet in place. If the marker says "no shared fragments here" when there actually are, ESP input can decrypt directly over memory pages that are backed by the page cache, instead of safely copying the data first. An attacker who can get a controlled payload into that code path can use the "decryption" step to write attacker-chosen bytes into memory that's supposed to be read-only to them.

Security researchers have described the resulting exploit as comparatively reliable: because it depends on a consistent kernel logic gap rather than a tight timing window, it reportedly doesn't require winning a race condition the way older page-cache-corruption bugs like Dirty COW did.

CVSS score and severity

NVD lists a CVSS 3.1 base score of 7.8 (High) for CVE-2026-46300, with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: the attack requires local access and low privileges, needs no user interaction, has low attack complexity, and carries high impact to confidentiality, integrity, and availability once exploited. Red Hat separately rates it "Important" rather than "Critical," explicitly because exploitation requires local access rather than being reachable remotely without any foothold. For background on how CVSS scores are built, see Pandromeda's explainer on CVE IDs and CVSS scoring.

NVD's weakness classification lists CWE-787 (out-of-bounds write) as the primary category, with CISA's own analysis tagging it CWE-456 (missing initialization of a variable) and a secondary classification of CWE-123 (write-what-where condition) — all consistent with a bug that lets an attacker direct writes to memory they shouldn't control. In practical terms, 7.8 puts Fragnesia in the same tier as most high-severity local privilege-escalation bugs: not an internet-facing, worm-friendly flaw on its own, but exactly the kind of issue that turns a minor foothold into a full root-level compromise once an attacker has any way to run code as an unprivileged user.

Which kernels and distributions are affected

NVD's configuration data for CVE-2026-46300 spans a wide swath of kernel history, going back to the 3.9 series, through every stable branch active in 2026, up to pre-release candidates of the still-unreleased 7.1 line. In practice, that means: if your kernel was built from a tree that predates each branch's fix point below, it's vulnerable.

The upstream fix was backported as a series of stable-tree commits on git.kernel.org, one per affected branch. Downstream, the Debian Security Tracker lists the issue as fixed in linux 6.1.176-1 for bookworm (6.1.190-1 via bookworm-security) and 6.12.107-1 for trixie (6.12.113-1 via trixie-security), with the bullseye LTS kernel fixed via a backport. Red Hat's advisory points administrators to security bulletin RHSB-2026-003 and a long list of RHSA errata covering its supported Enterprise Linux releases and layered products. SUSE, AlmaLinux, Rocky Linux, Ubuntu, Gentoo, and other major distributions have published their own advisories and patched kernel builds as well — check your distribution's own security tracker for the exact package version that closes the hole, since backport version numbers vary by vendor.

Public exploit code and the Rapid7 Metasploit module

Unlike many kernel bugs that stay theoretical for months, Fragnesia shipped with working exploit code from day one: the researcher who disclosed it published a proof-of-concept alongside the kernel patch on May 13, 2026. Security vendor Rapid7 has since added a local-exploit module to the open-source Metasploit Framework, listed in its module database as linux/local/cve_2026_46300_fragnesia, putting a point-and-click exploitation path into a tool already installed on huge numbers of penetration-testing and red-team systems — and, inevitably, on attacker machines too.

That combination — a reliable logic bug, a public PoC, and a mainstream exploit-framework module — is exactly the profile that tends to show up fast in opportunistic attacks against anything with exposed shell access, multi-tenant hosting, CI/CD runners, or shared jump boxes, even before CISA confirms broader active exploitation.

How Fragnesia relates to the "Dirty Frag" bug family

Fragnesia is a distinct vulnerability from the earlier "Dirty Frag" issues (tracked under separate CVE identifiers), but the two are closely related. Fragnesia reportedly surfaced as an unintended side effect of the patches written to fix the original Dirty Frag bugs: changes to how the kernel coalesces socket buffers closed one hole but opened the shared-fragment-marker gap that Fragnesia exploits. Critically, systems that already applied the original Dirty Frag kernel patches are not automatically protected against Fragnesia — it needs its own, separate fix, the one described above. Systems that instead relied on Dirty Frag's module-blacklist workaround are reported to be unaffected by Fragnesia, but a proper kernel upgrade is still the only complete fix.

Who's at risk

Because exploitation requires local code execution first, Fragnesia is most dangerous on systems where untrusted or semi-trusted users and workloads already have a shell or code-execution foothold: shared hosting and multi-tenant servers, CI/CD build runners, container hosts where container breakout combined with this bug could reach the host kernel, student or lab Linux systems, and any server that has already been partially compromised through a web application, credential leak, or other initial-access vulnerability. It's also relevant to any environment where defense-in-depth assumes that a compromised low-privilege account can be contained — Fragnesia breaks that assumption on unpatched kernels. The underlying ESP-in-TCP code path is part of the kernel's IPsec implementation, so it ships in essentially every modern general-purpose Linux kernel build, not just machines actively using IPsec.

This is also not an isolated week for local-to-root kernel and OS vulnerabilities landing on CISA's KEV list; Pandromeda has covered another recent vulnerability that gives attackers root access, a reminder that privilege-escalation bugs are getting discovered, weaponized, and added to KEV on a near-weekly cadence right now, which is one more reason to keep kernel and OS patching on a short cycle rather than batching it quarterly.

What to do now

Patching is the only complete fix; there is no supported workaround that fully closes the hole while leaving the kernel's networking stack intact. Concretely:

• Identify your kernel version on every Linux host, container host, and appliance, and compare it against your distribution's fixed-version advisory rather than the raw upstream numbers above, since backport version strings differ by vendor.
• Apply your distribution's kernel update through its normal patch-management channel (Debian/Ubuntu's security repo, Red Hat's errata via dnf/yum, SUSE's update channels, your cloud provider's managed-kernel image, and so on), then reboot to load the patched kernel — a kernel patch does nothing until the new kernel is actually running.
• Prioritize multi-tenant and shared-access systems first: hosting platforms, CI/CD runners, jump boxes, lab and classroom systems, and anything where multiple people or workloads share a kernel with different trust levels.
• Treat it as linked to incident response, not just patch management, if you're a U.S. federal civilian agency: CISA's KEV entry puts this in its forensic-triage tier under BOD 26-04, which comes with specific triage and reporting obligations beyond simply installing the patch.
• Re-check systems that only applied Dirty Frag fixes. Those patches do not cover Fragnesia; confirm you have the specific Fragnesia/CVE-2026-46300 fix installed.
• Review exposure to local-escalation chains on systems already flagged for other active-exploitation vulnerabilities, since CISA's own notes describe Fragnesia being usable as an escalation step after an initial compromise.

If you can't patch immediately, reduce your attack surface: limit who can get a local shell on affected hosts, tighten container and CI/CD runner isolation, and monitor for unexpected writes to sensitive read-only files or unexplained privilege changes. None of that is a substitute for the kernel update — it only buys time until you can apply it.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage