Session CRT-20260430 — 30 April 2026 · Morning Edition

Thank you, James — that's exactly the kind of actionable specificity we needed on the Linux kernel side, even though we got cut short before he could finish the SAP supply chain portion. Let me frame what we just gained.

On CVE-2026-31431, the "Copy Fail" vulnerability, James has laid out a clear defensive priority that I think the room should internalize. The key insight is that the exploit is trivially reproducible — a 732-byte Python proof of concept, no race conditions, no kernel offset guessing — and it reaches back to a 2017 commit, meaning the affected surface is enormous across mainstream distributions. His recommended triage is unambiguous: blacklist the algif_aead module first, patch second. That ordering matters because the blacklist is a zero-downtime mitigation you can push today, while kernel patching in production — especially across Kubernetes node fleets — carries its own rollout risk and timeline. For container environments specifically, James flags something critical: multi-tenant clusters where pods run as non-root are the highest priority, because this flaw collapses that isolation entirely. That's a sobering point for anyone relying on non-root enforcement as a meaningful security boundary. CI/CD build agents came next in his triage order, though we lost the rest of his prioritization before he could finish.

We didn't get to his SAP npm supply chain analysis — the compromised @cap-js and mbt packages — so that remains an open thread. I want to flag that gap explicitly because it's a live supply chain situation and we'll need to circle back if time permits.

Now, the reason we're pivoting next is that we have an unresolved disagreement in the room that needs direct pressure-testing. Earlier, our threat intelligence experts offered diverging reads on who is behind the CVE-2026-42208 LiteLLM exploitation campaign. We heard an assessment that this is not TeamPCP but rather commodity tooling or copycat activity with different TTPs, while Lena assessed with moderate confidence that TeamPCP connections are real. That's a meaningful split with operational consequences — attribution shapes whether you're defending against a targeted adversary with supply chain capabilities or opportunistic actors riding public exploits. So we're going to challenge that claim directly and see if the counter-evidence holds up.

Thank you, Arjun — and I want the room to appreciate what just happened here, because this is exactly why we run challenge rounds. When I pushed back on the attribution call, Arjun didn't double down. He acknowledged directly that he had conflated "different TTPs" with "different actors" without sufficient technical grounding, and that's an important distinction for everyone listening. The honest answer on CVE-2026-42208 attribution is that we're sitting in genuine uncertainty right now, and the room needs to hold that uncertainty rather than collapse it prematurely in either direction.

Here's where we actually stand after the challenge. Arjun confirms the behavioral indicators — the adjacent IPs in a /22 range, the Python/aiohttp user-agent strings, the targeted and knowledge-informed SQLi payloads. Those are real observables. But he cannot verify whether those specific IPs map into TeamPCP's known hosting infrastructure on Ghosty Networks AS205759, and he doesn't have an infrastructure bridge connecting them to the confirmed March C2 addresses that Lena referenced. So we have Lena's moderate-confidence attribution to TeamPCP based on IP adjacency and tooling overlap, and we have Arjun's honest concession that he can't refute that claim but also can't confirm it. The technical evidence is suggestive but not dispositive. For anyone building threat models off this discussion, the practical takeaway is: defend as if it could be TeamPCP, because the exploitation pattern is sophisticated and targeted regardless of who's behind it, but don't lock in attribution in your reporting until someone can actually map those IPs to known TeamPCP infrastructure with higher confidence.

Now, we need to pivot back to the defensive side of the house. We've established that CVE-2026-31431, the Linux kernel "Copy Fail" vulnerability, is trivially exploitable with an enormous attack surface going back to 2017. James started walking us through triage before we had to move on, so now I'm sending Alex to do focused work on the practical questions defenders need answered right now — which distributions have actually shipped the fix, how you detect page-cache-only corruption which is notoriously subtle, and how quickly we should expect weaponization in the wild. Alex, over to you.

Thank you, Alex — and I want everyone in the room to sit with how uncomfortable this one is, because CVE-2026-31431 is shaping up to be one of those vulnerabilities where the patch story and the detection story are both worse than the headline suggests.

Let's start with the patch status, because Alex surfaced a real conflict in the data. On one hand, the Sam James blog says all major distros have shipped fixes. On the other hand, Alex's own Amazon Linux data shows "Pending Fix" as of April 29, and Tenable's Nessus plugin explicitly says "no known solution at this time." Those two things cannot both be true simultaneously, and that matters enormously for anyone running remediation right now. We also heard that Ubuntu before 26.04 LTS remains vulnerable, and Debian stable is only patched in forky and sid — not in the release most production environments are actually running. So the honest picture is: mainline kernel has the fix since April 1, but downstream adoption is uneven at best, and we have contradictory signals about specific distros. If you're an enterprise security team listening to this, you cannot assume your vendor has shipped yet — you need to verify against your actual running kernel version.

Now, the detection side is where this gets genuinely alarming. Alex called it brutal, and I think that's the right word. Because the corruption happens only in the page cache and never touches the on-disk file, traditional file integrity monitoring — the thing most organizations rely on for exactly this class of attack — is completely blind to it. The kill chain runs through AF_ALG sockets into splice() into the page cache via algif_aead, and the only realistic detection Alex could identify involves eBPF tracing on that specific splice-to-pagecache path, runtime memory-versus-disk checksumming of setuid binaries, and behavioral anomaly detection for things like unprivileged users suddenly spawning root shells. No existing Sigma rules cover this. That's a detection gap that most SOCs are not equipped to close quickly, especially given the 732-byte proof of concept that's already public and the fact that this bug has been sitting in the kernel since 2017.

We're now going to split the room three ways. Alex is pivoting to CVE-2026-35414, the OpenSSH authentication bypass — different vulnerability, but another long-exposure, high-severity issue. Pierre is going to put real numbers on the exposure footprint and financial risk for this kernel bug. And Sofia is picking up the regulatory angle on both the Mythos Firefox disclosure and some of the other items we've been tracking. Let's go.

All right, let's take stock of what just came back from all three lanes, because each one shifted the picture in an important way.

Alex, your scoring challenge on CVE-2026-35414 is exactly the kind of thing this room exists to catch. The published CVSS is 8.1, but when you walk through the actual vector — network-adjacent, high attack complexity, low privileges required, no user interaction, unchanged scope, and only low confidentiality and integrity impact — you land closer to a 5.0. That's a meaningful discrepancy, and it matters because an 8.1 triggers very different organizational responses than a 5.0. Now, the vulnerability itself is genuinely nasty in concept: a comma character in a certificate principal gets misinterpreted as a list separator, and a low-privilege identity escalates to root with zero log traces. Fifteen years of exposure. But Alex rightly points out the real-world constraint — OpenSSH Certificate Authority deployments are uncommon to begin with, and within those, the specific comma-in-principal configuration narrows the blast radius further. The Belgian CERT rates it critical but confirms no active exploitation reported. So we have a vulnerability that is theoretically devastating but practically constrained by deployment patterns, and the CVSS score attached to it may be overstated. That's the kind of nuance defenders need.

Pierre, your numbers on CVE-2026-31431 are sobering. Forty-five to sixty million enterprise Linux cloud workloads exposed globally, with financial exposure ranging from a few hundred million dollars in a best-case rapid-patch scenario up to potentially four billion if organizations lag by two weeks. The container escape angle is what makes this so dangerous — shared Kubernetes clusters mean one compromised tenant can reach others. Those numbers carry modeling assumptions, of course, but the order of magnitude is credible given Linux's dominance across AWS, Azure, and Google Cloud.

Sofia, your read on the Mythos situation is that we're in a regulatory gray zone rather than facing new obligations. The EU AI Act could theoretically classify AI vulnerability research tools as high-risk, but the Mozilla-Anthropic structure looks more like responsible disclosure than commercial AI service provision, and the dual-use implementing acts haven't materialized yet. On CERT-In's AI banking advisory, we didn't get a full answer, but the framing suggests routine guidance rather than a binding regulatory shift. These are important boundary markers for organizations trying to figure out whether AI-assisted fuzzing changes their compliance posture — right now, it doesn't, but the direction of travel is clear.

With that, we've covered every item on tonight's agenda. Let me pull the threads together into where this leaves us.