Key takeaways

  • Attackers broke into the Government Solution Service (GSS), the shared IT platform the Digital Agency runs for Japanese ministries. They got in through a VPN vulnerability that had already been disclosed but not yet patched.
  • Files containing personal data on about 246,000 people may have been taken. Most are government officials, but about 57,000 are private-sector workers and individuals who dealt with the agencies involved.
  • The agency detected the activity on June 25, confirmed the intrusion on July 9, and disclosed it publicly on September 11, about eleven weeks after detection. The announcement withholds the product, the vulnerability and any indicators, despite JPCERT/CC's long-standing call for victims to share attack technical information.
  • The agency has not named the product. piyolog, a Japanese security researcher, has pointed to CVE-2026-0257, an authentication bypass in Palo Alto Networks' GlobalProtect VPN. It was first rated Medium, exploited within days, and added to CISA's Known Exploited Vulnerabilities catalog on May 29.

What happened#

On September 11, 2026, Japan's Digital Agency announced that GSS had been accessed by an outside party. GSS (ガバメントソリューションサービス) is the standardized office IT environment that the agency provides to ministries and agencies, covering networks, work PCs and cloud infrastructure. The agency said files containing personal information may have been leaked.

According to the agency, the attacker exploited a vulnerability in a VPN device that is part of GSS. The attacker then used the account of a maintenance and operations staff member (保守運用担当者) to access a large number of files on a server.

The agency says government operations were not disrupted. It also says no secondary misuse of the data, such as fraud, has been confirmed so far.

Timeline#

Date (2026) Event Source
May 13 Palo Alto Networks publishes CVE-2026-0257, an authentication bypass in PAN-OS GlobalProtect Vendor, NVD
Mid-to-late May Exploitation of the flaw reported in the wild. Attackers are believed to have entered GSS around this time piyolog (Japanese researcher), media reports
May 29 CISA adds CVE-2026-0257 to its Known Exploited Vulnerabilities catalog CISA
June 25 Digital Agency detects mass file access using a maintenance account and starts investigating Digital Agency
July 9 Agency confirms a third party entered via a VPN vulnerability. It suspends the account and cuts the compromised device's external connections Digital Agency
July 15 Agency reports the incident to the Personal Information Protection Commission Digital Agency Q&A
September 11 Public disclosure and minister's press conference Digital Agency
September 12 Q&A updated to add the date of the report to the Commission Digital Agency

Some English-language reports have given a later disclosure date. The Digital Agency's notice and the minister's press conference are both dated September 11.

What data was exposed#

The agency says about 246,000 records may have been exposed:

Group Records
Staff of agencies using GSS, and other public servants who worked with them (including staff of incorporated administrative agencies) ~189,000
Businesses and individuals who worked with those agencies ~57,000

By data type (a person can appear in more than one row):

Data type Records
Names ~236,000
Email addresses ~231,000
Phone numbers ~94,000
Addresses ~1,000

According to the Q&A, the data came mainly from user registration forms for the system. Most phone numbers and addresses are official office contacts, not personal ones. The agency says no My Number (national ID) numbers, bank account details or pension numbers were included, and no data on the general public.

The private-sector group includes employees of companies and sole proprietors who worked with the affected agencies. It also includes people who joined web meetings held by those agencies. The agency has not named the ministries involved and says it is contacting affected people individually.

The vulnerability#

The Digital Agency has declined to identify the vulnerability, citing security reasons. It has said the following:

  • The vulnerability had been publicly disclosed before the attack.
  • Its initial severity rating was Medium on the CVSS scale.
  • The agency was patching it faster than its normal process for that severity, but the flaw was exploited before the patch was applied.

The link to a specific vulnerability comes from piyolog, a Japanese security researcher. piyolog runs a long-running, widely read blog that compiles Japanese incidents from public sources. In a write-up published the evening of the announcement, piyolog pointed to CVE-2026-0257 as the likely flaw, and Japanese media coverage has since cited the same CVE. This is a researcher's inference, not an official finding, but the pieces fit:

  • It is an authentication bypass in the GlobalProtect portal and gateway of Palo Alto Networks' PAN-OS, and lets an attacker "establish an unauthorized VPN connection".
  • It was published on May 13, 2026, and was reported as initially rated Medium.
  • Palo Alto Networks now rates it 7.8 (High) under CVSS v4.0, and NVD's own CVSS 3.1 score is 9.1 (Critical).
  • CISA added it to the KEV catalog on May 29, with a remediation deadline of June 1 for US federal agencies. The catalog marks it as known to be used in ransomware campaigns.

No ransom demand or threat actor claim has been reported in this case, and the agency describes the attacker only as a "third party".

Our analysis#

Severity scores are not a patching plan#

The agency's own explanation is the core lesson. It prioritized the patch according to the vulnerability's published severity. In the minister's words, the rating "was not high urgency", so the fix went through the normal sequence.

But this was an internet-facing VPN, the kind of device attackers scan for within hours of a disclosure. Exploitation began within days. Once CISA listed it as actively exploited, the risk was no longer theoretical, whatever the base score said.

The Q&A promises to move to "substantive, risk-based" vulnerability management that accounts for how important government systems are. For any organization, that means prioritizing by exposure and evidence of exploitation (KEV listings, vendor exploitation notices), not by CVSS alone.

"Zero trust" in Japan is often a label, not an architecture#

GSS has been promoted as a zero trust environment, and the agency's Q&A says it had adopted zero trust architecture. The agency declines to explain how, and we do not know how GSS implements it. What we do know is that the attacker entered through a VPN and then used a single maintenance account to reach large volumes of files. It also took two weeks after detection to confirm the entry path.

The definition in the Digital Agency's own policy makes this uncomfortable. Its Zero Trust Architecture Application Policy (DS-210, June 2022) cites NIST SP 800-207. It describes zero trust as:

  • Assuming that the inside of the perimeter can be compromised
  • Enforcing access control with the minimum necessary privilege for each request

It also states plainly that zero trust architecture does not refer to any specific implementation or solution. Measured against that definition, an operations account that could read so much is exactly the kind of implicit trust zero trust is supposed to remove.

This matters beyond GSS. Working in security in Japan, we regularly see the term ゼロトラスト (zero trust) used as a product label rather than a design principle. The typical claim is "we deployed SASE, so we are zero trust", or the same with a cloud proxy or ZTNA gateway. Meanwhile, privileged accounts keep broad standing access, internal access is not evaluated per request, and logs are not watched closely enough to reconstruct an intrusion quickly. The product changes how users connect. It does not by itself limit what an account can do once connected.

The minister's own comment points the right way: holes will always be found somewhere, so zero trust controls have to be reviewed continuously. For readers outside Japan, the practical advice is simple. When a Japanese partner or vendor says it is "zero trust", ask what that means concretely:

  • Which access decisions are evaluated per request, and on what signals?
  • How are administrator and maintenance accounts restricted and monitored?
  • How quickly could the organization reconstruct what an account accessed?

Late, and not useful to anyone else#

The agency reported to the privacy regulator six days after confirming the intrusion. It went public only on September 11, eleven weeks after detection, saying it needed time to establish the scope and identify the people affected. Japanese media, including Nikkei, have criticized the delay.

The timing is only half the problem. What was disclosed matters just as much. The announcement and Q&A do not name:

  • The product or the vulnerability
  • Any indicators of compromise
  • The ministries affected
  • When the attacker first got in

Each time, the agency cites security reasons. For another organization running the same VPN, the announcement contains nothing it can act on. The most useful technical lead in the public record, the likely CVE, came from an independent researcher's inference, not from the victim. And the victim is the government agency responsible for Japan's digital infrastructure.

This runs against what Japan's own national CSIRT has been arguing for years:

  • 2022. JPCERT/CC called for attack technical information (malware, infrastructure, vulnerabilities exploited) to be shared early and kept separate from information about the victim and the damage. That way, other organizations can defend themselves while the victim is still investigating.
  • 2023. That idea became government guidance, the Guidance on Sharing and Disclosure of Cyber Attack Damage Information. It was developed with the Ministry of Internal Affairs and Communications, NISC (now the NCO), the National Police Agency, the Ministry of Economy, Trade and Industry, and JPCERT/CC.
  • Also 2023. JPCERT/CC argued that naming the cause in a public announcement warns other users of the same product in a way vendor advisories alone do not. It also argued that when the cause is a known vulnerability that others will identify anyway, refusing to name it "for security reasons" has little justification.

The agency may well have shared technical details privately with the NCO or JPCERT/CC. The guidance encourages exactly that, and we would not see it. But the public record offers the rest of the ecosystem nothing actionable.

We find this disappointing, and we think it is revealing. In Japan, public disclosure of a cyber incident is still treated mainly as an apology and an accounting to the people whose data was exposed. It is not yet seen as a contribution to collective defense. The announcement is carefully worded, complete on the personal data, and silent on everything a defender would need. When the government's own digital agency follows this pattern, it tells you where Japan's default still sits.

The contrast with the new law is hard to miss. From October 1, Japan's Active Cyber Defense law requires critical infrastructure operators to report incidents to the government "promptly", with only what they know at the time. That duty covers reports to the authorities, not public disclosure, and it does not apply to the Digital Agency itself. Still, the government is about to ask private operators for a speed and openness in reporting that it did not show the public in its own case.

What this means for readers outside Japan#

  • Expect targeted phishing that uses Japanese officials' names. Names, work email addresses and phone numbers of Japanese government staff are exactly what spear-phishing needs. Anyone who works with Japanese ministries should be wary of unexpected messages that appear to come from officials or from the Digital Agency. The agency says it will never ask for passwords or card details by email or phone.
  • You may be in the data yourself. If your company worked with a Japanese ministry, or you joined one of its web meetings, your name and work contact details could be among the ~57,000 non-government records. The agency is notifying affected people individually and has set up a dedicated contact point.
  • Check your own GlobalProtect deployments. If you run PAN-OS GlobalProtect and have not applied the fixes for CVE-2026-0257, treat the device as potentially compromised, not merely unpatched.

Japanese terms at a glance#

Japanese Reading Meaning
ガバメントソリューションサービス（GSS） gabamento soryūshon sābisu Government Solution Service, the Digital Agency's shared IT platform for ministries
保守運用担当者 hoshu un'yō tantōsha Maintenance and operations staff
漏えいした可能性 rōei shita kanōsei "Possibly leaked". Standard wording in Japanese breach notices when exfiltration cannot be ruled out
個人情報保護委員会 kojin jōhō hogo iinkai Personal Information Protection Commission (privacy regulator)
脆弱性管理 zeijakusei kanri Vulnerability management
ゼロトラスト zero torasuto Zero trust. In Japan often used as a product or marketing label
お答えを差し控えさせていただきます okotae o sashihikaesasete itadakimasu "We must refrain from answering". The standard phrase for declining to disclose details
攻撃技術情報 kōgeki gijutsu jōhō Attack technical information (JPCERT/CC and government guidance term)

We will update this article if the Digital Agency publishes further findings.