Daylila

Cybersecurity · Monday, 17 August 2026

01 · Briefing · what happened

The year's best defence against stolen logins shipped switched off

Cybersecurity 8 min 20 sources

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

Defences shipping off High

Chrome's new protection against stolen logins is live but enabled for only a limited set of users, so almost nobody has it yet.

Patch volume High

Microsoft fixed around 400 flaws in one day, double June's then-record; it credits AI-assisted bug hunting for the surge.

Attacks routing around settings Building

The ChainDrop worm infects without an install, and the Trivy compromise stepped past the setting that blocks install scripts.

Local government exposure High

Suisun City lost 911 routing, Coweta lost every computer, Mitchell shut its networks - three small towns in one week.

Regulators naming the gap Easing

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.

In play Google Chrome — shipped device-bound session credentials, on for a limited set of users Microsoft — fixed around 400 flaws; warned on a China-linked ransomware crew ACRO — reprimanded by the UK regulator over unread alerts and unowned patching Lazarus — North Korean group using the exploited Windows driver flaw since early July TeamPCP — claimed the supply-chain compromise behind 2,500 exposed organisations

How it unfolded

  1. 4 Aug ChainDrop worm found in 444 npm packages
  2. 7 Aug Suisun City loses 911 routing at 5:45am
  3. 10 Aug Metabase patches a flaw already being exploited
  4. 11 Aug Microsoft ships around 400 fixes, one flaw already in use
  5. 12 Aug UK regulator reprimands ACRO over unread alerts
  6. 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 [1]. Then it left it off for nearly everyone.

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 [1]. A session cookie is the small token a website stores in your browser after you log in. It saves you re-entering your password on every page. It also proves, to that site, that you are already you.

That token has become the prize. Two-factor codes and passkeys made stealing a password much less useful [1]. So attackers stopped chasing passwords and started stealing the proof-of-login instead, using malware that scrapes browsers and fake login pages that sit in the middle of a real sign-in [1]. Paste the stolen cookie into your own browser and you get the same access the owner has.

Chrome’s answer is called device-bound session credentials [1]. The browser generates a secret key and stores it inside a small locked chip in your machine. On Windows that chip is the TPM; on Macs and iPhones it is the secure enclave [1]. The website then asks the browser to sign each session with that key. The chip will hand back an answer, but never the key itself.

“The attacker can steal the cookie, but they can’t answer a DBSC challenge,” researcher Scott Helme told Ars Technica [1]. The stolen token becomes useless.

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 [1]. It is unclear when other Chrome-based browsers will follow [1].

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 [3].

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 [2].

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 [2]. Separately, SpecterOps demonstrated a chain that impersonated privileged Microsoft accounts while still satisfying phishing-resistant two-factor checks [3]. An independent researcher showed malware in a signed-in Windows session using a hardware-backed Windows Hello key without prompting the user again [3].

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 [3]. A CVE is just a public catalogue number for a specific flaw. Microsoft says it has also applied mitigations for the passkey issue SpecterOps reported [3].

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 [4][6]; Brian Krebs counted at least 398, of which 42 were rated critical [5]. The gap is a counting convention, not a dispute. Krebs notes it is double June’s then-record batch, and that Microsoft attributes the surge to bugs now being found with the help of AI [5].

One flaw was already being used. CVE-2026-68820 sits in afd.sys, a core Windows networking driver [4][5]. It does not get an attacker in; it lets one who is already in become the administrator [5]. “This isn’t a front-door bug,” Automox’s Landon Miles wrote. “It’s step two in a chain” [5].

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 [7]. Check Point found the exploit built into a new version of the group’s kernel-level rootkit, which switches off security software’s reporting [7].

Elsewhere: Metabase patched a critical flaw already being exploited that handed unauthenticated attackers admin access to its analytics tool [16]. GeoServer has an unpatched flaw being probed within hours of disclosure, with hundreds of attempts logged and no fix yet available [17]. CISA, the US cyber-defence agency, told federal agencies to patch a Progress LoadMaster flaw scored 9.6 out of 10 that has been exploited since late June [18].

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 [8].

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 [8]. That data included names, dates of birth, National Insurance numbers, passport and driving licence details, bank details and criminal-record information [8]. Complaints came from people applying for child protection certificates and from domestic-violence victims [8].

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 [8]. The web supplier applied CMS patches, but was not responsible for spotting when they were needed [8]. ACRO itself did not monitor for them at all [8]. Nobody owned the gap.

The second failure is sharper. ACRO had security software installed, and it generated alerts. Those alerts were “not reviewed or acted upon” [8]. Had they been investigated at the time, the regulator said, further activity could likely have been prevented [8]. The intrusion was only discovered because ACRO happened to be investigating a different one, and it still cannot say whether the data was actually taken [9]. The regulator did note one thing ACRO had done right: the network was segmented, which limited how far the intruder could reach [8].

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 [11]. SOCRadar found that over 95% of affected companies were hit through a poisoned version of Trivy, a widely used security scanner [11]. The AI tool LiteLLM, which got the headlines, was downstream of it [11]. Its poisoned packages were online for roughly 40 minutes on 24 March [11]. They carried a file type that Python runs automatically at start-up, even if the package is never used [11]. That stepped around the setting developers turn on to block install scripts [11].

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 [12].

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 [10]. npm is the package library most JavaScript projects pull code from. ChainDrop does not need you to install anything [10]. It writes start-up hooks into repository config files, so simply opening an infected branch can trigger it [10]. It leaves little trace in the source [10].

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 [13][14]. The city shut its whole network, declared a state of emergency, and routed emergency calls through the county [13][14]. City hall closed [13].

Coweta, Oklahoma, population about 12,000, lost every computer and digital service to ransomware [13]. It has offsite backups to restore from, and has promised not to cut anyone’s water off while payments are down [13]. Mitchell, South Dakota, shut its networks after an attack the same week [13].

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 [19]. The likely way in was a flaw in N-central, a console thousands of IT providers use to manage client machines remotely [19]. Huntress described the flaw as giving unauthenticated “god-mode” access [19]. Microsoft has seen this group go from first foothold to full encryption in under a day [19].

And RingCentral, a business phone and messaging platform used by over 600,000 companies, had data on 1.6 million accounts exposed [15]. The extortion group ShinyHunters broke in during July through what RingCentral called a social engineering campaign, claimed 623GB of data, and leaked 280GB after the company refused to pay [15]. Have I Been Pwned confirmed the leak contains names, email addresses, phone numbers and physical addresses [15].

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 [20]. The operations could include surveillance and the disruption or destruction of criminals’ systems [20].

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 [20]. It is not clear which firms, if any, will sign up [20]. Former officials warn of legal exposure and escalation, and the memorandum does not address most of those concerns [20].

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

  1. A vendor ships a safety setting
  2. Changing it needs someone to know it exists
  3. Then to decide it matters
  4. Then to actually go and do it
  5. Almost nothing survives all three filters
  6. 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.

Across the beats