The most useful thing an attacker can steal is often not a password. It is the list of people who have one. Japan's Digital Agency disclosed on September 11 that unauthorized access to the Government Solution Service—a platform shared across ministries and agencies—may have exposed roughly 246,000 rows of personal information belonging to government staff and contractors. No My Number identifiers, bank details or pension numbers were involved.
It would be easy to file that as a low-severity incident. It is not, and the reason is specific: what was exposed is a high-confidence directory of who works where, on what system, reachable at which address and phone number. That is the raw material for a convincing request for something that actually is a secret.
What is confirmed
The agency states that it detected large-scale file access from a system-maintenance administrator account on June 25, 2026, and confirmed on July 9 that a third party had been accessing the system since around late May. It suspended the account, isolated the affected device and notified the Personal Information Protection Commission on July 15. The agency says initial access came through a vulnerability in a VPN device used by the Government Solution Service.
The announcement puts the affected population at roughly 189,000 public employees and about 57,000 contractors and individuals working with partner agencies. BleepingComputer reports the 246,000 rows breaking down as approximately 236,000 names, 231,000 email addresses, 94,000 telephone numbers and 1,000 postal addresses. The agency says general members of the public are not affected, and that no secondary damage from misuse of the information has been confirmed so far. It has begun individual notifications and opened a dedicated support line.
On the vulnerability itself, the agency was unusually specific about what it was not: it says the flaw carried a medium severity rating and was not a zero-day. The VPN product and the specific vulnerability have not been named publicly.
What remains unknown
The public record does not establish which individual records were actually copied, what else on the shared platform the maintenance account could reach, who the actor was, or whether the data has since circulated. “No confirmed misuse” is a statement about detection, not a guarantee of safety—impersonation built on a leaked directory typically shows up weeks or months later, and it rarely announces which list it came from. The agency also cited the difficulty of determining the intrusion path as a reason the disclosure came roughly two months after confirmation.
Why a contact list is a secret-handling problem
A directory like this makes the two hardest parts of social engineering easy. It removes guesswork about identity—the attacker already knows the person's real name, real address and which agency they support—and it supplies a plausible pretext, because the incident itself is public and a “security verification” message is exactly what a recipient would half expect.
The pattern is consistent across incidents we have covered: a breach that contains no credentials produces a wave of requests for credentials. The messages arrive from a plausible sender, reference a real system, and ask the recipient to confirm access, approve a prompt, enroll a new device, or read back a code. Nothing in the original breach was secret. The follow-up is where the secret leaves.
If you receive a request tied to an incident
- Treat the incident itself as a pretext. Public disclosure of a breach is a known trigger for impersonation of that organization's support and security teams.
- Never authenticate through the message. Do not use its link, attachment or phone number. Open the system from a route you already know, or call a number you looked up independently.
- Refuse code read-back entirely. No legitimate support process requires you to speak or type a one-time code, recovery code or password to a person who contacted you.
- Verify the requester through a different channel than the request. If the request came by email, confirm by phone or in person—and use a contact route recorded before the incident, not one supplied in the message.
- Report it even when you did not fall for it. The first reported attempt is what tells a security team a campaign is running against their staff list.
If you run a shared platform
The structural lesson here is about accumulation. A service used across many organizations gradually becomes the one place holding a complete, current directory of all of them, usually without anyone deciding that it should. Three questions are worth asking of any platform in that position:
- Does the platform need the contact fields at all? Phone numbers and postal addresses often arrive with an account record and are never read again. Data you do not retain cannot appear in a disclosure.
- What can one maintenance account reach? This intrusion ran through an administrator account used for system maintenance. Scope those accounts to the systems they maintain, require separate approval for bulk file access, and alert on volume rather than only on failed logins.
- How long is the window between access and detection? Late May to June 25 is roughly a month of undetected access, and a further two weeks to confirm a third party. Assume anything handled through the platform in that window—including credentials and session material—needs replacing.
That last point is where incident response often doubles the damage. When you rotate credentials after an intrusion, the replacement must not travel through the channel that may still be compromised. Decide in advance which route carries recovery material, who is authorized to receive it, and how the recipient confirms they are who they claim—while the usual directory and the usual mail channel are both in question.
Where Secretus fits—and where it does not
Secretus can reduce plaintext exposure when an authorized team must deliver a small, temporary credential or approval code over a separately verified channel during exactly this kind of recovery, instead of leaving it in a mailbox or ticket that may later be exported. Team Split can require several holders to reconstruct a high-value text secret.
It does not verify who a recipient is, does not authenticate the person who opens a link, and cannot tell you whether a message asking for a code is genuine. Identity verification has to happen out of band, through a route you established before the incident. Secretus is the transport for the value once you have decided the request is legitimate—never the reason to believe that it is.