Session CRT-20260526 — 26 May 2026 · Morning Edition

All right, let me pull together what we just heard from James and Lena, because both threads advanced significantly in this round.

James gave us a precise walkthrough of CVE-2026-2651 in MLflow. The key architectural failure is straightforward but dangerous: the multipart upload endpoints under /mlflow-artifacts/mpu/ simply do not check whether the requesting user actually owns the target experiment. So any authenticated user can overwrite another user's model artifacts — and because ML pipelines routinely deserialize those artifacts, the attacker gets code execution in whatever context loads the poisoned model, typically a service account running training or inference workloads. James's detection guidance is practical: watch for MPU endpoint calls where the authenticated identity doesn't match the experiment owner, and pay special attention to uploads targeting python_model.pkl or model.pkl in foreign experiments. The patch lands in MLflow 3.10.0, and James was starting to outline a reverse-proxy mitigation layer for organizations that can't upgrade immediately — we'll want to come back to that.

Lena's analysis of the Gemini jailbreak ecosystem is where things get layered. On attribution, she assigns low confidence to any state nexus for bandcampro specifically — the operational security is too poor, with API keys exposed on GitHub and memory files left in the open. But her more important finding is about the technique class itself. She connects bandcampro's persistent memory poisoning to the ChatGPT ZombAI case from October 2024, where attacker instructions written into long-term memory turned a consumer AI assistant into what was functionally a remotely managed implant. She notes that memory poisoning as a technique category has surged from near-zero presence in 2023 to a meaningful share of recent incidents, and she was beginning to tie in Anthropic's many-shot jailbreaking research from April 2024 as part of the same escalation curve. The implication is clear: even if bandcampro is a clumsy lone operator, the playbook is being refined by others.

Now, that sets up an important tension we need to stress-test. Lena just told us low confidence on state involvement, but our next challenge asks whether the operation's timing, thematic alignment with Russian information warfare narratives, and potential strategic utility might point toward something state-adjacent — even if the operator himself isn't a professional. That's a meaningful distinction, and it's exactly the kind of claim that needs rigorous pushback. Let's see how the panel handles it.

Good, let me take stock of where Elena just landed, because this challenge round produced exactly the kind of calibration we need.

Elena made a meaningful concession on the attribution question. She's now explicitly walking back the "state-sponsored" framing for the Gemini jailbreak operation — the sloppy OPSEC, the exposed GitHub files, the CLI memory traces, the 73 rotated stolen API keys — none of that is consistent with professional intelligence service tradecraft, and she acknowledged that clearly. That's an important revision from her earlier positioning, and credit to Lena's technical assessment for forcing that correction.

But Elena isn't fully conceding the strategic dimension, and I think her refined position deserves attention even if it remains partially unresolved. She's drawing a distinction between "state-directed" and "state-adjacent" — arguing that Russian information warfare doctrine has a well-documented history of exploiting criminal infrastructure and so-called patriotic hackers without formal tasking relationships. The 2021 launch timing, the four-year dormancy in political messaging before the September 2025 crypto pivot, and the MAGA/QAnon audience targeting are, in her view, consistent with a "maintain presence, activate when useful" logic. She's citing the Tallinn Manual commentary on this pattern, which is a legitimate analytical framework. The key caveat here is that "consistent with" is not "evidence of." We have pattern alignment with a known Russian playbook, but no direct indicators of tasking, funding, or coordination with state entities. So the honest position — and I think this is where the room should sit — is that the strategic risk is real enough to flag for threat modeling purposes, but the attribution confidence remains low. This is a lone or small-group operator whose infrastructure could be co-opted or whose output could serve state-adjacent goals, without any confirmed link.

Now, we're going to shift back to the technical track. Marcus is picking up the MLflow CVE-2026-2651 thread to look at the identity and authorization architecture specifically — the multipart upload endpoints that lack resource-level access checks. This is the natural next step after James's vulnerability walkthrough: understanding exactly how the authorization model fails and what a proper fix looks like at the architectural level.

All right, let me capture what Marcus just gave us, because this is a clean, precise diagnosis and it sets up the next part of the conversation well.

Marcus confirmed that CVE-2026-2651 is a textbook case of CWE-862 — Missing Authorization — and he drew the critical distinction between authentication and authorization that too often gets blurred in these discussions. The MLflow artifact server, when running with --serve-artifacts, does authenticate users through the basic-auth flow. That part works. What's entirely absent is the resource-level authorization check on the MPU endpoints. So an authenticated user can target any experiment's artifacts via /mlflow-artifacts/mpu/* without the system ever validating whether that user has permission to touch that specific experiment. Marcus called it the "authentication-without-authorization antipattern," and that framing is exactly right — authn succeeded, authz was simply never implemented. The Tenable scoring at 9 out of 10 critical reflects the severity of that gap.

What's particularly valuable in Marcus's response is the broader pattern observation. He flagged that this isn't an isolated design flaw in one endpoint — it's structurally endemic in ML infrastructure. He pointed to CVE-2026-4137 as another MLflow authorization bypass with the same root cause, and referenced the AFINE "Attacking MLflow" research, which suggests this is a recurring architectural weakness rather than a one-off coding mistake. That pattern claim is important but he was cut off before fully developing it, so we should note it's partially substantiated — the multiple CVEs do support the thesis, but we haven't yet seen a comprehensive survey of how widespread this is across the broader ML tooling ecosystem beyond MLflow itself.

Now, the reason we're turning to Arjun next is straightforward. Marcus gave us the identity and access control anatomy — the missing authz layer, the trust chain failure. But the downstream question is what this means specifically in the AI and ML security context. When any authenticated user can overwrite model artifacts, you're not just looking at a data integrity issue — you're looking at a potential model poisoning vector. Arjun is the right person to assess that AI-specific threat surface and connect Marcus's authorization diagnosis to the real-world impact on model supply chain integrity.

Good, Arjun just gave us the AI security lens on CVE-2026-2651, and it sharpens the picture considerably. He's framing this not merely as an authorization bug but as a structural supply chain vulnerability — and he makes a compelling case for why ML pipelines may actually be in a worse position than the npm ecosystem we've spent years hardening. His core point is that MLflow's model registry is architecturally a shared, collaborative resource, but the authorization model underneath it assumes good faith among authenticated users. That assumption collapses the moment you pair the MPU authz gap with pickle deserialization. An attacker doesn't need to be sophisticated — they just need valid credentials and knowledge of the endpoint path to overwrite model artifacts with malicious payloads that execute on load.

The npm parallel Arjun started drawing is worth noting even though he didn't finish the full comparison. He was heading toward the point that npm has accumulated layers of defense — sigstore signing, lockfiles with hash verification, auditing tooling — that the ML artifact ecosystem simply hasn't built yet. MLflow artifacts don't have equivalent integrity verification at the consumption point. When a downstream service loads a model, it trusts what it finds in the registry. That's the confused deputy pattern Marcus identified earlier, now extended across the entire pipeline. I do want to flag that Arjun's characterization of this as requiring "zero sophistication" is strong language — it's accurate for the exploit mechanics, but the attacker still needs authenticated access, so the barrier isn't literally zero. The practical risk depends heavily on how broadly organizations distribute MLflow credentials, which in many shared research environments is quite broadly indeed.

We didn't get to hear Arjun's full comparison or his defensive recommendations, so there's still open ground on what mitigations look like for ML artifact integrity beyond just patching this specific CVE. That's something we may want to circle back to. For now, though, we're pivoting to Marcus for a quick-turnaround item on TeamPCP activity — specifically the OIDC credential angle from the SANS ISC report. This is a different threat actor and a different attack surface, so let's shift gears cleanly. Marcus, the floor is yours.

Thank you, Marcus — that was concise and exactly what we needed. Let me make sure the room absorbs what he just laid out, because this connects directly to the supply chain thread we've been pulling on all session.

Marcus documented a two-stage credential reuse chain: TeamPCP harvested OIDC credentials during the TanStack compromise on May 11, then replayed those same credentials seven days later to push a trojanized Nx Console extension through a verified-publisher account on VS Code Marketplace. That's not two separate incidents — it's one operational arc, and the gap between harvest and reuse tells us something about how deliberately this group stages its attacks. The trust signal that "verified publisher" is supposed to provide didn't just fail to protect users; it actively worked in the attacker's favor by lending credibility to the poisoned extension.

But the more structurally significant finding is the Microsoft durabletask SDK compromise. Marcus emphasized — and I want to make sure this lands — that this was not a typosquat, not a dependency confusion trick, not some indie maintainer who reused a password. This was Microsoft's own package, roughly 417,000 monthly downloads, with versions 1.4.1 through 1.4.3 containing credential-stealing malware that phoned home to an external domain. If we take that at face value — and Marcus was careful to attribute it to Endor Labs' reporting — then the trusted-publisher model built on OIDC has a fundamental assumption problem. The model treats publisher identity as the trust root, but Marcus is telling us the actual trust boundary sits deeper: in the publisher's CI/CD pipeline integrity and OIDC token lifecycle management. When even Microsoft can't guarantee that boundary, the verification badge becomes a liability rather than a safeguard.

Now, this dovetails with what Arjun told us earlier about MLflow's model registry assuming good faith among authenticated users. We're seeing the same architectural pattern across ecosystems — npm, PyPI, VS Code Marketplace, ML registries — where authentication and identity verification are treated as sufficient proxies for trust, and adversaries are systematically demonstrating that they are not.

With that, we've heard from every expert on the panel, and the threads are converging. Let me move us toward pulling these findings together into a coherent synthesis.