CTI Daily Brief — 2026-06-29

KDDI third-party email platform breach exposes up to 14.22 million credentials across six Japanese ISPs

Japanese carrier KDDI disclosed that a threat actor exploited a vulnerability in third-party software integrated into its centralised ISP email-management platform, with unauthorised access detected on approximately 2026-06-17 (BleepingComputer, 2026-06-28). The breach potentially exposed email addresses and passwords for up to 14.22 million subscriber accounts across six ISPs running on the shared platform — STNet, JCOM, Chubu Telecommunications, Nifty, Biglobe and a further KDDI ISP; KDDI states some passwords were stored hashed or encrypted and that 14.22 million is a worst-case figure pending forensic completion (SecurityAffairs, 2026-06-28; Infosecurity Magazine, 2026-06-24). No CVE for the third-party software flaw and no threat actor have been named; KDDI notified Japan's Personal Information Protection Commission and advised affected users to change passwords and enable MFA.

Why it matters to us: The structural lesson, not the jurisdiction, is the signal — a single vulnerable dependency in a shared multi-tenant email-management plane produced a six-ISP blast radius, the same exposure model any European telco or managed-ISP operator carries when subscriber-mail administration is consolidated onto one vendor platform. The immediate downstream risk for Swiss/EU defenders is credential-stuffing: 14.22 million leaked email/password pairs will surface in combolists and feed phishing-as-initial-access. Hunt for anomalous authentication against external-facing services from Japanese-ISP email address spaces, and treat any reused-password exposure on those domains as a stuffing precursor. Inventory third-party vendor access to your own subscriber/identity-management platforms and enforce MFA on the administration plane itself.

Mozilla 0DIN: a "clean" GitHub repo coerces AI coding agents into a reverse shell via three-stage indirection

Mozilla's Zero Day Investigative Network (0DIN) detailed an indirect prompt-injection class against AI coding agents in which no malicious code is present in the repository itself (Mozilla 0DIN, 2026-06-25; reported BleepingComputer, 2026-06-27). The repository carries three cooperating components: (1) plausible setup instructions telling the user/agent to install a Python package; (2) the package, engineered to fail at runtime with an error message that instructs the runtime to run python3 -m axiom init; (3) the axiom init handler, which issues a DNS TXT lookup to an attacker-controlled domain and executes the returned record value as a shell command. The chain achieves three levels of indirection — error message → DNS resolution → shell execution — so the agent never "decides" to open a shell; it interprets each step as routine error recovery and autonomously runs the suggested remediation, side-stepping per-step user approval. No CVE is assigned: this is exploitation of agentic error-recovery autonomy plus out-of-band payload retrieval, not a single software bug. It is a distinct technique from the Amazon Q Developer MCP-config auto-load issue (CVE-2026-12957) covered on 2026-06-27 — that abused automatic config loading; this abuses error-recovery behaviour and DNS-TXT C2.

Why it matters to us: Any environment where AI coding agents (Claude Code, GitHub Copilot Workspace, Cursor) hold repository and shell access — developer workstations, CI/CD runners, increasingly common in public-sector DevOps — should treat agent-executed setup/init steps as an untrusted-input execution surface. The static-analysis-clean property means repo scanning will not catch it; the behavioural tells are network-dependent init steps and out-of-band command retrieval. Detection concepts (no IOCs): alert on DNS TXT-record queries originating from developer-tooling process trees (node, python, pip, npx) during repository setup; EDR parent-child chains where an agent process spawns an unexpected shell child; egress monitoring for DNS TXT lookups from developer workstations and build agents. Hardening: require human-in-the-loop approval for any external network call made by agent-executed init scripts, and treat an agent's DNS/network capability as a scope that needs explicit grant rather than a default. Mapped to T1566 (delivery via a malicious repo link), T1071.004 (DNS as C2 channel) and T1059.004 (Unix shell execution).

UPDATE: Gogs CVE-2026-52806 moves from "no observed exploitation" to active cryptojacking campaign

UPDATE (originally covered 2026-06-20): When this brief first covered the Gogs argument-injection RCE CVE-2026-52806 (branch name injects --exec into git rebase; fixed in 0.14.3 on 2026-06-07), exploitation status was not observed. Wiz Threat Research now reports the flaw under active in-the-wild exploitation: a cryptojacking campaign active 2026-06-13–23 chained Gogs and Argo Workflows vulnerabilities for initial access, compromised thousands of Linux hosts, and pivoted across more than 300 additional Kubernetes nodes (Wiz Threat Research, 2026-06-28). The new development is the exploitation, not the bug — the CVE mechanics and patch were covered on 2026-06-20.

Per Wiz, once on a node the operators stole Kubernetes service-account tokens and used them to schedule workloads cluster-wide, then escaped to host via privileged containers to deploy cryptominers; Wiz designates the actor "Unknown" and names the C2 framework "Realm C2." The Gogs argument-injection vector is the same one documented by Rapid7 — an authenticated (effectively unauthenticated on default open-registration instances) RCE via a malicious pull-request branch name during a "rebase before merging" operation (Rapid7 Labs). ATT&CK chain as reported: T1190 (exploit public-facing Argo Workflows / Gogs) → T1078.004 (stolen K8s service-account tokens) → T1610 (deploy container) → T1611 (escape to host) → T1496 (resource hijacking).

Defender delta since 2026-06-20: the patch urgency is now exploitation-driven, not advisory-driven. If self-hosted Gogs is still below 0.14.3, prioritise the upgrade and disable open self-registration (DISABLE_REGISTRATION = true). Hunt K8s API-server audit logs for create on workflows.argoproj.io and on pods from unexpected service accounts, git rebase child processes spawned by the Gogs service user, and privileged-container/nsenter activity. Enforce Pod Security Admission (restricted) and audit RBAC to remove default service accounts with node-escalation rights. Scope/attribution figures (thousands of hosts, 300+ nodes, "Realm C2") are Wiz's single-source assessment — see § 7.