Topic starter
21/08/2026 4:51 pm
TL;DR: Fragnesia, tracked as CVE-2026-46300, is a Linux kernel local privilege escalation in the ESP-in-TCP path that lets an unprivileged attacker corrupt the page cache for a read-only binary and execute the modified cached copy as root, according to Corgea. The case shows why disk integrity alone is not enough when kernel networking paths expose cache-resident write primitives.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “Fragnesia: Linux ESP-in-TCP bug revives page-cache root escalation”.
Key questions
Q: What breaks when Linux page-cache corruption is possible on a shared host?
A: Read-only binaries are no longer a reliable trust boundary if the kernel can alter cached pages in memory.
Q: Why does Fragnesia create root risk even without changing the on-disk file?
A: Because the attack changes the page cache, which is the in-memory version the kernel actually executes.
Q: What are the signs that Linux kernel privilege escalation is being attempted through XFRM paths?
A: Watch for unexpected namespace creation, XFRM netlink activity from non-network-management processes, and unusual splice() or sendfile() use immediately before a setuid binary executes.
Practitioner guidance
- Restrict vulnerable ESP modules on hosts that do not need them Blacklist esp4 and esp6 where IPsec is not required, remove the modules from active hosts, and regenerate initramfs if your distribution needs that step for boot-time enforcement.
- Limit untrusted local code paths on shared Linux systems Tighten user namespace creation, avoid granting CAP_NET_ADMIN without a reviewed need, and treat self-hosted CI runners and developer workstations as untrusted execution zones.
- Add runtime detections for XFRM abuse Alert on unexpected XFRM netlink activity, unusual use of splice() or sendfile(), and namespace creation by application workers or build jobs that should not manage IPsec.
Bottom line: Fragnesia shows that Linux privilege boundaries can fail in memory even when the filesystem still looks clean.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:09 pm
Fragnesia is a host governance failure as much as a kernel vulnerability. The bug matters because organisations often treat disk integrity and package state as sufficient proof that a Linux host is safe. Fragnesia shows that the kernel can still execute altered memory-resident code even when the file on disk looks untouched. The practitioner conclusion is that host trust must include runtime state, not just filesystem state.
A question worth separating out:
Q: How should teams respond when a Linux host may already have cache-resident root compromise?
A: Patch or mitigate first, then reboot or flush caches to remove in-memory modifications. After that, treat the host as fully compromised, review recent local code execution and CI activity, and rotate credentials reachable from the affected workloads before returning the system to service.
👉 Read our full editorial: Fragnesia shows how page-cache corruption can turn local code into root