CyberSip™ — Issue 74 — June 29, 2026

Weekend picture

Wiz Research disclosed on June 26 that Amazon Q Developer, the AI coding assistant for VS Code, JetBrains, Eclipse, and Visual Studio, silently executed MCP server configurations from any cloned repository without prompting for consent, handing AWS session credentials, API keys, and SSH agent sockets to any attacker who could deliver a malicious .amazonq/mcp.json file. Amazon patched it in May; the parallel issue in Claude Code, Cursor, and Windsurf confirmed that MCP auto-execution without workspace trust verification is a wider industry problem. KDDI Corporation disclosed on June 28 that a third-party software vulnerability in its managed email system gave attackers access to credentials for up to 14.22 million accounts across six Japanese ISPs including JCOM, Nifty, and BIGLOBE. The FBI and CISA updated their advisory on Russian intelligence Signal phishing campaigns on June 26, confirming that operators have added a step: they now coax targets into handing over their Signal Backup Recovery Key, which grants permanent access to message history and survives phone number changes.

Threat snapshot

3 items this issue

Amazon Q / MCP auto-exec / AWS credential theft / patched KDDI / 14.2 million email credentials / six ISPs Signal / Russian backup key theft / permanent takeover 3 items this issue

June 26Amazon QMCPPatched

Amazon Q Developer silently launched MCP servers from untrusted repository config files, inheriting the developer’s full environment including AWS credentials. Opening a malicious repo was the only action required. No exploitation confirmed in the wild. Patch in Language Servers for AWS 1.69.0.

The same root cause, MCP auto-execution without workspace trust verification, was disclosed simultaneously in Claude Code, Cursor, and Windsurf. Wiz argues this is not an Amazon problem specifically but a pattern the whole industry needs to address. DPRK-linked actors already use fake job interview coding tests that ask candidates to clone and open repositories, which is the exact delivery mechanism this flaw enables. The language server auto-updates on IDE reload for most users.

June 28KDDI14.2 Million Accounts

KDDI Corporation breach exposes up to 14.22 million email credentials across six Japanese ISPs via a third-party software vulnerability. Detected June 17, disclosed June 28. Passwords were hashed but may have been captured. All affected users should rotate email passwords immediately.

KDDI provides a shared email platform to STNet, JCOM, Chubu Telecommunications, Nifty, BIGLOBE, and KDDI Web Communications. One vulnerability in that shared infrastructure cascaded across all six. Former and inactive accounts are included in the 14.22 million figure. Investigation is ongoing and scope may change.

June 26Russian IntelligenceSignal

FBI and CISA update their Signal warning: Russian operators now steal Backup Recovery Keys, not just link devices. The key grants permanent access to message history and works even if the victim changes their phone number or reinstalls Signal.

The fix is simple: generate a new Backup Recovery Key in Signal Settings, which invalidates the old one for future downloads. Anything already pulled before the key is rotated is gone. The advisory specifically targets government officials, politicians, journalists, and activists with access to sensitive communications.

Detailed intelligence

Full analysis

01 Amazon Q MCP Auto-Execution Patched

Amazon Q Developer executed MCP server configs from untrusted repositories without consent, exposing AWS credentials and cloud access to any attacker who could get a developer to open a repo. Patched. The same pattern found across Claude Code, Cursor, and Windsurf.

CVE-2026-12957 · CVE-2026-12958 · CVSS 8.5

Wiz Research discovered and disclosed the vulnerability. The Amazon Q Developer extension for VS Code, JetBrains, Eclipse, and Visual Studio read a hidden .amazonq/mcp.json configuration file from any workspace directory opened in the IDE and launched the MCP servers defined in it, without any confirmation dialog, workspace trust check, or user consent. Spawned processes inherited the developer’s complete environment.

Executive Impact

For most users, the language server that powers Amazon Q auto-updates, and reloading the IDE triggers the patch. Verify the running version of Language Servers for AWS is 1.69.0 or later. No further action is needed for users on patched versions. The broader policy implication is for teams using AI coding assistants more generally: any AI IDE extension that can execute commands from workspace configuration files should require explicit user approval before running commands from any repository that is not already trusted.

Don’t Miss

Wiz specifically names the DPRK delivery vector. North Korean threat actors, including Sapphire Sleet covered in Issue 70 and Lazarus Group, have an established pattern of posing as recruiters and sending fake coding assessments that require candidates to clone and open a repository on their local machine. That technique was already documented as a credential theft vector before the Amazon Q flaw was discovered. The combination of a social engineering delivery that begins with cloning a repository and an IDE extension that executes configuration files from any cloned repository is precisely the attack chain DPRK actors had already built for other reasons. Whether or not any recorded exploitation of CVE-2026-12957 has been confirmed, the delivery mechanism was already in use for related attacks, and the tooling for it was already built and deployed.

CyberSip Take

This is the fourth time this brief has covered an MCP or workspace trust boundary issue in AI coding tools since May: Agentjacking via Sentry in Issue 63, AutoJack via AutoGen Studio in Issue 67, the Mastra npm supply chain attack in Issue 66, and now Amazon Q. Each one works by placing something in the environment the AI tool reads from and trusting that the tool will act on it. The fix in every case is the same: AI coding tools need to ask before they run. The Amazon Q patch does that. Whether the equivalent fix exists in every other tool in your environment is worth checking.

What happened

Wiz researcher Maor Dokhanian discovered the vulnerability on April 17, 2026, and reported it to Amazon on April 20. Amazon deployed an initial fix on May 12 in Language Servers for AWS version 1.65.0. CVE numbers were assigned on June 23 and public disclosure followed on June 26 under Amazon Security Bulletin 2026-047-AWS.

The root cause was straightforward. Amazon Q Developer reads a file at .amazonq/mcp.json inside any open workspace and automatically launches the MCP server processes it describes, because the design of MCP assumes a user has consciously configured those servers. When the configuration file is present in a cloned repository rather than placed there by the developer themselves, that assumption fails. The spawned processes run on the developer’s machine with the developer’s full environment, which in practice includes AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, cloud CLI tokens, API keys, and SSH agent sockets.

Wiz’s proof-of-concept used a single bash command in the malicious config to run aws sts get-caller-identity and send the captured AWS session to an attacker-controlled server. From there, an attacker could backdoor IAM users, establish cloud persistence, or pivot to internal production systems through an inherited VPN context. The flaw affected the Amazon Q extension for VS Code, JetBrains, Eclipse, and Visual Studio, all of which bundle the same Language Servers for AWS runtime. A second CVE, CVE-2026-12958, covered a missing symlink validation flaw that allowed path traversal outside workspace boundaries. Amazon has fully patched both in version 1.69.0 of the language server. Wiz confirmed that similar MCP auto-execution flaws were disclosed at the same time in Claude Code, Cursor, and Windsurf.

Recommended actions

Reload your IDE. The language server updates automatically for most users. Confirm the running version of Language Servers for AWS is 1.69.0 or later via the Extensions panel.
Until you have verified the patch is applied, avoid opening unfamiliar repositories with Amazon Q active. This applies to repositories received as part of coding assessments, job interviews, or unsolicited outreach.
For teams managing developer workstations: audit whether any AI coding assistant extensions in use apply workspace trust checks before executing configuration files from cloned repositories. The same class of flaw was confirmed across multiple tools simultaneously.

Derived from The Hacker News, The Register, and Wiz Research blog on CVE-2026-12957, June 26, 2026.

02 KDDI 14.2 Million Accounts

KDDI Corporation breach exposes up to 14.22 million email credentials across six Japanese ISPs. A third-party software vulnerability in the shared email platform was the entry point. Detected June 17, disclosed June 28.

KDDI · June 17 detected · June 28 disclosed

KDDI Corporation, one of Japan’s largest telecommunications operators, publicly disclosed on June 28 that attackers exploited a vulnerability in third-party software running on its managed email system. The system is shared with five other Japanese internet service providers. Up to 14.22 million sets of email addresses and passwords may have been exposed. The investigation is ongoing.

Executive Impact

Anyone using email services from STNet, JCOM, Chubu Telecommunications, Nifty, BIGLOBE, or KDDI Web Communications should change their email account password immediately and enable two-factor authentication if their provider offers it. The 14.22 million figure includes former and inactive accounts, so the impact extends beyond current customers. Because email credentials are routinely used for password reset flows across other services, the downstream risk from credential reuse is significant even if the original email account is not the primary concern.

Don’t Miss

KDDI did not disclose what specific software was vulnerable, how long the attacker had access before detection, or what proportion of passwords were stored in plaintext versus hashed. It confirmed only that passwords were stored in hashed or encrypted form, without specifying the hashing algorithm, salting, or iteration count. Weak hashing, particularly MD5 or unsalted SHA-1, can be reversed for common passwords in hours using publicly available tools. The practical advice for affected users is to change the email password regardless of any assurances about hashing, and to check whether the same password was used elsewhere. The six-provider cascade from a single shared platform is structurally significant: one vulnerability in shared infrastructure became a breach across six separate customer-facing brands, none of which were directly responsible for the flaw.

CyberSip Take

Third-party software vulnerability in a shared platform, 14 million credentials across six brands, investigation still ongoing. This is the Klue pattern from Issue 67 at telecommunications scale. One weak point in shared infrastructure cascades to every organization and customer that depends on it. The question for any organization using managed or shared infrastructure is not only whether their own systems are patched, but whether the providers running those systems have the same security standards they would apply themselves.

What happened

KDDI Corporation detected unauthorized access to its managed email platform on June 17, 2026, and blocked the attacker and implemented defensive measures the same day. The company identified the entry point as a vulnerability in third-party software integrated into the email system, which serves as the backend for email services operated under six ISP brands.

The affected services span a broad range of Japanese internet customers. The platform powers email for Pikara Hikari and related services under STNet, CPI rental server email under KDDI Web Communications, J:COM NET email, Commufa Hikari and Business Commufa email under Chubu Telecommunications, @nifty Mail, and BIGLOBE Mail. The 14.22 million figure represents the maximum potential exposure across all current, former, and inactive accounts stored in the system.

KDDI publicly disclosed the breach on June 28, following internal investigation and notification to Japan’s Personal Information Protection Commission and the Ministry of Internal Affairs and Communications. The company said passwords were stored in hashed or encrypted form but that there remains a possibility they were obtained by the attackers. Investigation is ongoing and KDDI said it will continue to coordinate with affected ISPs on customer notification and remediation.

Recommended actions

If you or any employee uses email services from STNet, JCOM, Chubu Telecommunications, Nifty, BIGLOBE, or KDDI Web Communications, change that email account password immediately and enable two-factor authentication where available.
Check whether the same email address and password combination is used on any other service. Credential reuse across services is the primary downstream risk from this breach. Use a password manager and unique passwords per service.
Be alert to phishing email campaigns targeting KDDI and affiliated ISP customers in the coming weeks. Breach disclosures consistently precede waves of phishing that impersonate the breached company using the stolen email addresses. Verify any official-looking communication by navigating to the ISP’s website directly rather than clicking links in email.

Derived from BleepingComputer and Security Affairs reporting on KDDI breach, June 28, 2026.

03 Russian Intelligence Signal

FBI and CISA update their Signal warning: Russian operators now steal Backup Recovery Keys to permanently access message history. The key survives phone number changes. Rotate it now in Signal Settings.

FBI · CISA · Signal · June 26

The FBI and CISA updated their March 2026 joint advisory on Russian intelligence targeting Signal on June 26. The updated guidance confirms that operators linked to Russian military intelligence have added a step to their phishing campaigns: after gaining initial access, they now specifically target the Signal Backup Recovery Key, which grants the ability to download the victim’s full message backup including private and group message history.

Executive Impact

Any government official, politician, journalist, activist, or person handling sensitive communications on Signal should generate a new Backup Recovery Key immediately. The setting is in Signal under Settings, then Account, then Signal Backups. Generating a new key invalidates the old one for future backup downloads. It does not retract any data already downloaded before the key rotation. This is a one-time action that takes under a minute and permanently closes the key theft vector for past key exposure.

Don’t Miss

The advisory notes a specific property of the Backup Recovery Key that makes this attack more persistent than a standard credential theft. Unlike a compromised password that stops working once reset, a stolen Signal Backup Recovery Key keeps working even if the victim changes their phone number or installs Signal on a new device. The attacker holds a key that is tied to the backup, not to the current account state. Restoring a new Signal account on the same phone number does not invalidate an old backup key. Generating a fresh key in Signal Settings is the only action that closes that window. If the key was stolen and has not been rotated, an adversary who held it could have been quietly downloading updated backups at any point since the theft.

CyberSip Take

Signal backup key theft is operationally elegant for Russian intelligence. The attacker gets a persistent, silent read capability against a target’s private communications without needing to maintain ongoing access to their device. Rotate the key if there is any possibility it was exposed, treat the action as routine hygiene for anyone in a sensitive role, and check that it has been done on the devices of any staff member whose communications are potentially of interest to a foreign intelligence service.

What the updated advisory says

The FBI and CISA first warned in March 2026 that Russian military intelligence operators were running phishing campaigns against Signal users in government, politics, journalism, and civil society. The March advisory documented the primary technique: sending fake group invite links or device linking QR codes that, when scanned or clicked, added an attacker-controlled device to the victim’s Signal account, giving real-time access to ongoing conversations.

The June 26 update confirms that operators have refined the approach. After establishing initial access through the device-linking technique or through account compromise, they now specifically attempt to recover the victim’s Signal Backup Recovery Key. This key allows Signal to download an encrypted backup of the account’s message history. Unlike linked device access, which a victim can detect and remove by reviewing linked devices in Signal Settings, the backup key provides a persistent, passive capability that is not visible in the Signal interface once obtained.

The advisory notes that the key continues to work even after the victim changes their phone number or sets up Signal on a new device, because it is tied to the encrypted backup rather than to the live account. Generating a new key in Signal’s backup settings invalidates the old one for future downloads, which is the recommended immediate remediation. Data already downloaded before key rotation cannot be recovered.

Recommended actions

Generate a new Signal Backup Recovery Key now. Open Signal, go to Settings, then Account, then Signal Backups. This invalidates any previously issued key for future backup downloads.
Review linked devices in Signal Settings and remove any that are not recognized. This addresses the original March advisory vector alongside the key theft technique.
For organizations with staff in sensitive roles: include Signal backup key rotation in onboarding security briefings and periodic security reviews alongside password and authentication credential hygiene.

Derived from The Hacker News reporting on the FBI and CISA updated Signal advisory, June 26, 2026.

Still watching

Aging items · days 2–5

Items here remain operationally relevant but have no significant new developments. They drop off after 7 days.

DirtyClone CVE-2026-43503 (Issue 73). Working public PoC. Fourth DirtyFrag-family Linux kernel root escalation. Patch in mainline since May 21. Update kernel and verify all five DirtyFrag-family CVEs are addressed. Restrict unprivileged namespaces as interim mitigation. Day 3

PTC Windchill CVE-2026-12569 CVSS 9.3 (Issue 73). Actively exploited with JSP webshells. First PTC KEV. Patch available. Check HTTP logs for POSTs to /Windchill/login/*.jsp and scan for 16-hex-char .jsp files. Day 3

Cross-source standouts

MCP auto-execution is now confirmed as a systemic risk across the AI coding tool ecosystem

The Amazon Q flaw was disclosed on the same day that similar vulnerabilities were confirmed in Claude Code, Cursor, and Windsurf. All four tools, from different vendors with different codebases, made the same design choice: read MCP configuration files from workspace directories and launch the servers they define without first checking whether the workspace came from a trusted source. Wiz frames this explicitly as an industry problem rather than an Amazon-specific one. The MCP protocol defines what servers can do, not whether an application should trust a server from an unfamiliar directory. That trust decision was left to each application, and four major tools got it wrong in the same way. This brief has now documented five distinct incidents where MCP or AI tool integrations were used as attack vectors since May: Agentjacking, AutoJack, the Mastra npm supply chain, the Sentry MCP poisoning technique, and now Amazon Q. The pattern is consistent enough that MCP trust boundaries should be treated as a first-class security control in any development environment using AI coding tools.

The KDDI and Klue breaches this month both trace to third-party software in shared infrastructure

KDDI: a third-party software vulnerability in a shared email platform exposed credentials across six ISPs. Klue: a compromised prototype credential in shared integration infrastructure gave attackers OAuth tokens across dozens of enterprises. In both cases the organization whose name appeared in the disclosure was not the organization that introduced the vulnerability. The affected ISPs did not write the email platform code. The Klue customers did not configure the legacy credential. The attack surface in both cases was created by a dependency on shared infrastructure that was not under the affected organization’s direct security control. As supply chains and SaaS dependencies become the norm for infrastructure, the relevant security question is no longer just what software the organization runs but what software the providers it depends on are running, and whether the security standards those providers apply match what the organization would require of itself.