Fragnesia (CVE-2026-46300): What Panelica Users Need to Know

What is Fragnesia?

On May 13, 2026, security researcher William Bowling of the V12 security team (confirmed also by Zellic) disclosed CVE-2026-46300, named Fragnesia. CVSS score: 7.8 (High). It is a local privilege escalation in the Linux kernel — meaning an unprivileged local user can reach root without any network access or special privileges beyond a local shell.

The root cause is in skb_try_coalesce(), a kernel function that merges socket buffer fragments when transferring paged data between socket buffers. When it moves paged fragments from one socket buffer to another, it fails to propagate the SKBFL_SHARED_FRAG flag. That flag marks fragments backed by page-cache pages — read-only memory shared with the filesystem. Without it, the kernel no longer knows the fragment is shared, and the XFRM ESP-in-TCP receive path performs in-place AES-GCM decryption directly over those page-cache pages. The result is an arbitrary write primitive over read-only files in memory — including executables like /usr/bin/su.

The affected kernel modules are esp4, esp6, and rxrpc. These handle IPsec encapsulation and the AFS/kRPC transport. On most general-purpose hosting servers these modules are not loaded, but they can be auto-loaded on demand if the right socket family is opened by an unprivileged process. That auto-load behavior is the entry point.

This is the third Linux kernel local privilege escalation in two weeks, following CopyFail (CVE-2026-31431) and DirtyFrag (CVE-2026-43284). All three share the same underlying pattern: a flag or state marker not correctly carried through a fragment-merging operation, leaving the kernel believing a shared page is safe to write. Fragnesia appears to be follow-on research from the DirtyFrag investigation.

Why We Are Writing This

This is a kernel-level vulnerability, not a Panelica vulnerability. Panelica itself is not affected. What is affected is the underlying Linux OS that Panelica runs on — Ubuntu and Debian. We are writing this because our users follow security advisories through us, and we want to give a clear, calm picture of what this means for a typical Panelica server.

The short version: most Panelica users do not need to do anything beyond their normal system update routine.

Are You Affected?

For the vast majority of Panelica users, the answer is: probably not in any meaningful way.

Exploitation requires the esp4, esp6, or rxrpc kernel modules to be loaded or auto-loadable. On a typical hosting server running Panelica — web hosting, email, databases, DNS — none of these modules serve any purpose and are not loaded. You can verify with a single command:

lsmod | grep -E 'esp4|esp6|rxrpc'

If that returns no output, those modules are not currently loaded. On most Panelica servers this will return nothing, because:

• esp4 / esp6 are IPsec transport mode modules. Unless you have configured IPsec tunneling between servers, these are not present.
• rxrpc handles the AFS/OpenAFS distributed filesystem. If you are not running an AFS environment — which is extremely rare in hosting contexts — this module is not loaded.

If the command returns no output, your attack surface for this CVE is effectively zero without further action.

Distribution Patch Status

Ubuntu Security has published an advisory for this CVE. Debian Security Tracker has done the same. Patched kernels are already available in the standard apt repositories for both distributions.

For most Panelica users, the only action needed is:

sudo apt update && sudo apt upgrade
sudo reboot

If you are on a regular update schedule, you may have already pulled the patched kernel. After the next reboot, you are done.

When You Might Need to Act Sooner

There are specific configurations where the risk is higher and faster action is warranted:

• Multi-tenant servers with customer shell access. If your hosting customers have SSH logins with full or limited shell access, any one of them is a potential local user who could attempt exploitation.
• CI/CD runner hosts. Self-hosted runners executing pipeline jobs from untrusted contributors — open source projects, external contractors — are a classic local unprivileged execution surface.
• Dev or staging servers with third-party developer accounts. A developer or contractor with a shell login has enough access to attempt this.

If any of the above apply to you, do not wait for the next maintenance window. Either update and reboot now, or apply the module blacklist as an interim measure:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

The first command writes a modprobe blacklist preventing auto-load of these modules and attempts to unload them if currently present. The second drops the page cache to flush any potentially affected pages. Both commands are safe to run on servers that do not use IPsec or AFS — which describes almost every hosting server.

Note the operational caveat: if your servers rely on IPsec transport mode for inter-server traffic, blacklisting esp4/esp6 will break that. Verify your setup before applying. On standard Panelica hosting deployments, this is not a concern.

The Bigger Picture

Three kernel LPEs in two weeks is not coincidence. Researchers who worked on DirtyFrag examined adjacent code and found Fragnesia. The same pattern — fragment flag propagation gaps in socket buffer handling — likely has more instances. Community researchers are already circulating analysis of a potential bypass variant through the skb_segment() path, though this has not received official confirmation from major distribution security teams at the time of writing.

The module blacklist mitigation covers both the confirmed path and the reported variant, because blocking these modules prevents the XFRM/esp receive path from running regardless of which internal function routes data into it. On servers where esp4, esp6, and rxrpc serve no operational purpose, the blacklist is a reasonable permanent configuration even after applying the kernel patch.

Summary

If you run a standard Panelica server for web hosting, email, and databases:

• Run lsmod | grep -E 'esp4|esp6|rxrpc'. Empty output means you have no active attack surface.
• Run apt update && apt upgrade and reboot at your next convenient window. The patched kernel is already in the Ubuntu and Debian repositories.
• No other action is required.

If you have untrusted shell users — hosting customers with SSH, CI runners, external developer accounts — treat the kernel update as higher priority. Apply the module blacklist immediately if a reboot cannot happen within a few hours.

For questions or discussion, the community is active at forum.panelica.com.