Security researchers disclosed 'Dirty Frag,' a privilege escalation vulnerability affecting all major Linux distributions since 2017. The embargo was broken when a third party revealed details, suggesting possible in-the-wild exploitation. Unlike previous kernel bugs, this one bypasses existing mitigations.Another week, another critical Linux kernel bug that's been lurking for years. The question isn't whether the kernel has bugs - it's why we keep finding them after they've been exploited.According to security researchers at Wiz, Dirty Frag is a privilege escalation vulnerability that allows local attackers to gain root access on affected systems. It works across all major Linux distributions - Ubuntu, Debian, Red Hat, CentOS, and others. And it's been present in the kernel since 2017.What makes this particularly concerning is that Dirty Frag bypasses the mitigations put in place after the previous "Copy Fail" vulnerability. Security teams thought they'd fixed the class of bugs that allowed privilege escalation through kernel memory corruption. Turns out there's another path.The vulnerability itself involves the ESP (Encapsulating Security Payload) and RxRPC (RPC over Reliable Datagram) kernel modules. Technical details aside, the practical impact is straightforward: an attacker with local access can escalate to root privileges reliably.One silver lining: Dirty Frag requires the CAP_NET_ADMIN capability, which is less likely in hardened container environments like Kubernetes with default seccomp profiles. So if you're running properly configured containers, you're probably okay. But plenty of systems aren't hardened.What's particularly troubling is how the disclosure happened. Researchers were working under coordinated disclosure rules - find the bug, notify vendors privately, give them time to patch, then publish details. That embargo was broken when an unrelated third party revealed the vulnerability details publicly.Why would someone break embargo? Usually because they've seen evidence of in-the-wild exploitation. If attackers are already using a vulnerability, keeping it secret only helps the attackers while leaving victims in the dark.This is the eternal tension in security research. Responsible disclosure protects users while vendors develop patches. But if attackers already know about the bug, responsible disclosure just means the good guys stay quiet while the bad guys exploit it.The fact that Dirty Frag has existed since 2017 raises uncomfortable questions. How many systems were compromised because of this bug before it was discovered? How many remain compromised now? If attackers knew about it before researchers did, we may never know the full scope.This is also a reminder that kernel security is hard. The kernel is millions of lines of code written over decades by thousands of contributors. Finding all the bugs isn't realistic. The question is whether we're finding them before attackers do.The answer increasingly seems to be: no. Dirty Frag is at least the third major kernel privilege escalation vulnerability disclosed in the past two years. Each one affects all major distributions. Each one has been present for years. Each one could have been exploited undetected.What's the fix? Patch immediately, obviously. But also: defense in depth. Don't rely on the kernel being bug-free. Use seccomp, namespaces, capabilities restrictions, and other hardening measures to limit what attackers can do even if they find kernel bugs.Container security best practices exist for a reason. Default seccomp profiles block the capabilities needed for Dirty Frag exploitation. Properly configured systems are significantly harder to compromise even when kernel bugs exist.The broader lesson is that treating the kernel as a trusted security boundary is increasingly questionable. Bugs will exist. Some will be found by researchers. Some will be found by attackers. Build systems assuming the kernel might be compromised.That's not defeatism - it's realistic security engineering. The kernel is amazing software that powers most of the internet. It's also complex software with a large attack surface and a long history of security vulnerabilities. Both things can be true.If you run systems - and if you use the internet, you rely on systems whether you know it or not - check for patches. Review your security configurations. Make sure you're not running with unnecessary capabilities enabled.And maybe stop being surprised when researchers find seven-year-old kernel bugs. At this point, it's not a bug, it's a feature. Of the disclosure process, if not the kernel itself.