Notifications
Clear all
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.
NHIMG editorial — based on content published by Corgea covering Fragnesia and CVE-2026-46300: Linux kernel local privilege escalation in ESP-in-TCP
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: What breaks when Linux hosts allow ESP-in-TCP on untrusted workloads?
A: The host loses the assumption that read-only binaries are safe from local manipulation.
Q: Why do namespace-enabled CI runners increase kernel exploit risk?
A: Because user and network namespaces expand the paths available to local code, which can make a kernel bug reachable from ordinary build or automation jobs.
Q: How do security teams know if a Linux kernel exploit is actually active?
A: They should watch for runtime signals such as unexpected namespace creation, XFRM activity from non-networking processes, unusual splice or sendfile use, and root shells after setuid execution.
Practitioner guidance
- Disable vulnerable ESP-related modules where IPsec is not required Blacklist esp4, esp6, and related modules on hosts that do not need them, and regenerate initramfs where required so the block survives reboot.
- Restrict namespace creation on untrusted Linux workloads Limit unprivileged user namespaces and network namespaces on self-hosted CI, developer workstations, and shared nodes unless a reviewed use case requires them.
- Remove unnecessary container and job privileges Avoid granting CAP_NET_ADMIN to containers and build jobs unless the workflow explicitly depends on it, because the exploit path becomes easier when XFRM operations are reachable.
What's in the full analysis
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Public proof-of-concept behaviour showing how the page-cache write primitive is triggered on affected kernels
- Distribution-specific exposure notes for CloudLinux, Ubuntu, Amazon Linux, and other kernel lines
- Exact mitigation commands, module blacklist details, and reboot or cache-drop considerations
- Vendor and tracker status references for teams validating patch coverage across fleets
👉 Read Corgea's analysis of CVE-2026-46300 and Linux page-cache corruption →
Fragnesia and Linux page-cache corruption: what kernel teams missed?
Explore further
21/08/2026 5:09 pm
Page-cache corruption is now an identity and workload trust problem, not just a kernel bug. When a local process can turn cached binary state into root execution, the real failure is governance over which workloads are trusted to reach kernel networking surfaces. That intersects directly with IAM, PAM, and NHI controls because CI runners, build agents, and automation jobs often operate with implicit trust and elevated local capability. Practitioners should treat host-level privilege boundaries as part of identity governance.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who should own response when a kernel local privilege escalation is disclosed?
A: Ownership should sit with the platform or infrastructure team, with security coordinating exposure review and containment. The response scope is host hardening, kernel patching, module removal, and verification of any workloads that ran on the affected nodes before remediation.
👉 Read our full editorial: Fragnesia shows how page-cache corruption can turn local code into root
