We predicted the next wave. Five days later, we found it ourselves.

Here we go again. Five days is how long it took between me writing in our last blog post that we predicted that vulnerabilities would come in waves and realizing that this wave isn't done yet. I'd love to tell you I was surprised but I wasn't. What I can tell you is that this time we did something different. Instead of just patching what the researchers found, we did additional research and found another vulnerable code path.

Let me back up.

On May 13, a new local privilege escalation exploit called Fragnesia (CVE-2026-46300) was publicly disclosed. The Dirty Frag fix taught the kernel's ESP decryption path to check whether a buffer's pages are shared with the page cache before decrypting in place. But that fix relies on a flag being set correctly, and five code paths in the kernel silently drop it. Fragnesia exploits those paths. If the flag gets stripped before the packet reaches ESP, the check passes and the kernel decrypts in place over page-cache pages. Same result as Dirty Frag. An attacker overwrites a cached binary like /usr/bin/su, and the next user who runs it gets a root shell.

There's another thing worth noting. Fragnesia was disclosed without any coordination with kernel maintainers or Linux distributions. The public proof-of-concept code was released at the same time that the patch was submitted to the upstream kernel. No advance notice, no embargo period, no time for vendors to prepare patches before the exploit was public. That's the reality we're operating in, and it's why speed matters so much in our response.

The mitigation is the same one that covers Dirty Frag: block the esp4 and esp6 kernel modules. Our knowledge base article walks through the details. If you applied the Dirty Frag mitigations and haven't reverted, you're already covered for Fragnesia as well.

Now, here's where the story gets interesting.

In the Dirty Frag blog post, I wrote that "we need upstream communities to be more proactive in looking for similar vulnerabilities." That was a call to action not just for the broader community but for us as well. The discussion on LKML shows that kernel developers were already looking at other paths. We decided that we needed to do that as well.

After the Fragnesia disclosure landed, Sultan Alsawaf, one of our kernel engineers, used Claude Code to systematically audit the networking stack in the Linux kernel for additional code paths where the same class of bug (a missing SKBFL_SHARED_FRAG flag propagation) could be exploited. The upstream V2 patch from Hyunwoo Kim (who had written the original Dirty Frag fix and stepped up to address Fragnesia) fixed three sites in skbuff.c, but Sultan wanted to know if there were others that hadn't been found.

There were.

Sultan discovered that skb_gro_receive() in the kernel's GRO (Generic Receive Offload) subsystem had the exact same flag-propagation bug. When GRO merges socket buffer fragments, it moves fragment descriptors without propagating the shared-fragment flag. After the merge, the ESP fast path treats page-cache fragments as writable — and you get the same page-cache corruption primitive as the original Fragnesia exploit, just through a completely different entry point.

Sultan didn't stop at finding the bug. He built a full proof-of-concept exploit that targets /usr/bin/su through this GRO path, confirmed it works, and posted both the exploit and the fix to the Linux kernel mailing list: Sultan's LKML post. Within hours, Hyunwoo Kim folded Sultan's GRO fix into the upstream V3 patch. In the process, Hyunwoo spotted another problematic GRO path that Sultan's patch hadn't covered and fixed that too. The resulting V3 patch covers all five vulnerable sites across two source files, showing the power of working with the community.

This is exactly the model I was calling for. Instead of waiting for the next researcher, or the next attacker, to find the GRO path, we found it ourselves and contributed it upstream. That's what it looks like when the community is proactive.

Looking ahead, Sultan is continuing to use AI to audit for any remaining vulnerable paths in the kernel's fragment handling code. We're investing in this proactive approach because we believe it's the right way to operate. The waves of AI-discovered vulnerabilities I predicted in my last post are here, and the answer isn't just faster patching — it's getting ahead of the curve. Finding the bugs before the next disclosure, contributing fixes upstream, and making the entire ecosystem safer.

Three page-cache privilege escalations in three weeks. Copy Fail, Dirty Frag, Fragnesia. The pattern is clear, and it's not slowing down. But this time, we didn't just react. We went looking, we found additional paths that needed fixing, and we gave it back to the community. That's the standard we're holding ourselves to.

Check out our Fragnesia KB article for current patch status and mitigation guidance.