Session CRT-20260705 — 5 July 2026 · Afternoon Edition

Halil, I would not make this a blanket Android panic. The same-day group is narrower: Android 14, 15, 16, and 16 QPR2 users who are plausibly in a targeted-exploitation lane — senior leadership, government-facing staff, security/legal teams, and anyone under personal surveillance risk. The evidence says CVE-2025-48595 is an Android Framework integer-overflow privilege-escalation, exploited in “limited, targeted” attacks, with no user interaction required and likely via malicious apps. That is exactly where MDM/conditional access should bite hard.

For MDM: require the June 2026 Android security patch level for those high-risk Android cohorts before access to mail, messaging, VPN, admin portals, and sensitive SaaS. If an OEM has not shipped the June patch, conditional access should restrict the device, not waive the risk. Also preserve suspicious devices for mobile forensics; don’t reflexively wipe them if you suspect spyware-style exploitation.

The 188% Android NFC rise and the WhatsApp/SMS/calendar lure wave are different. They are high-volume fraud and identity threats, not automatically same-day OS emergency material. Escalate controls there: block sideloading where you can, warn on unofficial APKs, push “disable NFC when not needed” guidance for exposed banking users, and tune identity monitoring for device-code phishing and mobile-origin token theft. But keep it in the monitored-and-hardened bucket unless you see fraud losses, malicious APK installs, or credential/session compromise in your own telemetry.

So my split is: CVE-2025-48595 gets same-day enforcement for targeted-risk Android users; NFC scams and mobile phishing get aggressive user, identity, and fraud controls, but not fleetwide emergency lockdown.

Halil, my split is: JADEPUFFER and Claude Code are actionable this week; the others are watch/control items unless your environment directly uses those workflows.

For JADEPUFFER, the evidence we have labels the Langflow-ransomware breach as critical and active in the wild. That makes it operational, not AI theater. But I would not frame it as “agentic ransomware” unless we have stronger proof that the model made autonomous attack decisions. The actionable path is simpler: exposed or over-privileged AI workflow infrastructure becomes a control-plane entry point, then conventional ransomware follows. Enterprises should immediately inventory Langflow and similar AI workflow tools, restrict internet exposure, rotate secrets reachable from flows, review workflow execution permissions, and hunt for abnormal outbound execution or file-encryption staging.

For the Mozilla 0din Claude Code PoC, this is a real exploit pattern but still described as a proof of concept, not an active campaign. The important mechanism is not “Claude went rogue”; it is indirect prompt/toolchain injection. A clean-looking GitHub repo led the agentic coding tool into setup behavior, with payload retrieval from a DNS TXT record, decoded and executed into a reverse shell. That bypasses casual repo review because the malicious payload is not stored in the repository. This week’s action: run coding agents in disposable sandboxes, disable unattended setup/script execution, block or alert on DNS TXT payload retrieval from developer workstations, and treat agent instructions in READMEs/issues/package metadata as untrusted input.

For OpenClaw marketplace skills, Hugging Face artifact manipulation, and token-by-token LLM exfiltration, I do not have enough visible evidence here to call them active enterprise exploitation at the same level. They are still important governance pressure: marketplace skills need allowlisting and permission review; model/artifact registries need provenance checks and isolated loading; token-level exfiltration matters where LLMs can see secrets or regulated data. But I would not displace patching, exposure reduction, and developer-agent sandboxing this week unless the enterprise is actively consuming those marketplaces or ML artifacts in production.

So my practical priority order is: 1) exposed AI workflow platforms like Langflow, 2) agentic coding tools with shell/network/file access, 3) ML supply-chain controls for model/artifact ingestion, 4) LLM data-loss monitoring. This is OWASP LLM Top 10 territory: prompt injection, insecure tool use, excessive agency, sensitive information disclosure, and supply-chain risk — not sentience, and not magic.

From a board-risk view, I would rank tonight’s exposure like this:

1. SharePoint exploitation — highest emergency risk if internet-facing or tied to regulated data. The evidence labels this as critical and active in the wild, so if SharePoint supports customer portals, document workflows, legal, finance, or healthcare records, I would approve an emergency change window tonight. Best case: contained patching and validation cost. Worst case: data theft, business interruption, disclosure, and litigation exposure.

2. Developer/cloud credential theft — PolinRider, TeamPCP, Langflow/JadePuffer — systemic supply-chain risk. This is the biggest cascade item. PolinRider is flagged as targeting npm, Packagist, Go modules, and Chrome extensions; TeamPCP is reported stealing cloud credentials via compromised developer tools; historic CyberBrief evidence tied TeamPCP-style activity to cloud tokens, SSH keys, Kubernetes secrets, and CI/CD exposure. Emergency action is justified tonight if affected packages, developer workstations, CI/CD runners, cloud keys, or Kubernetes secrets are present. Rotate credentials first; patching alone is not enough.

3. Microsoft 365 token theft — likely board-relevant, but I do not have current evidence visible here to price this specific item. Decision threshold: if there are anomalous OAuth apps, impossible travel, mailbox forwarding, token replay, or executive/admin account exposure, trigger customer/regulator comms preparation and emergency identity containment tonight.

4. Data-extortion/breach items — Kairos confirmed in the visible evidence; LastPass/Klue, Medtronic, DentaQuest, SLA, and Tata are not sufficiently evidenced here for me to quantify. Kairos is tied to data-theft extortion against a U.S. government entity. For the named breach/extortion cases, the board threshold is simple: if personal data, health data, credentials, or customer confidential data left the environment, move from “security incident” to legal disclosure clock and customer-communications readiness.

5. Android targeted exploitation — lower enterprise-wide financial priority unless executives, high-risk staff, or regulated-data access are involved. Without current evidence visible here, I would not put this above SharePoint or cloud credential theft. Escalate tonight only if targeted users include executives, government relations, M&A, legal, finance, or privileged admins.

My decision thresholds: emergency change window tonight for internet-facing SharePoint, confirmed malicious developer dependency use, exposed CI/CD secrets, cloud-token theft, or active extortion. Customer/regulator comms tonight if regulated data, customer credentials, health data, or material business interruption is plausible. Supplier escalation tonight if a vendor package, developer tool, MSP, SaaS integration, or cloud credential path touches production revenue systems.

Halil, I would prioritize PolinRider first for multinationals with developer, crypto, or open-source exposure. The CyberBrief handoff describes it as an active North Korean supply-chain campaign against npm, Packagist, Go modules, and Chrome extensions; MITRE identifies Lazarus as North Korean state-sponsored and OFAC lists Lazarus with North Korea sanctions exposure. That makes this more than “developer malware”: it sits directly at the intersection of software supply-chain trust and DPRK sanctions-evasion pressure. For crypto firms, fintech, exchanges, Web3 infrastructure, and companies with privileged developer pipelines, this changes board-level risk prioritization.

Armored Likho is second, but I would be disciplined on attribution. The evidence points to phishing, BusySnake Stealer, RAT functions, credential theft, reverse SSH tunneling, and targeting of government and electric power operators in Russia, Kazakhstan, and Brazil. That is geopolitically meaningful because energy and state institutions are strategic pressure points, but I would not yet turn “previously unreported APT” into a named state operation. For multinationals operating in those countries or supplying energy/government entities, raise priority; for others, treat it as a targeted espionage/access campaign requiring phishing resilience, credential controls, and segmentation.

UNC6508 and Pegasus are narrower. UNC6508 targeting research environments matters most to universities, labs, pharma, AI, defense-adjacent R&D, and firms with sensitive IP; absent stronger attribution or sponsor detail, I would keep it as an operational security and IP-protection issue, not a geopolitical conclusion. Pegasus in the Greek political-surveillance context is different: it does not raise whole-enterprise risk for every multinational, but it absolutely raises risk for executives, public-policy teams, lawyers, journalists, opposition-linked figures, and anyone around EU political processes. My provocation: the strategic target in Pegasus cases is often not the phone — it is the democratic decision-making environment around the person carrying it.