5 short insights this week: A record $409M privacy fine, and not a hacker in sight · A 9.8 zero-day in PeopleSoft, no login required · npm is finally turning off the feature that kept getting you hacked…
In this edition
Get the next GRC Brief in your inbox.
Subscribe to The GRC BriefA record $409M privacy fine, and not a hacker in sight
South Korea's privacy regulator hit Coupang, the country's largest online retailer, with a 624.7 billion won fine (about $409 million). It is the biggest data-protection penalty in the country's history, nearly five times the previous record. The breach exposed roughly 34 million customers plus 4.3 million non-members, around two-thirds of the population. The cause was not sophisticated hacking. A former employee who had helped build Coupang's authentication system walked off with a signing key and kept access for months, undetected. The regulator called it "deficiencies in basic safety management." Coupang also missed the 24-hour reporting window, failed to preserve proper logs (triggering a criminal referral), and ignored four requests to notify the non-member victims.
Source: The Record · reporting also by BleepingComputer
My take
Read the cause again. Not a nation-state. Not a clever exploit. A guy who left, whose key nobody revoked. The most expensive breach of the week was an offboarding failure.
This is what security budgets keep getting wrong. You can spend millions on detection and still lose 34 million records because a departed employee's credentials stayed live and nobody watched the logs. Access reviews and offboarding are not glamorous. They are exactly where the real exposure lives.
And notice what turned a bad breach into a record fine: the basics, again. Missing the reporting clock. No usable logs. Ignoring the regulator's request to warn victims. The breach was the accident. The fine was the response. Regulators punish how you behave after the incident almost as hard as the incident itself.
A 9.8 zero-day in PeopleSoft, no login required
A critical flaw in Oracle's PeopleSoft (CVE-2026-35273), rated 9.8 out of 10, lets an attacker take over the server with nothing but network access. No login, no user interaction. Google's Mandiant says a group it tracks as UNC6240 was exploiting it between May 27 and June 9. Oracle did not publish its advisory until June 10, which means it was a live zero-day the entire time. If you run PeopleSoft with the Environment Management Hub reachable from the internet, that is your exposure.
Source: The Hacker News · attribution by Google Mandiant
My take
PeopleSoft runs HR and payroll for a huge slice of large organisations. That means it sits on a goldmine: salaries, bank details, national IDs, the lot. A pre-authentication remote takeover here is about as bad as it gets.
The uncomfortable part is the timeline. Attackers were in from May 27. The patch landed June 10. For two weeks, the only defence was not exposing the thing in the first place. That is the entire argument for attack surface management in one story. You cannot patch a zero-day you don't know is being exploited. You can make sure your crown-jewel systems aren't casually reachable from the open internet.
Go check whether your PeopleSoft management endpoints are exposed. Today, not next sprint.
npm is finally turning off the feature that kept getting you hacked
GitHub announced that npm version 12, due in July, will stop running dependency install scripts by default. For years, a single "npm install" could execute code from any package anywhere in your dependency tree, the moment you pulled it in, on developer laptops and CI runners full of credentials. That has been the foothold behind a long run of supply-chain attacks. From v12, those scripts (along with Git and remote-URL dependencies) become opt-in, approved explicitly with "npm approve-scripts." The warnings are already live in npm 11.16.0.
Source: The Hacker News · GitHub announcement, 9 Jun 2026
My take
This is genuinely good news, and it is also a deadline. Good, because automatic install scripts have been the single most reliable way to get malicious code onto a build server for over a decade. Closing that by default removes a whole class of attack in one move.
But "breaking changes" means exactly that. If your CI pipeline quietly depends on a package's install script, it breaks on upgrade day. The teams that sail through are the ones who turn on the warnings in 11.16.0 now, see what fires, and build their approved list before July. The teams that ignore it will be debugging broken builds and rubber-stamping approvals under pressure.
And this is a governance question, not just a dev one. Who in your org decides which third-party scripts are allowed to run on your infrastructure? If the answer is "nobody, it just happens," that was always the problem.
DORA's first numbers: 90% of major incidents weren't cyber
The European Supervisory Authorities published the first DORA incident report, the clearest picture yet of what actually breaks in EU finance. Financial entities reported 3,383 major ICT incidents in 2025, roughly 282 a month. The headline finding: only 10% were cybersecurity-related. The rest were system failures, technology outages and external events. Almost a third traced back to third-party providers, and around a third had cross-border impact. The regulators still urge firms to raise cyber standards, because highly capable AI-driven attack tools are coming.
Source: European Banking Authority · ESAs first DORA incident report, 3 Jun 2026
My take
Sit with that 10%. For all the ransomware headlines, nine out of ten major incidents in European finance last year were not attacks. They were things falling over. A botched change, a cloud outage, a supplier going dark.
This is the case for operational resilience in a single statistic. If your entire resilience programme points at hackers, you are defending against 10% of your actual incident volume. The other 90% is reliability engineering, change management and third-party oversight. Less exciting than a breach. Far more likely to take you down on a random Tuesday. And to be clear, this is not "cyber doesn't matter." Ten percent of 3,383 is still a lot of attacks, and the regulators flag AI-driven threats next. Cyber is one part of resilience, not the whole of it.
The number that should worry you more than the 10%: almost a third of incidents came from third parties. Your resilience is only as strong as the suppliers you don't control.
10.9 million records walked out of an unlocked cabinet
Kyushu Electric, one of Japan's largest regional utilities, disclosed that an external hard drive holding data on up to 10.9 million customers went missing from its server room. The backstory is painfully ordinary: short on storage, IT staff copied the data to an external drive on April 27 and locked it in a secured cabinet. On May 26, they came back to find the cabinet unlocked and the drive gone. 57 people had access to the room. The firm filed a police report and suspects the drive was removed. The data includes names, addresses, phone numbers and electricity usage, though no banking or card details.
Source: BleepingComputer · 11 Jun 2026
My take
Two items in this brief now, and not one hacker behind either of the biggest data losses. Coupang lost 34 million records to a departed employee's key. Kyushu lost 10.9 million to an unlocked cabinet. The threat was never exotic.
Notice what is missing from the disclosure: any mention of encryption. A drive holding 10.9 million customer records should be encrypted at rest, full stop. Encrypt it, and a lost drive is a lost piece of hardware, an inventory problem. Leave it in the clear, and it is a breach you report to the regulator and to 10.9 million people.
Physical security is information security. Your access policy means nothing if the cabinet gets left open and 57 people can reach it. And "we'll just use an external drive this once" is exactly the kind of unmanaged shortcut that becomes the incident. Boring control, expensive lesson. Again.