*sshole: The Decade-Old OpenSSH Bug AI Agents Found and Attackers Used Within Hours

On Thursday, November 5, the people who maintain OpenSSH shipped a release to fix a bug with a name you can’t say on the radio.

OpenSSH is the program that answers when someone types ssh at a server. It’s the most widely used SSH server in the world, and it runs on a lot of things that don’t look like servers: routers, cameras, medical devices, the build runners in your CI, and the little boxes some startups ship to their customers’ data centers.

The bug works like this. On Linux, a single asterisk in an account’s password field means that account can never log in with a password. It’s how administrators lock root, service accounts and anyone who should only use keys. On systems built with musl, a small C library used by Alpine Linux and a lot of embedded Linux, the function that hashes passwords gives up on passwords longer than 256 bytes and returns, of all things, an asterisk. And since 2016, OpenSSH has run that hashing step even for accounts that can’t log in, so attackers can’t tell real accounts from fake ones by timing the answer. Put those three facts together and send a password between 257 and 1,024 characters long. OpenSSH compares an asterisk to an asterisk, finds them equal, and lets you in.

Özgün Kültekin, the researcher at Wakefield who found it, named it *sshole, for the asterisk at the center of the bug. It’s tracked as CVE-2026-123158 and rated 8.1 out of 10. OpenSSH fixed it in version 10.6p2 (oss-security), and Alpine Linux published patched packages for every branch back to 3.16 the same day (iTnews).

Then the clock started. Exploit code was public about four hours after the fix (BleepingComputer). The threat intelligence firm Previdian saw its first exploitation attempt “less than nine hours after CVE publication,” in the words of its founder, Ryan Dewhurst, and confirmed that an attacker had taken root on one of its Alpine honeypots (Help Net Security). GreyNoise recorded the first successful attack against a real network at 00:46 UTC on November 7, about 40 hours after the fix, and then watched attackers read password hashes, try to plant SSH keys and install a Python remote-control agent (BleepingComputer).

Here’s the part we keep thinking about. The bug sat quietly in one of the most reviewed programs on earth for ten years. It was found in days, by one researcher who describes his method on sshhole.com, in his own lowercase, as “i had agent swarms. a lot of them.”

Jon has a line he’s been saying to founders all year:

*sshole is that sentence written as a security incident. A ten-year-old bug was always going to be found by someone. In 2026 it was found by a person with a swarm of agents, fixed by maintainers within days, and used by attackers within hours. Every step that used to take months took a day. This post is about what that means for a founder who runs a company on top of software like this, which is every founder.

The short answer

*sshole (CVE-2026-123158) is an OpenSSH authentication bypass. On Linux built with musl and without PAM, it lets anyone who can reach the SSH port log in to accounts that were locked with an asterisk, by sending a password of 257 to 1,024 characters. It was introduced in 2016, found in late October or early November 2026 with the help of AI agent swarms, fixed in OpenSSH 10.6p2 on November 5, and exploited in the wild within two days.

If you run a typical startup stack on Ubuntu, Debian or Amazon Linux, you’re not affected by the bug itself. You are affected by what it showed. The short version of what to do:

1. Check for musl plus OpenSSH: Alpine-based machines, images and devices that run sshd. Patch to 10.6p2 and restart sshd.
2. Turn password logins off anywhere you don’t need them, with PasswordAuthentication no. That closes *sshole on its own.
3. Take SSH off the public internet. Reach machines through a bastion or identity-aware access, with keys or certificates.
4. Read your logs for password logins on accounts that should never accept one.
5. Measure your patch clock in hours for anything internet-facing, because attackers now measure theirs in hours.
6. Make your own security checks fail closed, so an error never means yes.
7. Write the one-sentence answer your enterprise customers will ask for, and send it before they ask.

The rest of this post explains how a lock that meant “never” came to mean “yes,” what the AI side of the story actually was, why the speed is good news once you adjust to it, and how to measure your own response against the clock attackers ran this week.

How a locked door learned to say yes

We like this bug because no single person made a mistake. Three reasonable decisions, made years apart by different people for good reasons, met in one function.

1980: the asterisk. BSD’s password file used an asterisk for the daemon account, a value no password hash could ever match, and the convention stuck. In Linux’s shadow password file today, * (or !) in the hash field means the account can’t log in with a password at all. It’s standard hardening. When Alpine changed how it locks its root account in version 3.16 in 2022, it moved to an asterisk (sshhole.com).

2012: musl’s error value. The C standard function crypt() turns a password and a salt into a hash. The old specification said it returns nothing, a null pointer, when it fails. Plenty of programs never checked for that and crashed, so musl chose to return a string that could never match a real hash instead: an asterisk. Three weeks later musl added SHA-512 password hashing with a 256-byte limit on the password, which keeps enormous inputs from burning a server’s processor. Longer passwords fail, and failure returns an asterisk (sshhole.com, citing musl’s own commits).

2016: OpenSSH’s timing fix. Researcher Eddie Harari noticed that OpenSSH answered faster for accounts that didn’t exist, because it skipped the expensive hashing step, and that a very long password made the difference easy to measure. That leak, CVE-2016-6210, let attackers list valid usernames. OpenSSH fixed it by hashing every password attempt, including attempts on accounts that can’t log in, borrowing a salt from a real account so the timing looks the same (iTnews).

Each decision is defensible on its own. Together, on a musl system with password logins on and no PAM in the way, the hashing step for a locked account fails on a long password and returns *. OpenSSH compares that to the * in the shadow file. They match.

There are a couple of details that matter if you run these systems. The attacker needs to know the name of a locked account, which is easy for root or the default alpine user, and the machine needs at least one other account with a real password, because that’s where OpenSSH borrows its salt. Medcrypt’s Daniel Beard, who reproduced the bug on a stock Yocto image, found that the first attempt in a connection fails and the second succeeds, which is why lowering MaxAuthTries to 1 blocks it. He calls that setting “a tourniquet, not a fix” (Medcrypt).

The fix in 10.6p2 is three small changes, any one of which would have been enough: OpenSSH now copies the shadow entry instead of pointing into the C library’s buffer, rejects password hashes shorter than four characters before running any crypto, and copies the salt it borrows (Medcrypt). The release notes put it plainly: the root cause is outside sshd, but sshd can avoid being exploited through it (oss-security).

If you’d like to see it happen on a real terminal, two independent walkthroughs went up within days:

Found by a swarm

The AI part of this story is easy to exaggerate, so here’s exactly what’s on the record.

Kültekin’s write-up on sshhole.com describes the method in one breath. He built OpenSSH in many configurations, with glibc and with musl, with PAM and without it, with shadow passwords and without, “and threw like 17,600 weird logins at it.” Only one setup disagreed with the rest: musl without PAM accepted logins the others refused. Then the line that got the most attention: “i had agent swarms. a lot of them. let’s not get into it.”

That’s a technique called differential testing, and it’s old. You run the same inputs through several implementations that should behave identically, and you study the places where they don’t. What’s new is the cost. Building a dozen variants of a C program, writing thousands of strange inputs, running them and sorting the disagreements used to be weeks of a specialist’s time. With a swarm of agents doing the building, the running and the first pass of sorting, it’s a few days for one curious person. His explanation for why nobody found it sooner is just as plain: “openssh tests on openbsd and glibc, musl doesn’t test sshd,” and most distributions route passwords through PAM, which never calls crypt() on an asterisk at all.

The other detail on his page is the one we’d underline. On October 30, OpenSSH’s maintainer Damien Miller committed a fix to pick_salt(), the function that borrows a salt for those fake hashing runs. The commit corrected how fake salts handle bcrypt hashes, and its message carries a reference to an Anthropic report (openssh-commits). The commit doesn’t say how that report was produced. Anthropic has been pointing its Claude Mythos Preview model at critical open-source code with partners since April, as part of Project Glasswing (eWeek). Kültekin’s summary: “a security review fixes pick_salt(). the bug is four lines below it.” He found it four days later.

We don’t read that as a story about one review missing something. Reviews always miss things, which is why there’s more than one of them. We read it as a picture of the year. Defenders’ AI was reading this code. A researcher’s AI was testing it from a different angle. Each found something real within days of the other, in code that had been stable for a decade.

The numbers behind that picture are large. By its May 22 update, Anthropic said Mythos Preview had scanned more than 1,000 open-source projects and produced 23,019 candidate findings, with 1,726 confirmed valid, 1,596 disclosures to maintainers across 281 projects, and 97 upstream patches so far. Anthropic also warned that “patched upstream” doesn’t mean the fix has reached the people running the software (eWeek). Discovery got fast. Everything after discovery is still made of people.

The Hacker News thread on sshhole.com passed 2,900 points, which is rare air for a vulnerability write-up. One of the most useful comments in it wasn’t about AI’s brilliance at all:

"I think everyone is over fixated on AI finding complex bugs beyond a typical person's understanding either to locate or exploit. I think for any one of those bugs there might simply be half a dozen footguns or bugs that once it's spelled out you wonder how anyone let it slide."

rustyhancock, commenting on sshole, November 2026

That’s our read too. *sshole is a footgun that three sets of defaults loaded together, and AI made it cheap to point a light at the corner where they met. There are more corners like it, in your stack as well as in OpenSSH.

Exploited before lunch

The attacker side of the week moved even faster, and it’s worth looking at the order of events, because it’s the order your own week will follow next time.

OpenSSH 10.6p2 and the advisory went out on November 5. Exploit code followed about four hours later. Previdian’s first attempt arrived less than nine hours after the CVE was published, from a single address in Japan that sent oversized passwords and then ran id, uname and hostname to see where it had landed. Previdian later confirmed root on one of its Alpine honeypots, and by November 8 it had counted 20 attempts from 13 addresses in nine countries (The Hacker News).

Dewhurst’s explanation for the speed is the honest one. Attackers are getting faster with AI, and in this case: “This vulnerability was particularly trivial to exploit, which significantly shrunk that timeline” (Help Net Security).

GreyNoise recorded 16 successful exploitation chains against networks it protects, from six source addresses. The attackers looked around the system and its containers, queried cloud metadata services, tried to read password hashes and root’s SSH keys, and tried to change authorized_keys files so they could come back. One gained root and installed a Python command-and-control agent with comments and error messages in Chinese, then configured a startup service so it would survive a reboot. Its server never answered, so it never received a task (BleepingComputer). The firm watchTowr tied other exploitation to botnets and crypto mining. The Finnish firm Defused saw “a small amount of actors,” which is the reassuring part: the first wave was narrow because the vulnerable population is narrow.

Damien Miller’s advice to administrators, posted on Mastodon, is the best one-line incident response we’ve read this year: “stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY” (Help Net Security).

Jon described this shift on episode 105 a month before *sshole, with a metaphor he’s been using for years:

Listen · Jon on episode 105, from 9:27

The weather this week was a storm with a target list. It found the machines that matched, in about a day.

Why shorter is good news

It would be easy to read the last two sections and feel tired. Plenty of people did. The most human comment in the Hacker News thread came from someone who’d had enough:

"This is a super duper annoying site for people who just want to know if their systems are vulnerable, after patching like a dozen critical vulnerabilities in other software over the last week and are almost at the breaking point of resigning."

oefrha, commenting on sshole, November 2026

If that’s you, or someone on your team, it’s worth saying out loud: the fatigue is real, and it isn’t a character flaw. The volume of critical fixes this autumn has been unusual. The answer isn’t more heroics from the same two people. It’s systems that make the next patch boring.

But we’d push back, gently, on the idea that the speed itself is the problem. Go back to Jon’s line. Everything that was going to happen is still going to happen. The *sshole bug existed whether or not anyone found it. For ten years, anyone who happened across it could have used it quietly against routers, appliances and cloud images, and nobody would have known. Had it been found in 2036 instead, the world would have had ten more years of a door that opened for the wrong people.

What changed in 2026 is that the time between “the flaw exists” and “everyone knows and it’s fixed” collapsed. That’s painful for a week. It’s also how old debt gets paid: by people paying attention, while they’re paying attention, with tools that didn’t exist two years ago. Sasha made the point on episode 97 that there’s no such thing as a finished system:

Listen · Sasha on episode 97, from 27:03

So the useful question isn’t how to stop the clock. It’s how to be the kind of company that’s comfortable when it runs fast. Suha Can, who was Grammarly’s chief information security officer when we recorded and now runs security at DoorDash, told us about the hardest version of that he’s lived through, at the Microsoft Security Response Center in 2017, when the Shadow Brokers dumped a set of stolen exploits on the internet:

Listen · Suha Can on episode 52, from 32:55

The fix existed months before WannaCry. The damage happened anyway, in the window between “patched upstream” and “patched where it runs.” That window is the one founders control.

Where *sshole hides in a startup

Most startups we work with run their cloud servers on Ubuntu, Debian or Amazon Linux, which use glibc and aren’t affected. So “are we vulnerable to *sshole?” usually has a quick answer. The more interesting exercise is looking for the places musl and OpenSSH hide, because they’re the places nobody thinks of as servers.

Containers built to accept SSH. Most Alpine containers don’t run sshd at all, and teams reach them with docker exec or kubectl. One commenter in the Hacker News thread put the common case well: “Many, many Docker containers rely on ‘docker exec’ or the kubectl equivalent to gain CLI access when needed.” The exceptions are the containers someone built on purpose to accept SSH: development boxes, SFTP drop points for customers, CI runners, and the sandboxes AI coding agents work in.

Alpine cloud images. Alpine’s official images for AWS and Azure ship a default alpine user with no password who can become root with doas and no password, on tiny-cloud images 3.18.11 through 3.24.3 according to SOCRadar (Help Net Security). If anyone on your team launched a small Alpine instance for a quick job and left SSH open, that instance was one long password away from root.

Jump hosts and bastions. A tiny Alpine machine is a popular choice for a bastion precisely because it’s small. If it accepts passwords, it was the front door.

Devices. OpenWrt routers that swapped Dropbear for OpenSSH, and anything built with Buildroot or Yocto, can meet every condition (iTnews). Medcrypt makes the uncomfortable point for hardware founders: locking service accounts with an asterisk is standard hardening, so the better-hardened devices can be the more exposed ones (Medcrypt). Jon raised the same blind spot with Jim LaRoe of Symphion on episode 94, about printers that sit on the network for years: “They have to stay online. That means, like, SSH is on there.”

The box you ship to customers. This is the one we’d lose sleep over. If your product includes an on-premises appliance, an edge device or a virtual appliance built on Alpine or Yocto, with OpenSSH for support access, then you’re not the one patching. You’re the vendor. Your customers are waiting for your advisory, your fixed image and your instructions, and their security teams are asking their own vendors, including you, the same question this week.

If you want to check a machine you own, these four commands answer most of the question. They read configuration and logs and change nothing.

cat /etc/os-release | head -2                        # Alpine, OpenWrt, or another musl system?
sshd -T | grep -iE 'passwordauthentication|usepam'   # password logins on, PAM off?
awk -F: '$2=="*" {print $1}' /etc/shadow             # accounts locked with an asterisk (needs root)
grep 'Accepted password for' /var/log/messages       # any password logins at all? (Alpine's default log)

If the system is musl-based, password authentication is on, PAM is off and an asterisk-locked account exists, treat it as affected until it runs 10.6p2 and sshd has restarted. Alpine’s own wording for the last step is worth keeping: “If you cannot rule out a login, treat the machine as compromised” (The Hacker News).

The patch promise in your contracts

This is where *sshole reaches founders who don’t run a single Alpine machine.

If you’ve closed an enterprise deal, there’s a good chance you’ve signed something that promises how fast you fix vulnerabilities. The security exhibit, the data processing agreement or the questionnaire answer usually says some version of “critical vulnerabilities remediated within 30 days.” Card payment rules say the same: PCI DSS requirement 6.3.3 asks for critical patches within one month of release (PCI Security Standards Council). The U.S. government’s own rule for its agencies gives them two weeks to fix vulnerabilities on its known-exploited list (CISA).

Thirty days was a reasonable promise when exploits took weeks to appear. This week the first confirmed attack on a real network arrived about 40 hours after the fix. A 30-day promise is still a promise you can keep. It just isn’t the promise that matters anymore for anything facing the internet.

Travis McPeak, who worked on security at Netflix and led product security at Databricks before co-founding Resourcely, told us on episode 68 what he’d do when a company promises a patch window it can’t meet:

Listen · Travis on episode 68, from 10:59

That’s the right instinct, and *sshole gives it a new shape. Enterprise security teams spent this week asking every vendor some version of “were you affected, and when did you close it?” The vendors who answered in hours, with specifics, earned something you can’t buy: the buyer’s belief that they’ll do it again. The ones who answered “we’re looking into it” a week later spent some of that belief. We’ve written about the distance between promises and practice before, in the security exhibit your startup signed last quarter and Enabled Isn’t Enforced. A patch window is the same kind of promise, and *sshole was a live audit of it.

The practical move is to split the promise in two. Keep the 30-day window for the long tail of findings. Add a much shorter one, measured in hours, for critical vulnerabilities in internet-facing systems that are being exploited, and build the plumbing to meet it: an inventory that tells you within minutes whether you run the affected thing, a way to push a configuration change to every machine at once, and a habit of restarting and verifying rather than assuming.

Fail closed: the lesson in your own code

There’s a deeper principle in *sshole that has nothing to do with OpenSSH, and it’s the one we’d most like founders to take back to their engineering teams.

The bug is a fail-open bug. A security check couldn’t finish, because the password was too long to hash, and the failure value happened to look like the value for “locked.” When the check failed, the lock opened. Retr0id, in the thread, answered the argument that a downstream check would have caught it: “that’s not a perfectly valid argument, and it never was.”

Every startup has code with the same shape. We find some version of it in most penetration tests we run:

• Authorization middleware that allows a request when the policy service times out, because someone didn’t want an outage to lock customers out.
• Rate limiters that stop limiting when their cache is unreachable.
• Webhook signature checks that skip verification when the header is missing, so old integrations keep working.
• Feature flags that default to “on” for a security control when the flag service is down.
• AI guardrails that pass content through when the classifier errors or takes too long, which is the newest version and the most common one we see this year.

Each of those decisions is made for a good reason, usually availability, by someone who had a deadline. Each one turns an error into a yes. The fix is a design rule, not a patch: when a security check can’t reach a verdict, the answer is no, and the system says so loudly. If an outage would lock customers out, that’s a reason to make the check more reliable, not a reason to let errors through.

This is also the most AI-proof habit you can build. Agents that throw 17,600 strange inputs at your login page, your API or your model are looking for exactly the input that makes a check fail, and then for what happens next. A system that fails closed gives them nothing.

Time your own exploit clock

This clock asks five questions about how your team handles a critical vulnerability in something that faces the internet, and lays your timeline next to the one attackers ran against *sshole this week. It takes about two minutes, runs entirely in your browser, and ends with the one sentence you can send a customer who asks.

Interactive · 2 minutes · Runs in your browser

The exploit clock

Pick what's true today for an internet-facing system, not what the policy says. The clock updates as you go.

The clock needs JavaScript. The five questions are: how you hear about a critical vulnerability, how fast you know whether you're affected, whether you can contain it before a fix, how fast a fix goes live, and whether you restart and verify.

Load an example startup Start over

…until you're closed

…where you'd have been

…exposed after the first attack

…your slowest step

Copy the result Download (.md) Print

Everything here runs in your browser and is saved only in this browser. The attacker timeline uses the public reporting cited in this post. Your timeline is an estimate from your answers, not a measurement, and the right windows for your company depend on what you run and what you've promised.

Have an operator shorten your clock →

We get your email, the option you picked for each question and your result, nothing else. Jon or Sasha replies to set up a short review of how you handle critical fixes. No sequence.

What to do this week

If you only have an hour, do the first three. If you have a day, do all seven.

1. Turn off password logins everywhere you can. Set PasswordAuthentication no and restart sshd on every machine that only needs key logins, which should be nearly all of them. It closes *sshole on its own, and it closes the next password bug before anyone finds it.
2. Patch the musl machines and restart. Upgrade to OpenSSH 10.6p2 or your distribution’s fixed package and restart sshd. Help Net Security’s reminder is the step people skip: installing the update doesn’t restart the daemon, so the old binary keeps accepting connections.
3. Read the logs. Look for Accepted password for on accounts that should never accept a password, and for new users, new authorized_keys entries, doas or sudo use and unfamiliar startup services. If you can’t rule out a login, rebuild the machine.
4. Take SSH off the internet. Put machines behind a bastion, a VPN or identity-aware access, with keys or short-lived certificates tied to a person. Avery Pennarun described Tailscale’s version of this on episode 42 as something that “bypasses the need for SSH keys, authenticates using your Tailscale identity.” Whatever tool you choose, the principle is the same: no password prompt waiting on the public internet.
5. Build the inventory you wished you’d had on Thursday. Which base images, cloud images, runners and devices run OpenSSH, on which C library, with which settings. The next advisory will name a different program, and the hour you spend now turns a day of digging into a minute of searching.
6. If you ship a device or appliance, act like a vendor. Publish an advisory, ship a fixed image, tell customers exactly how to check and what to change, and keep a software bill of materials so the next question is answered by a lookup. Medical device makers have regulators asking for exactly this.
7. Find your fail-open checks. Ask your engineers to list every security check that allows the action when it errors or times out, starting with authorization, webhooks and AI guardrails. Flip the defaults, one at a time, and watch what breaks.

If you’d like a second set of hands on any of that, it’s the kind of week our monitoring and response and vulnerability remediation teams are built for.

Pick up the same tools

There’s one more line Jon uses with founders, and it fits the second half of this story:

*sshole is the good version, mostly. A researcher picked up agent swarms and found a decade-old bug. Maintainers were already fixing an Anthropic report four lines away. Attackers turned the published fix into working exploit code in about four hours. The only people this story leaves behind are the ones still running the old clock: annual penetration tests, monthly patch windows, and an inventory that lives in someone’s head.

The defenders’ version of Kültekin’s method is available to any startup now. Differential testing, fuzzing and agent-driven testing of your own login flows, APIs and models can find your fail-open checks before someone else’s swarm does. We wrote about how buyers now judge that kind of testing in Pentest Once a Year?, about what AI-driven testing does well and badly in AI penetration testing, and about what attackers’ agents already do in AI Cyberattacks Are Going Autonomous. If something does get in, the blast radius playbook is how you keep one machine from becoming the company.

Turn it into an answer buyers trust

Your enterprise customers’ security teams asked their vendors about *sshole this week, or they will at your next renewal. The answer that builds trust is short, specific and dated. Once it’s true, it sounds like this:

Sasha wrote up how to build sentences like that one, and what evidence to attach, in The 10 AI Security Questions Your First Enterprise Buyer Will Ask in 2027. If your board asked about *sshole, the patch window belongs on the security slide next to the other numbers you report.

Wednesday’s post takes the same lens to the Binance hack, the largest crypto theft on record, and the twenty minutes after a fake job interview. We’ll also be in Austin next April for MicroConf US, where YSecurity is a sponsor and our talk is “How Founders Turn Security Commitments Into Revenue.” It’s on our events page.

A lock that opens when its check fails was a quiet assumption in a lot of software for a long time. This week a researcher with a swarm of agents found one of them, the maintainers fixed it within days, and the attackers proved within hours that the old patch calendar is over. That’s the world getting faster, and we think it’s a better one. Find your own asterisks while it’s your swarm doing the looking.

Jon and Sasha