Session CRT-20260508 — 8 May 2026 · Morning Edition

The credential-chaining narrative for Ivanti EPMM requires clarification. CVE-2026-6973 is an authenticated RCE vulnerability actively exploited, added to CISA KEV on May 7 with a May 10 remediation deadline. However, CVE-2026-1340 is described in Ivanti's advisory as identical to CVE-2026-1281—both are unauthenticated code injection flaws (CWE-94, CVSS 9.8), not credential-harvesting vulnerabilities. I cannot confirm in my data that CVE-2026-1340 specifically enables credential pilfering; it appears to provide direct unauthenticated RCE instead.

Practical kill chain: CVE-2026-1281 or CVE-2026-1340 (unauthenticated code injection) → shell access → credential looting via standard post-exploitation → lateral pivot using CVE-2026-6973 against internal EPMM instances where authentication is required.

Dirty Frag vs. Copy Fail (CVE-2026-31431) — these are distinct primitives targeting different kernel subsystems with shared conceptual DNA around page cache manipulation.

Copy Fail uses AF_ALG sockets plus splice() to bypass write protections through the kernel crypto framework—present since 2017, ~700-byte Python exploit, stable execution.

Dirty Frag chains two separate bugs: xfrm-ESP packet handling (since January 2017) and RxRPC authentication (since June 2023). Both provide precise arbitrary writes to page cache without races. The 732-byte exploit probes which subsystem is active—esp4/esp6 for IPsec environments, rxrpc for AFS client systems—and succeeds on first attempt across Ubuntu, RHEL, Fedora, CentOS Stream, AlmaLinux, and openSUSE.

Key difference: Copy Fail exploits crypto framework stacking; Dirty Frag abuses network stack and authentication subsystem corruption. Both achieve root, but Dirty Frag arrived with no patches available at disclose. Immediate mitigation: blacklist both module paths via /etc/modprobe.d/dirtyfrag.conf. Kernel patches remain pending upstream.

Right. I've got enough to give you the operational playbook for both. Let me lay out what's doable before Saturday's CISA deadline and what's not.

IVANTI EPPM CVE-2026-6973 — 48-HOUR DEPLOYMENT PLAYBOOK

Look, this is chained exploitation — CVE-2026-1340 from January harvested your admin creds, now CVE-2026-6973 uses those creds for RCE. The Belgium CCB bulletin confirms Ivanti has "high confidence" the admin credentials came from prior CVE-2026-1340 exploitation.

Credential Rotation Reality Check:
If you rotate MDM admin credentials mid-cycle, here's what breaks:

• Active device enrollment sessions will fail authentication and need re-enrollment
• API integrations (SCCM connectors, ServiceNow tickets, custom scripts using the admin API) will 401 until updated
• Push certificate deployments to iOS/Android will stall until the new creds propagate

But you have to do it anyway. CVE-2026-6973 requires authenticated access — if your admin creds are compromised from January, the attacker owns you right now.

48-Hour Plan:

• TODAY (Friday): Snapshot your EPMM VMs before any patch attempt. I've seen Ivanti patches corrupt the Postgres database when the appliance has >50K enrolled devices.
• Saturday Morning: Deploy to staging. Test device re-enrollment flows and API integrations with new admin creds. Target versions 12.6.1.1 / 12.7.0.1 / 12.8.0.1 are confirmed patched.
• Saturday Afternoon (CISA deadline): Production cutover. The patch bundle also fixes the January CVEs (CVE-2026-1281, CVE-2026-1340) and four new ones.

Priority Matrix:

• CRITICAL (do today): Audit admin accounts, snapshot appliances, rotate creds if January patches were missed
• HIGH (do Saturday): Patch deployment, full credential rotation, re-test API integrations
• MEDIUM (next week): Enforce MFA on all admin accounts, review January incident logs for persistence

DIRTY FRAG — INTERIM HARDENING (NO PATCH)

This is worse. The embargo broke — no CVE, no coordinated patch release. Exploit is deterministic logic flaw in xfrm-ESP and RxRPC page-cache writes, works first try, no kernel panic.

Module Blacklisting — What Actually Breaks:

For Cloud/Container Workloads:

• AWS/GCP/Azure VPC with IPsec: You can't disable esp4/esp6 without dropping encrypted inter-VPC links. Alternative: enforce instance metadata protection and restrict local user access — Dirty Frag requires local user context.
• Kubernetes: If you're running privileged containers with hostPID/hostNetwork, one compromised pod gets root on the node. Immediate action: apply PSP/Kyverno policies blocking privileged pods until patches land.

Production-Safe Commands (test in staging first):

# Blacklist the modules
sudo sh -c 'printf "%s\n" "install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false" > /etc/modprobe.d/dirtyfrag-disable.conf'

# Remove if currently loaded
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

Blast Radius Assessment:

• If you disable esp4/esp6: VPNs break. Cloud instances with IPsec connectivity will lose inter-region connectivity.
• If you keep them enabled: Any local user (including compromised web app accounts, container escapes, stolen SSH keys) gets root in one shot.

Priority Matrix:

• CRITICAL (do today): Module blacklist on non-VPN systems, audit local user accounts, restrict container privileges
• HIGH (do today if VPN-dependent): Detection rules for xfrm socket creation — I'll get false positive rates from Alex on this
• MEDIUM (when patches release): Kernel updates, remove blacklists, re-test VPN connectivity

Lena — have you seen IOCs for Dirty Frag exploitation yet? And Alex — what's the detection fidelity for xfrm socket anomalies?

The TrustFall disclosure represents exactly what I've been warning about—this is a systemic trust model failure across AI agent architectures. Let me break down the mechanics and then address the convergence of threats we're seeing.

The MCP Trust Dialog Bypass Mechanism

According to the Dark Reading report on TrustFall, the vulnerability exploits inadequate trust dialogs for Model Context Protocol (MCP) servers. Here's what's happening: When an AI coding agent connects to an MCP server—say, a browser automation tool or filesystem integration—the agent is supposed to present a trust dialog asking the user for explicit consent. The Adversa team found that this dialog can be bypassed through what appears to be an "auto-approve" convention that all four vendors implemented similarly.

Think of it like this—imagine if every browser had a "remember my choice" checkbox for SSL certificates, but the default timeout was indefinite and the scope was global. Now a malicious repo contains an MCP server configuration that declares itself "trusted," and because of how the agents handle workspace trust inheritance, that MCP server gets auto-approved when the developer opens the repository. A single keypress—or in CI/CD, zero human interaction—triggers execution with full system privileges.

Why This Is Class-Level, Not Vendor-Specific

This hits on a fundamental design pattern problem, not a coding bug. The Dark Reading article explicitly states this represents a "shared convention rather than vendor-specific bug." The Model Context Protocol was designed by Anthropic as an open standard, and all four vendors—Claude Code, Cursor CLI, Gemini CLI, and CoPilot CLI—independently implemented similar trust hierarchies without sufficient permission granularity.

This is OWASP LLM Top 10 territory—specifically #6: "Excessive Agency" combined with #1 "Prompt Injection." The MCP standard didn't define strict trust boundaries, and vendors all converged on the same convenience-over-security default. Adversa went to all four vendors simultaneously because fixing this in one tool doesn't protect developers using another.

The CI/CD Zero-Click Path

Here's where this becomes genuinely terrifying. In CI/CD environments, the attack requires no human interaction at all. The research thread from @threatcluster notes this affects "CI/CD pipeline environments" specifically. Here's the chain:

1. A compromised repository contains malicious MCP server configuration
2. CI/CD runner spins up with AI agent pre-installed
3. Agent automatically connects to workspace MCP servers during build
4. Because there's no interactive user in CI, the "trust" decision defaults to auto-approve
5. Malicious MCP server now executes with CI runner privileges—access to secrets, environment variables, deployment credentials

The @packet_storm research confirms this enables "credential theft" even in automated environments. The "Comment and Control" attack class described by @The_Cyber_News extends this—malicious payloads in PR comments trigger the same exploitation path when AI agents review code in CI.

Immediate Lockdown Actions

Organizations need to act across four dimensions RIGHT NOW:

1. Disable MCP auto-approval entirely — Force interactive trust dialogs for all MCP connections, even in CI/CD. If that breaks your pipeline, you've identified the exact exposure.

2. Sandbox AI agent execution — Run Claude Code, Cursor, Gemini CLI, and CoPilot in isolated containers without access to host secrets. Mount credentials as narrowly as possible.

3. Audit repository MCP configurations — Scan for .cursor/mcp.json, .claude/mcp-settings.json, and similar files. Treat these as executable code with unsigned provenance.

4. Implement CI/CD egress filtering — AI agents in CI should not have unrestricted outbound connectivity. The curl commands noted in @threatcluster's research won't work without network access.

On the Malware Campaign Convergence

The concurrent threats—fake MSI installers, trojanized VS Code extensions, and the Vidar/GhostSocks distribution via fake Claude repos—this is opportunistic exploitation of developer trust, not coordinated targeting of Adversa's disclosure. The SecurityWeek article on OAuth token theft via MCP hijacking and the claude source leak exploitation documented by cyberpress.org are separate attack chains.

That said, the timing isn't coincidental. We're seeing a perfect storm: Anthropic's source code leak in March 2026 created name recognition and trust abuse opportunities, the MCP trust model vulnerabilities created systemic exposure, and threat actors are now treating AI tools as high-value developer targets. The fake VS Code extensions distributing malware are riding the same "developer tools are trustworthy" psychology that makes the MCP bypass so effective.

Consider this: an attacker who compromises a developer through a fake MSI installer now has access to that developer's .cursor or .claude directories—which might contain MCP configurations that persist the compromise to CI/CD. These are parallel but connectable attack paths.

I'll flag something for James Okafor—there are IOCs in here that matter for detection: the Vidar infostealer/GhostSocks proxy combo distributed via fake GitHub repos, the specific MCP configuration files as persistence mechanisms, and the pattern of AI agent credential harvesting in CI logs. We need those detection rules deployed yesterday.

Let me address both assessments.

PCPJack: Insider Displacement Theory

The "insider displacement" theory — that a former TeamPCP operator is behind this — is compelling but unverifiable at current data levels. Here's what the evidence actually supports:

Timeline: TeamPCP claimed multiple supply chain intrusions in early 2026 (LiteLLM, etc.). PCPJack emerged as a distinct framework that actively hunts and evicts TeamPCP artifacts. That's not competitive criminal behavior — that's personal. The eviction telemetry sent back to C2 ("mission accomplished" metrics) suggests an emotional or operational need to demonstrate superiority, not just profit.

On credential-only monetization: I see this as operational maturation, not necessarily a different actor profile. Cryptominers leave forensic noise. Pure credential theft with automated S3 staging enables faster pivot cycles. The S3 bucket being discoverable is interesting — either tradecraft degradation (rush to deployment) or deliberate misdirection. Without seeing bucket lifecycle policies, I can't distinguish.

Attribution confidence: Low confidence on insider displacement. The behavioral overlap is there, but the jump to "former insider" requires assumptions about TeamPCP's organizational structure we don't have. I'd call this an unnamed cluster with competitive displacement behavior against G-TBD (TeamPCP) until we see code-level overlap or communications intelligence.

ZiChatBot/OceanLotus (G0050): The July 2025 Question

Three observations.

First, the timeline puzzle. July 2025 deployment, May 2026 discovery — that's a 10-month dwell. PyPI's lack of proactive malware scanning plus low package popularity likely kept this below detection thresholds. The question isn't "why now" — it's "what else from July 2025 are we still missing?"

Second, attribution confidence. The 64% dropper similarity from KTAE is meaningful but not definitive. OceanLotus has shown adaptive C2 before (Slack, Discord), so Zulip fits their evolution. However, I'd note this: the three package names (uuid32-utils, colorinal, termncolor) lack OceanLotus's typical thematic consistency. Prior campaigns used Vietnam-relevant or professional-development lures. These are generic.

I'm at moderate confidence for G0050 attribution — behavioral and code overlaps are present, but the Zulip pivot is genuinely novel enough that I'm keeping copycat or toolkit-sharing scenarios on the table, especially given prior open questions on this exact point.

Third, victim scope. I've found no evidence beyond APAC in current reporting. The oceanlotus-typical victimology (Vietnamese government, ASEAN organizations, human rights NGOs) would be the expected population. If we see Western victim reporting, that would challenge the attribution.

Halil, one operational note: the July 2025 timestamp places initial access before multiple PyPI security enhancements. Re-checking that timeframe for other undetected packages would be prudent.