Cybersecurity · Saturday, 8 August 2026

01 · Briefing · what happened

The safest logins keep a back door open, and attackers keep finding it

Cybersecurity 2 min 10 sources

Researchers hijacked passkey-protected accounts, an admin flaw handed over remote-management consoles, and a guilty plea traced 100 million exposed records to logins with no second check. Three versions of one design trap.

100M

people exposed

Snowflake accounts had MFA switched off

3 days

federal patch deadline

CISA's window for the N-central flaw

165

organisations breached

in the 2024 Snowflake spree

8.2

CVSS severity

N-central unauthenticated admin flaw

At a glance

Researchers hijacked passkey-protected accounts without breaking the cryptography - they abused the sync and re-enrollment paths built for convenience.
The attack, Pass-ta-key, needs only ordinary malware on the PC: no fingerprint, no device unlock, no admin rights.
A separate N-central flaw hands unauthenticated attackers full admin access to remote-management consoles, and it is under active attack.
CISA gave federal agencies three days to patch it, and N-able confirmed attackers reached customer networks.
A guilty plea in the 2024 Snowflake breaches traced 100 million exposed records to accounts with no second login check.
One pattern connects all three: a login control that, when it cannot run its check, lets you in rather than locks you out.

Forces in play

Convenience pressure High→

logins must not lock out real users, so back doors stay open

Active exploitation High↑

N-central attacks reached customer networks this week

Defensive response Building↑

CISA deadline, second hotfix, mitigations shipped

Passwordless trust Building↓

passkeys still safer, but the halo cracked

In play Palo Alto Networks — disclosed the Pass-ta-key passkey attack N-able — confirmed attackers reached customer networks; pushed a second hotfix CISA — US cyber agency; set the three-day patch deadline Connor Moucka — pleaded guilty to the Snowflake breaches

How it unfolded

Jul 31 attackers begin exploiting the N-central admin flaw
Aug 2 N-able discloses it; CISA adds it to the must-patch list
Aug 6 Snowflake hacker pleads guilty; N-able ships a second hotfix
This week researchers reveal passkeys' fail-open convenience paths

Where this points

Watch whether Google's mitigations close the passkey re-enrollment window, and whether more provider consoles get pulled off the public internet after N-central.

Full briefing

Passkeys are the login that tech giants push hardest. They put a cryptographic key on your device to replace the password, and they are meant to shrug off phishing [1]. This week researchers at Palo Alto Networks showed how malware already on a Windows PC can hijack a passkey-protected Google account [1]. It needs no fingerprint check, no device unlock, and no admin rights [1].

The attack, named Pass-ta-key, does not break the cryptography. It abuses the convenience paths built in so real people are not locked out: Chrome’s cross-device sync and its device re-registration flow [1]. Malware reads the browser’s sync database and recovers a device-identity key [1]. It then signs Google’s login challenge itself, and the cloud service treats the request as a trusted device and waves it through [1]. A harsher variant registers the attacker’s own key during re-enrollment, so they can later log in from any machine [1]. Google was told and has shipped some fixes [1].

The same shape is being exploited right now. N-able confirmed that attackers used a critical flaw in N-central to reach customer networks [2]. N-central is the software many managed-service providers use to run thousands of client machines from one dashboard [2]. The flaw, CVE-2026-18577, hands unauthenticated attackers full administrative access, because the login check can simply be skipped [3][4]. CISA, the US cyber-defence agency, added it to its must-patch list and gave federal agencies three days [3][5]. N-able has pushed a second mandatory hotfix in a week and says a limited number of customers were hit [2][6].

A courtroom this week showed the bill for the oldest version of the trap. Connor Moucka pleaded guilty to the 2024 Snowflake breaches, which exposed records on at least 100 million people across 165 organisations [7][8]. There was no exploit and no platform flaw. The accounts simply had multi-factor authentication switched off, so a years-old stolen password was the whole front door [7].

One pattern connects all three. Take a passkey’s sync path, a console’s login check, an account’s optional second factor [1][2][7]. Each is a control that, when it cannot or does not run its check, lets you in rather than shutting you out. That default is a choice. Where a second check is offered, turn it on; if you run N-central, patch it now; and treat the convenience login as the thing worth guarding [7][3][1]. CISA has flagged a run of these bypass and skip-the-check flaws in a single fortnight [9][10].

02 · Lesson · why it matters

Every lock has to decide what happens when it breaks

A security check that fails has two ways to go, lock everyone out or let everyone in, and that quiet choice decides who gets breached.

How it works

A security control has to check who you are
But the check can fail - crash, time out, lose connection, or be skipped
The designer must pick a default: deny (fail-closed) or allow (fail-open)
Fail-closed is safe but can lock out real users and take systems down
Fail-open keeps things running, and hands attackers the door if they just break the check

The twist

You often cannot make a control purely fail-closed, because that would lock out real people - so the fail-open escape you keep for them is the same door the attacker walks through.

Where you've seen this

Building access

a badge reader that unlocks when it loses power saves you in a fire and lets anyone in

Payment fraud checks

if the risk engine times out, approving the charge keeps sales flowing and lets fraud through

Web filters

a filter that passes traffic when it errors avoids blocking work and lets the bad link land

Account recovery

the lost-my-phone path exists so you are not locked out forever, and it is the weakest link

The catch

Fail-open is not always wrong - a fire door must open when the power dies. The failure is choosing the default by accident instead of on purpose.

Full lesson

The moment the check can’t run

A passkey is meant to be the lock you cannot pick. The key never leaves your phone, and it takes your fingerprint to use. This week researchers showed a way in anyway. They did not break the key. They slipped through the paths built so you are not stranded when you lose your phone.

The same week, attackers reached company networks through a management console whose login check could simply be skipped. And a hacker pleaded guilty to a breach of 100 million people that needed no clever exploit at all, only accounts whose second check was switched off.

Three very different stories, one shared moment: a security check that, for one reason or another, did not run, and let the stranger through.

Two ways to fail

Every control faces the same question the first time it hiccups. The login server times out. The card reader loses power. The fingerprint sensor is unavailable. The rule engine crashes. In that instant the system has to do something, and there are only two doors.

Fail closed: when in doubt, deny. Lock the door, refuse the login, block the traffic. Safe against the attacker, and merciless to the real user standing outside in the rain.

Fail open: when in doubt, allow. Let the person in, wave the request through, keep the line moving. Kind to the real user, and a gift to whoever can make the check fail on purpose.

Most breaches are not a lock that was picked. They are a lock that quietly chose the second door.

Why “just fail closed” is a trap

The obvious answer is to always fail closed. It is also wrong, and the reason is people.

A purely fail-closed passkey would lock you out forever the day your phone falls in a lake. A purely fail-closed login server would freeze a whole company the moment it stutters. A fire door that failed closed would kill the people it was meant to protect. So designers keep an escape hatch: a recovery path, a fallback, an “if the check can’t run, let them through.” They keep it because the alternative, locking out the very people the system exists to serve, is its own kind of disaster.

The escape hatch is not a mistake. It is the price of a system that ordinary humans can actually use.

The escape hatch is the front door

Here is the turn. An attacker rarely beats the strong check head-on. They go looking for the escape hatch and break the check on purpose.

They do not forge your fingerprint; they trigger the “new device” path that skips it. They do not crack the admin password; they find the request that skips the password entirely. They do not defeat your second factor; they wait for an account where someone left it off. The convenience you were handed so you would not be locked out is the exact door they walk through. The stronger the front lock, the more the whole game moves to the side entrance.

You are already standing in this

If you use technology, you live inside this trade-off. Every “forgot my password,” every “trust this device,” every “skip for now” is a fail-open escape someone built so you would not be stranded. It makes your life work. It is also the softest part of your defence, and you did not choose where it sits.

The people who did choose, the engineers who set the default, were balancing your frustration against a stranger’s patience, usually under deadline, usually unseen. When a breach lands on a hundred million people, it is rarely because someone was reckless. It is because a hundred small “let them through, or we drown in support tickets” decisions all pointed the same way.

Seeing the whole

You cannot abolish the escape hatch. A lock that never yields is a lock nobody can live with. You can only decide, on purpose, where it sits and how narrow it is, and most of us never watch that decision being made on our behalf. The default was set upstream, by people we will never meet, weighing costs we never saw.

That is the humbling part. The safety of your accounts turns less on how strong your lock is than on how someone, long ago, chose to let it fail. Knowing that will not make you safe. It might make you slower to trust the word “unbreakable,” and a little kinder to the ones quietly holding a trade-off you never had to.

03 · Lab · your turn

Set the failure mode

Choose each control's fail-open or fail-closed default, then break the system and feel security and availability trade against each other.

04 · Hope · carry this

Every escape hatch an attacker slips through was first built to keep a real person from being locked out - the systems guarding us are, underneath, trying to be kind.