Atrilya
All analyses
Server & LinuxHighReference · CVE-2026-46300CVSS 7.8

Fragnesia (CVE-2026-46300): from webshell to root, the second step

Published

Fragnesia is a local privilege escalation in the Linux kernel’s XFRM ESP-in-TCP subsystem, found by William Bowling (V12) and disclosed on 14 May 2026. An unprivileged local user writes arbitrary bytes into the page cache of read-only files (`/usr/bin/su`, for instance) and becomes root.

Where does the patch stand?

Fixed: kernel patch of 13 May 2026, distribution updates rolling out

What does the Fragnesia flaw actually do?

Logic defects in how shared page fragments are handled during `skb` merging in the ESP-in-TCP subsystem allow chosen bytes to be injected into the page cache of key binaries, through a `splice` + ULP sequence.

The kernel patch is dated 13 May 2026, disclosure 14 May. CVSS 7.8. A public proof of concept exists and works on Ubuntu. Reports differ on in-the-wild exploitation: some vendors report it, others observe none. Earlier "Dirty Frag" patches do not cover this flaw; blacklisting the module protects against both.

Does a "local" flaw really mean "low risk"?

A local privilege escalation is never the first step of an attack. It is the second. The first is code execution through the web front: an unpatched Magento flaw, a WordPress plugin that accepts a PHP file, a webshell dropped three weeks earlier.

Chained, the two turn an application defect into full server compromise: root, persistence, access to every other site hosted on the same machine.

What can an edge filter do, and what can it not?

To be clear: AtriShield does not patch the kernel. No filter placed at the edge can stop a process already running on the machine from exploiting a local flaw. That one is fixed by updating your distribution, full stop.

What an edge filter does is remove the first step. Without initial code execution through the web application, local escalation has no starting point. That is exactly why virtual patches on application flaws matter so much: they break the chain where it begins.

What should you do today?

Apply the fixed kernel from your distribution, and reboot: a patched kernel that is not loaded protects nothing.

Until the reboot window, blacklisting the affected module is the recommended mitigation.

Shrink the web surface in parallel: that is the part of the problem you can act on immediately, without rebooting anything.

Who is affected?

  • Linux kernel: XFRM ESP-in-TCP subsystem
  • Kernel patch released 13 May 2026, disclosure 14 May 2026
  • CVSS: 7.8, local privilege escalation to root on the machine
  • Public proof of concept, working on Ubuntu; earlier "Dirty Frag" patches do not cover it

How does AtriShield stop it?

Virtual patch (Business and Enterprise): the flaw is neutralised at the entrance of your server, without changing your application and without waiting for a maintenance window. Security metadata is reported to your console.

  • ✓AtriShield does not patch the kernel: this one is fixed by updating your distribution.
  • ✓What it cuts is the first step: code execution through the web application, without which local escalation has no starting point.
  • ✓Virtual patches on application flaws (Magento, WordPress, extensions) directly reduce the odds of an attacker getting that foothold.
  • ✓HAProxy logs stay on your server: after an incident, the timeline can be rebuilt without depending on a third party.
Exploit→AtriShield×Magento

Sources

Analysis published by Atrilya Solutions, based on public security reporting. The links above point to the original sources.

More analyses

Running an exposed server?

We review your exposure together (which applications, which versions, how much surface), then switch AtriShield on in observe mode: you see what would be blocked before anything is.

Talk to an Atrilya Solutions engineer