What the Digital Agency's GSS Breach Teaches Us | When a "Medium" VPN Flaw Gets Exploited, How Should Companies Patch and Connect?

Hello, this is Ryuta Hamamoto from TIMEWELL. On 11 September 2026, Japan's Digital Agency announced that a third party had gained unauthorized access to the Government Solution Service (GSS), the shared work environment it runs for ministries, and that roughly 246,000 records of personal information about government staff and related parties may have leaked¹. The stated point of entry was a vulnerability in a network device, specifically a VPN appliance. The flaw had been published before the attack, and its initial severity rating was CVSS "Medium"².

I am not writing this to tally the agency's mistakes. On the same day it published a Q&A that volunteers the awkward facts: the vulnerability was known, it was rated Medium, and the patch had not yet been applied when the attackers used it. I respect that. But the incident contains a structural problem that applies to nearly every organisation in Japan and beyond. Why did fixing vulnerabilities in order of severity fail to arrive in time? Why was a system built on zero trust breached through a VPN box? And what should your organisation change tomorrow? I want to work through those three questions using only the published facts and public statistics.

The specific vulnerability, the device vendor and the attacker have not been disclosed. I will not fill that gap with guesses.

What happened, in the order it was disclosed

Here is the timeline as the agency's press release and Q&A describe it¹².

It begins on 25 June 2026. The agency detected large-scale access to files on a server using a maintenance operator's account and opened an investigation. Keep that phrase, "a maintenance operator's account", in mind; I will come back to it. On 9 July it established that a third party had entered the system through a VPN device vulnerability. The same day it disabled the account and cut the compromised device off from external communication. With an outside forensic firm it then confirmed that personal information may have left the environment, and it went public on 11 September. That is 78 days from detection to disclosure, and 64 days from identifying the entry route.

About 246,000 records may have leaked. Roughly 189,000 concern staff of the ministries and agencies that use GSS, plus other public servants involved in their work, including employees of incorporated administrative agencies. About 57,000 concern contractors and individuals who worked with those bodies. Counting overlaps, the fields are names (about 236,000), email addresses (about 231,000), phone numbers (about 94,000) and addresses (about 1,000). The Q&A adds that most of the phone numbers and addresses are not personal: they are ministry office addresses and official contact numbers. My Number identifiers, bank account details and pension numbers were not involved, and no data on members of the general public was included. As of 11 September, no secondary damage such as impersonation emails had been confirmed².

It helps to know what GSS is. The agency describes it as a service that provides "a standard, government-wide work environment (work PCs and network)", and it is the core of a programme to consolidate ministry networks onto an architecture built on zero trust³. As of February 2025 it served 13 organisations and 42,000 connected users⁴, and the July 2026 priority policy list sets a target of more than 270,000 users by the end of fiscal 2030⁵. This is fast becoming the foundation for the laptops and networks of Japan's national civil service, which is why the incident matters beyond the headline number.

On the 78 days, the Q&A says that "at the time of initial detection, whether unauthorized access had occurred and its scope were unknown, and analysing the intrusion route, identifying the information that may have leaked, and confirming the affected individuals took considerable time"². Anyone who has run a forensic investigation will find that plausible. From the affected person's side, though, it means names and email addresses that can be used for phishing were out of their control for two and a half months. Japan's personal data law requires administrative bodies to report to the Personal Information Protection Commission, and in the private sector the guidance is a preliminary report within roughly three to five days and a full report within 30 or 60 days⁶. Reporting to the regulator and telling the public are separate decisions. Still, a policy of "publish only once the facts are confirmed" removes the affected people's chance to protect themselves during the investigation, and that trade-off deserves a place in your own disclosure policy. If you want to check how organised your first response and disclosure decisions actually are, an inventory like our AI literacy assessment is one place to start.

A "Medium" flaw was exploited. The limits of patching in severity order

The heart of this incident sits in one passage of the Q&A: "The vulnerability exploited in this incident was rated Medium (CVSS) in the assessment published at the time." And: "We were addressing it faster than the general response for a vulnerability of that published severity. Nevertheless, it was exploited before the fix was applied"². At the press conference the minister explained that the team had been working through more urgent vulnerabilities first when this one was used⁷.

So the agency was not ignoring the flaw. It prioritised by severity and moved faster than the usual benchmark. It still lost the race. That is the same structure most organisations live with. CVSS, the Common Vulnerability Scoring System, measures how bad a vulnerability would be if exploited. It does not predict whether attackers will actually use it. Attackers do not work down a list from the highest score. They use whatever exploit they have in hand against whatever device they can reach right now. A Medium-rated flaw with public exploit code that works against an internet-facing VPN appliance is, from the attacker's point of view, the best door in the building.

The United States codified this thinking in CISA's Binding Operational Directive 22-01. CISA's own explanation: "Rather than have agencies focus on thousands of vulnerabilities that may never be used in a real-world attack, BOD 22-01 shifts the focus to those vulnerabilities that are active threats." Anything on its Known Exploited Vulnerabilities (KEV) catalogue with a CVE assigned in 2021 or later must be fixed by federal agencies within two weeks⁸. Deadlines set by exploitation, not by score. If I had to pick a single lesson from the GSS incident for any organisation, it would be that one.

The trouble is that real-world remediation is moving the other way. Verizon's 2026 Data Breach Investigations Report found that exploitation of vulnerabilities accounted for 31 percent of initial access in breaches, up from 20 percent the year before, and for the first time overtook credential abuse as the top way in. The median time to remediate a known exploited vulnerability was 43 days, almost two weeks longer than the previous year's 32, and only 26 percent were fully remediated, down from 38 percent⁹. Meanwhile a JPCERT/CC analyst notes that once a zero-day is discovered and the vulnerability is published, broad "N-day" exploitation follows almost immediately¹⁰. Attackers move within days of disclosure; defenders take a median of 43 days. GSS fell into that gap.

Honestly, "we patch high-severity items first, in the monthly maintenance window" was the textbook answer a few years ago. For internet-facing devices it no longer is. Even for a Medium rating, ask three questions: is exploitation confirmed, is exploit code public, and is the device visible from outside? If all three are yes, it goes to the top regardless of score. When the agency says in its Q&A that it will move to "faster, more proactive responses based on substantive risk"², this is the shift it means.

The VPN appliance has gone from safety box to the most attacked door

That the entry point was a VPN device is not a coincidence. Look at the numbers and it is the typical case.

Japan's National Police Agency reports 226 ransomware cases in 2025. Of the 92 victims who could identify the entry route, 61, or 66.3 percent, were breached through a VPN device. Remote desktop accounted for 19, and suspicious email for just 2. Over the past five years, 293 of 485 cases, more than 60 percent, came in through VPN devices¹¹. The report summarises the pattern: attackers exploit "unpatched vulnerabilities, leaked or weak credentials, and configuration errors" to enter the network. Targeted phishing, once the main act, is now a supporting player.

International data points the same way. Verizon's 2025 DBIR found that edge devices and VPNs were the target in 22 percent of breaches involving vulnerability exploitation, up almost eightfold from 3 percent the year before. Only about 54 percent of those flaws were fully remediated within the year, with a median of 32 days¹².

Why are VPN appliances hit so often? A JPCERT/CC presentation at Internet Week 2025 lays it out from a practitioner's view¹⁰. First, firewalls, SSL-VPN gateways and load balancers face the internet directly yet often cannot run host-based monitoring such as EDR, so they are weakly watched. Second, when they are compromised, credentials tend to be stolen, and even multi-factor authentication can be bypassed; the presentation notes cases where an edge-device compromise led to the theft of high-privilege account credentials. Third, credentials stolen or backdoors planted before a patch can be passed to other attack groups and used later, so "we patched it" is not the end; you have to check whether you were already compromised when the patch went on. In 2025 alone JPCERT/CC issued 11 alerts and CyberNewsFlash notices on edge devices from vendors including Ivanti, Fortinet, SonicWall, Citrix, Cisco and WatchGuard¹⁰.

Let me be blunt about one thing. A VPN is bought as a tool for safety. To an attacker it is the legitimate entrance to the internal network, one that opens with valid credentials, and if the box itself has a vulnerability, no credentials are needed. The safety box has become the easiest pane of glass to break. Both IT departments and boards need to make that mental switch.

It was built on zero trust. Why was it breached anyway?

GSS was built and promoted as a zero-trust system³, so "it was zero trust, how did this happen?" is a fair question. The Q&A poses it and answers: "We had adopted a zero trust architecture, but we take seriously that unauthorized access and possible leakage nevertheless occurred"². The minister put it plainly at the press conference: even with zero trust, there may be a hole somewhere⁷.

Answering the question means going back to what zero trust is. The agency's own 2022 Zero Trust Architecture Application Policy (DS-210) defines zero trust as a concept "designed to minimise uncertainty when enforcing appropriate, least-privilege access control for each request to systems and services, on the assumption that the inside of the perimeter may also be compromised", and states that zero trust architecture "does not refer to a specific implementation or solution". It also says the architecture "does not reject perimeter security or network-based security measures"¹³.

In other words, adopting zero trust does not make the VPN box disappear. In most organisations the VPN appliance, or an equivalent gateway, remains as the front door of the zero-trust design. If that device itself is vulnerable, the attacker is inside before any access policy gets evaluated. Zero trust is a design for limiting what an intruder can do once inside; it is not a guarantee that the door has no holes. The organisations that have leaned on the phrase for reassurance are exactly the ones that should sharpen that distinction.

One more detail deserves attention. The detection that started everything was "large-scale file access using a maintenance operator's account"¹. The reading is that the attacker came in through the VPN flaw and then moved using an account that held maintenance privileges. Per the Q&A, the VPN devices are part of GSS, managed under the agency's responsibility and "in some cases outsourced to external contractors"². That matches JPCERT/CC's warning that edge-device compromises lead to high-privilege credential theft¹⁰.

I want to be fair here. Detecting an anomaly in bulk file access is evidence that GSS monitoring worked. Without it, both the scope of the leak and the intrusion itself might have gone unnoticed far longer. At the same time, it shows how hard detection becomes when the stolen privilege is one where touching many files looks normal. The agency's July 2026 policy list says it will consider expanding outsourcing of routine operations such as device management and help desk during fiscal 2026⁵. Outsourcing is a realistic choice. But how to minimise and watch the privileges of maintenance accounts when you do so is the homework this incident sets.

What any organisation can change this week: act on exposure and exploitation, not scores

Now to your organisation. The same structural hole exists in every company, large or small, that points a VPN appliance or firewall at the internet. Here is what I would do, in order of priority.

Start with an inventory of everything exposed to the internet: VPNs, firewalls, load balancers, remote desktop gateways, and the small branch-office routers everyone forgets. For each, record the model, firmware version, where the management interface is reachable from, and who maintains it. JPCERT/CC closes its presentation by warning organisations not to leave hosts without remediation¹⁰, because real victims were running end-of-life versions nobody had on a list. You cannot protect what is not on the sheet.

Second, give edge devices their own remediation deadlines, separate from the monthly server patch cycle. The rule I recommend in practice is simple: for internet-facing devices, any vulnerability with confirmed exploitation or public exploit code gets patched or mitigated within 72 hours, regardless of CVSS. CISA's two-week federal deadline⁸ is a ceiling; given that N-day attacks start right after disclosure¹⁰, exposed devices need something shorter. Subscribe to JPCERT/CC alerts, your vendors' advisories and CISA's KEV catalogue, and put that subscription on a team rota rather than in one person's inbox.

Third, decide your interim measures in advance for when a patch cannot be applied immediately. If testing or vendor coordination is needed, first take the management interface off the internet, disable unused SSL-VPN web modes and portal features, and restrict source addresses to the countries and sites your business actually needs. Never let "we cannot do anything until the patch is out" be the state you are in.

Fourth, the handling of maintenance accounts. As this incident shows, once inside, attackers look for privileges under which touching many files is unremarkable. Do not keep privileged maintenance accounts permanently enabled; issue them per task, with an expiry. Give each contractor engineer a named account and retire shared IDs. Add "maintenance account accesses a large volume of files outside working hours" to your detection rules. GSS caught this incident with exactly that kind of signal, which means the same mechanism can work for you.

Fifth, get logs off the device. JPCERT/CC cites cases where edge-device logs lived only on the appliance and were wiped by the attacker, leaving nothing to investigate¹⁰. Forwarding logs to an external platform changes whether you can answer "were we breached?" at all. And after patching, run the check for prior compromise. Credentials stolen before the patch are not invalidated by it. Patch, then rotate credentials. That extra step is what stops the second intrusion.

None of this is purely technical work. Budget priorities, contract clauses with maintenance vendors and the disclosure decision belong to management. Our WARP SECURITY programme spends more time on that peacetime design and decision-making than on attack techniques. I made a similar argument in what companies should take from Sakura Internet's breach: decide in advance what responsibilities and procedures remain yours when a provider or a system is compromised, because that preparation is what actually pays off. If you want to formalise the management system behind it, our introduction to ISMS (ISO/IEC 27001) is a reasonable next read.

Closing: "Medium" still gets exploited, so change how you order the work

In one sentence: a known, Medium-rated VPN vulnerability was exploited before severity-ordered remediation reached it, and through a maintenance account some 246,000 personal records may have leaked. The Digital Agency disclosed the facts, including the uncomfortable ones, and says it will rebuild vulnerability management around "substantive risk, faster and more proactively"². I think that is the right direction. And the same rebuild is needed far more urgently in companies without a dedicated security team than in central government.

What to take away: a CVSS score tells you how much it hurts if exploited, not whether it will be. An internet-facing VPN appliance is the most attacked door there is, the entry route in more than 60 percent of Japanese ransomware cases. Zero trust limits damage after entry; sealing holes in the door is a separate job. And patching is only finished once you have checked that nobody got in before the patch.

This week, start by putting every device visible from the internet on a single sheet. That alone lets you answer "does this affect us?" in minutes the next time an alert lands. If you would like to talk through deadline design for edge devices, maintenance account controls or a disclosure policy that involves your leadership, reach out through our consultation form. We will listen first, then work out priorities together.

References

The facts in this article are drawn from the published sources below. As of 11 September 2026, the specific vulnerability, the device vendor and the attacker have not been disclosed.

Footnotes

1. Possible leakage of personal information of staff due to unauthorized access to the Government Solution Service — Digital Agency, Japan — 11 September 2026 (Japanese) ↩ ↩² ↩³

2. Q&A on the possible leakage of personal information due to unauthorized access to the Government Solution Service — Digital Agency, Japan — 11 September 2026 (Japanese) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

3. On the Government Solution Service (GSS), material for the Policy Evaluation and Administrative Programme Review expert meeting — Digital Agency — 29 May 2024 (Japanese) ↩ ↩²

4. Priority Plan for the Realization of a Digital Society — Digital Agency — 13 June 2025 (Japanese) ↩

5. List of Priority Policies (1-1 Migration to GSS; 1-2 Advancing security and disaster resilience of GSS) — Digital Agency — 21 July 2026 (Japanese) ↩ ↩²

6. Mandatory reporting of leaks and notification to data subjects — Personal Information Protection Commission, Japan (Japanese) ↩

7. Minister Matsumoto explains the possible leak of 246,000 records: "a known vulnerability exploited before remediation" (press coverage, supplementary; the official summary of the minister's press conference is to be published later) — ITmedia NEWS — 11 September 2026 (Japanese) ↩ ↩²

8. BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities — CISA — 3 November 2021 ↩ ↩²

9. 2026 Data Breach Investigations Report — Verizon (figures also reported in Verizon DBIR: Vulnerability exploitation is the dominant initial access vector — Help Net Security — 20 May 2026) ↩

10. Edge Devices Under Continuous Attack: cyberattacks as seen by JPCERT/CC — Tatsuya Kuge, JPCERT/CC, Internet Week 2025 presentation hosted by JPNIC (Japanese) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

11. Threats in Cyberspace in 2025 — National Police Agency, Japan (Japanese) ↩

12. 2025 Data Breach Investigations Report — Verizon ↩

13. Zero Trust Architecture Application Policy (Standard Guidelines ID DS-210) — Digital Agency — 30 June 2022 (Japanese) ↩