Cybersecurity · Monday, 17 August 2026
01 · Briefing · what happened
The year's best defence against stolen logins shipped switched off
Chrome now has a serious answer to the attack that beats two-factor codes. It is turned on for almost nobody. That was the shape of the whole week.
421
Microsoft flaws fixed
on 11 August; Krebs counted 398, 42 of them critical
10,920
people exposed at ACRO
seven months of access nobody noticed
444
poisoned npm packages
downloaded around two billion times a month
1.6m
RingCentral accounts exposed
names, emails, phones and addresses
At a glance
- Chrome shipped device-bound session credentials, the strongest answer yet to stolen login sessions, and turned it on for only a limited set of users.
- Session cookies are now the prize: two-factor codes made passwords less useful, so attackers steal the proof-of-login instead.
- Three research teams defeated passkeys without breaking the maths, partly because most passkeys sit in software, not in a secure chip.
- Microsoft fixed roughly 400 flaws on 11 August, one already used by North Korea's Lazarus group against defence firms.
- Britain's criminal records office was reprimanded: its security tool raised alerts for seven months and nobody read them.
- Two supply-chain attacks were built to step around protective settings rather than break them.
- Suisun City, Coweta and Mitchell all lost public services to attacks; RingCentral exposed data on 1.6 million accounts.
Forces in play
Chrome's new protection against stolen logins is live but enabled for only a limited set of users, so almost nobody has it yet.
Microsoft fixed around 400 flaws in one day, double June's then-record; it credits AI-assisted bug hunting for the surge.
The ChainDrop worm infects without an install, and the Trivy compromise stepped past the setting that blocks install scripts.
Suisun City lost 911 routing, Coweta lost every computer, Mitchell shut its networks - three small towns in one week.
Britain's data regulator spelled out exactly what ACRO got wrong - unowned patching and unread alerts - and credited its network segmentation for limiting the damage.
How it unfolded
- 4 Aug ChainDrop worm found in 444 npm packages
- 7 Aug Suisun City loses 911 routing at 5:45am
- 10 Aug Metabase patches a flaw already being exploited
- 11 Aug Microsoft ships around 400 fixes, one flaw already in use
- 12 Aug UK regulator reprimands ACRO over unread alerts
- This week Chrome's new session protection goes live for a limited set of users
Where this points
Watch whether Google moves device-bound session credentials from a limited test to on-by-default, and whether other Chrome-based browsers follow - that switch, not the feature itself, is what would change the numbers.
Full briefing
Google has added the strongest protection yet against a form of account theft that has quietly grown as everything else got safer
That is not a scandal. It is testing, and testing is sensible. But it is also the week in one line. The defences exist. The settings exist. What decides who gets robbed is whether somebody flipped a switch.
The best answer yet, and almost nobody has it
The attack Chrome is now defending against is session-cookie theft
That token has become the prize. Two-factor codes and passkeys made stealing a password much less useful
Chrome’s answer is called device-bound session credentials
“The attacker can steal the cookie, but they can’t answer a DBSC challenge,” researcher Scott Helme told Ars Technica
The catch is the rollout. It works only in recent Chrome releases on Windows and Mac, and even there it is switched on for a limited set of users while Google tests it
Passkeys are not stored where most people assume
The same week produced three separate pieces of research defeating passkeys, none of which broke the underlying maths
Passkeys replace passwords with a key pair split between your device and the site. The common belief is that the private half lives in that same locked chip. It usually does not. The FIDO standards do not require passkeys to be kept in dedicated hardware, and most platforms and passkey apps do not put them there
That default is what one attack used. Palo Alto researcher Arie Olshtein showed that on a Windows machine already infected with malware, his technique could pull every passkey stored by the Google Password Manager app
Microsoft issued a fix for one piece of this, CVE-2026-34348, a flaw in the Windows Event Logging Service rated 6.5 out of 10
Passkeys are still far better than passwords. The point is narrower: where the key sits is a configuration choice, and the choice most software makes for you is software storage.
Around four hundred fixes, and one already in use
Microsoft’s monthly patch release on 11 August was enormous. SecurityWeek and ZDNet counted 421 flaws fixed
One flaw was already being used. CVE-2026-68820 sits in afd.sys, a core Windows networking driver
North Korea’s Lazarus group had been using it since early July, against defence, aerospace and aviation firms in Europe and India, approached through fake job offers
Elsewhere: Metabase patched a critical flaw already being exploited that handed unauthenticated attackers admin access to its analytics tool
The alarm that worked, and nobody read
Britain’s criminal records office, ACRO, was reprimanded by the data regulator this week over a breach nobody caught for seven months
An intruder had access to ACRO’s website and its Kentico content management system from August 2022 to March 2023, exposing data on 10,920 people
The Information Commissioner’s Office found two failures, and both are about who was configured to act. ACRO’s outsourced IT provider patched the operating system but not the Kentico software
The second failure is sharper. ACRO had security software installed, and it generated alerts. Those alerts were “not reviewed or acted upon”
Attacks built to walk around the settings
Two supply-chain stories this week are about protections being routed around rather than broken.
The compromise that exposed credentials at more than 2,500 organisations turned out to trace back further than first reported
The haul was enormous: terabytes of cloud keys, code-repository tokens and other secrets, with Microsoft, Amazon, Cisco, Samsung and Salesforce among the organisations whose credentials appeared
The newer worm, ChainDrop, is worse in the same way. Researchers found it in 444 npm packages on 4 August, together downloaded around two billion times a month
Three towns offline, and 1.6 million accounts
Small US local governments had a bad week. Suisun City, California, population about 30,000, was hit by malware at 5:45am on 7 August that took down 911 call routing, police and fire dispatch, records and city services
Coweta, Oklahoma, population about 12,000, lost every computer and digital service to ransomware
Ransomware is malware that scrambles an organisation’s files and demands payment for the key. Microsoft warned that a China-linked crew, Storm-1175, began deploying a new strain on 2 August
And RingCentral, a business phone and messaging platform used by over 600,000 companies, had data on 1.6 million accounts exposed
If you use RingCentral through your employer, treat unexpected calls or messages referencing your work details with suspicion. That contact data is now public.
Washington changes a default of its own
Late on Wednesday President Trump signed a memorandum encouraging selected American companies to hack back at foreign criminal groups, working with the Justice and Homeland Security departments
It is a sharp reversal. For decades, across both parties, US policy kept offensive hacking inside the military and intelligence agencies and pushed companies toward better defence
The practical worry is simple. A company that hits back can be wrong about who it is hitting.
02 · Lesson · why it matters
The setting almost nobody changes is the one that decides
A setting you could turn on and a setting that is on are different worlds - because changing it takes knowing, caring, and acting.
How it works
- A vendor ships a safety setting
- Changing it needs someone to know it exists
- Then to decide it matters
- Then to actually go and do it
- Almost nothing survives all three filters
- So whatever shipped is what the installed base runs
The twist
A setting that is available and a setting that is on are worlds apart, so the vendor's default is not a suggestion - it is the effective policy for everyone who never touches it.
Where you've seen this
Organ donation
opt-in and opt-out countries have wildly different rates with similar public opinion
Workplace pensions
auto-enrolment lifted participation far more than years of encouragement did
Cookie banners
whichever box is pre-ticked is what most people end up agreeing to
Phone privacy settings
the sharing that is on out of the box is the sharing that happens
The catch
Safe defaults have real costs - they break existing setups, they generate support load, and a default that is right in one setting is wrong in another, which is exactly why vendors resist them.
Full lesson
The protection that shipped switched off
Google built a good thing this week. Chrome can now lock a login session to the machine it started on, so a stolen session token is worthless anywhere else. It closes the gap that opened when two-factor codes made passwords harder to use.
Then it turned the thing on for a limited set of users.
That is not a criticism. Testing a change across billions of machines carefully is the responsible move. But hold the two facts next to each other, because they explain most of the rest of the week. The best defence available and the defence most people are running are not the same object.
Three filters almost nothing survives
To change a setting, a person has to do three things in order.
They have to know it exists. They have to decide it matters enough to bother. Then they have to actually go and do it, on a Tuesday, instead of the work they were already behind on.
Each step loses most of the people who cleared the last one. Stack them and the survival rate is tiny. This is why almost nobody changes a default of any kind - not out of laziness, but because the path is long and everything else is shorter.
So whatever a vendor ships as the starting position is what the overwhelming majority of its users will run, for as long as they run it. The default is not a suggestion. It is the effective policy for the entire installed base.
Where you can see it working
Passkeys are the clean example. Most people assume the secret half of a passkey lives in a locked chip inside their device. The standard does not require that, and most software does not do it, so it usually sits in ordinary storage instead. Nothing was hidden. Anyone could have read the specification. The default decided the outcome for everyone who did not.
Britain’s criminal records office is the other shape of it. Security software was installed and it was raising alerts. Nobody was configured to read them. Patching the website software was a job that existed in principle and belonged to no one in practice. Seven months of intrusion followed. The capability was all there. The switch was never in the on position.
Why “they could have turned it on” is a weak defence
That sentence is technically true and does almost no work. It describes what a user could have done, not what the system produced.
If you ship a setting that ninety-seven people in a hundred will never touch, then you have chosen the outcome for ninety-seven people. Framing it as their choice only relocates the responsibility; it does not change the numbers. This is the quiet reason misconfiguration and unchanged defaults beat exotic exploits as a cause of breaches, year after year. The clever attack is rarer than the switch left where it shipped.
The most valuable security work a vendor can do is often not building anything. It is flipping something that already exists, and making the unsafe path the one that takes effort.
The honest cost
Safe defaults are not free, and that is why vendors resist them.
A default that is on will break someone’s working setup. It will fill a support queue with people whose Tuesday you just ruined. And a setting that is plainly right in a hospital can be plainly wrong in a factory. A vendor shipping one default for everyone is imposing a judgement on situations it cannot see. Those costs are real, they are paid immediately, and they land on the vendor. The benefit is spread thin across the installed base and mostly invisible, because it takes the form of things that did not happen.
That asymmetry is the whole reason so much protection ships switched off.
Who is actually holding the switch
This is not really about browsers. Whoever writes the default is deciding for everyone downstream who never opens the menu.
A pension scheme that enrols you automatically produces a different retirement than one that waits for a form, from the same people. Whichever box is pre-ticked on a consent banner is what most of the internet ends up agreeing to. Countries with almost identical public opinion on organ donation have wildly different donor rates, and the difference is which way the form is worded.
None of that is people choosing. It is people not choosing, which is the ordinary human condition, and someone else having already answered on their behalf.
Suisun City lost its 911 routing at quarter to six one morning. Nobody in that town picked a configuration. Their emergency calls depended on switches set in offices they will never see, by people who were weighing support tickets against risks that were only statistical until they were not. Most of the settings that decide our exposure were decided somewhere else, by someone with a different set of costs in front of them. That includes, right now, the ones sitting behind the screen you are reading this on.
03 · Lab · your turn
Ship the default
Choose how a security setting ships across 100,000 organisations and watch the starting position, not the feature, decide who ends up protected.
04 · Hope · carry this
Nearly everything that would have helped this week was already built and already paid for. Protection that needs a decision rather than an invention is the kind that can arrive fast.
More from Cybersecurity