14 Million Email Logins Exposed at Japanese ISPs

KDDI Corporation, one of Japan's largest telecoms operators, has confirmed a breach of its email systems affecting up to 14.22 million accounts across five partner ISPs, according to Bleeping Computer.

The attackers got in by exploiting a vulnerability in unnamed third-party software running on KDDI's email platform. Once inside, they had potential access to email addresses and passwords belonging to customers of STNet, JCOM, Chubu Telecommunications, NIFTY Corporation, and BIGLOBE — past and present. Inactive accounts were also caught in the net.

KDDI discovered the intrusion on June 17 and moved quickly to block the attacker and notify Japan's Personal Information Protection Commission and the Ministry of Internal Affairs and Communications. The investigation is still ongoing.

There is some partial good news: a portion of passwords were stored in hashed or encrypted form, which adds a layer of protection even if the data was lifted. The problem is KDDI has not confirmed what percentage were stored that way, nor the strength of the encryption used. Some may have been stored in plaintext. That is the kind of vagueness that should worry you.

What the attacker wanted is not difficult to guess. Fresh email credentials are valuable for account takeovers, spam campaigns, and credential stuffing (where stolen username and password pairs are tried automatically across other services — think banking, shopping, anything you reuse that password on).

What you should do: If you are a customer of STNet, JCOM, Chubu Telecommunications, NIFTY, or BIGLOBE, reset your email password now. Then check every account where you used that same password and change those too. Enable two-factor authentication (2FA) on your email if it is available — it means a stolen password alone is no longer enough to break in.

Mozilla's security research team, 0DIN (Zero Day Investigative Network), has published a warning about a new attack technique targeting AI-powered coding tools, according to Help Net Security.

The attack uses indirect prompt injection (manipulating an AI agent by hiding instructions inside content it reads — like a README file — rather than telling it directly). The trap works like this: a repository's setup instructions look normal, a Python package deliberately fails on first run, and the suggested recovery command fetches a shell script from a DNS record controlled by the attacker. That script runs with the developer's own system privileges.

The malicious payload never sits in the repository itself. It arrives at runtime, invisible to code review and static analysis.

If an AI coding agent like Claude Code follows the steps as written — which it will — it opens a connection back to the attacker's server, handing over access to API keys, credentials, and environment variables stored on that machine.

What you should do: Treat setup scripts in unfamiliar repositories as untrusted code, regardless of what your AI tool recommends. Review what a command will actually execute before running it.

What libssh2 is: A C library that gives software the ability to connect to SSH servers — it is embedded inside widely-used tools including curl, Git, and PHP, meaning it quietly runs inside many applications you use every day without advertising its presence.

What it is: A critical memory corruption flaw in the function that reads incoming SSH packets during a connection handshake. A malicious or compromised SSH server can trigger it with no credentials and no interaction from the user. The result is potential remote code execution (RCE — an attacker running their own commands on your machine) on the connecting client. A public proof-of-concept has been published, per The Hacker News.

Who's at risk: Any software that links libssh2 and connects to an SSH server — especially tools reaching external or untrusted servers. Many copies are bundled directly inside applications (statically linked — meaning the library is baked permanently into the application's own code), so updating your operating system's package manager may not touch them.

CVSS: 9.2 (Critical — patch today.)

Root cause: The packet-parsing code read an attacker-controlled length value from the incoming SSH packet but only rejected values below 1. No upper limit was enforced. When a very large length value is supplied, arithmetic to calculate the required buffer size wraps around to a tiny number (this is an integer overflow — when a number exceeds the maximum a fixed-size counter can hold and loops back to near zero). libssh2 then allocates a small buffer but later writes the full oversized packet into it, writing past the end of that buffer in memory — a heap out-of-bounds write (writing data beyond the boundary of an allocated memory block). The fix adds a single check rejecting any length above the permitted maximum before the arithmetic runs.

Attack vector: An attacker who controls or compromises an SSH server waits for a vulnerable client to connect. During the handshake, the server sends a crafted packet with an oversized length field. libssh2 miscalculates the buffer size, allocates too little memory, and then overwrites adjacent memory. Depending on the application and how libssh2 is embedded, this can lead to code running under that application's privileges. No user interaction is required beyond initiating the connection.

Detection strategies:

1. Unexplained crashes or memory errors in applications that make SSH connections (curl jobs, Git operations, backup agents)
2. Anomalous outbound connections following an SSH handshake to an external server
3. SSH client processes spawning unexpected child processes or making unusual network connections

Recommended actions:

1. Inventory every application and appliance that uses libssh2, including statically bundled copies — curl, Git, and PHP deployments are the most common carriers
2. Apply the patch by using distro backports where available (Debian already has a repaired build in testing) or build from source including commit 97acf3d
3. Until patched, restrict outbound SSH connections to trusted, verified servers and confirm host keys are checked before connecting

Mozilla's 0DIN team demonstrated today that malicious code does not need to live in a repository to compromise your machine. The attack exploits the trust developers place in AI coding tools — the agent reads setup instructions and follows them faithfully, with no way to see what will be fetched at runtime.

The practical defence is to review any initialisation or setup command before running it, regardless of whether an AI tool recommends it. Before executing a shell script from an unfamiliar source, check where it fetches content from. If a command pipes anything directly to bash or sh — particularly one that resolves an external address — treat it as suspicious.

0DIN's full write-up, including the proof-of-concept chain, is available via Help Net Security. If you work with developers or manage engineering teams, sharing this finding today is worthwhile.

The National Association of Insurance Commissioners (NAIC), the US body that coordinates insurance regulation across states, has confirmed a breach via a zero-day vulnerability (a flaw unknown to the developer at the time of exploitation) in Oracle PeopleSoft, the software it uses for internal financial reporting, according to Infosecurity Magazine. The breach was first detected on June 11 and publicly disclosed on June 17. Credit rating agency data was accessed and published by the attacker. Personal information of policyholders and payment data were not compromised. The NAIC says FBI coordination is underway and operations have largely returned to normal.