OpenSSH releases are speeding up, and the maintainers say why in their own release notes. OpenSSH is the free, BSD-licensed SSH server and client that sits behind most remote Linux logins, and 10.6p2, published on November 5, carries a paragraph about “a large number of security bug reports, many of which are findings from AI models or made with AI assistance.” Because the same bug keeps being found twice, they say they will “for now” ship fixes sooner “rather than batching them until the next planned release.”
I counted the schedule change from the release-notes page, diffed the 10.6p2 tarballs against 10.6p1, and wrote the checks a small team can run. My position: faster releases are the price of AI-found bugs, and you pay it by patching on a schedule, not by reading a scary headline once a quarter.
What the OpenSSH release notes say about AI bug reports
The release notes page is the primary source here, so I read it live this morning. 10.6p2 is still the newest entry. The paragraph is not new to 10.6p2. It sits at the top of the 10.5 notes (August 11), the 10.6 notes (October 6) and 10.6p2, and it is absent from 10.4 (July 6) and 10.3 (April 2).
Two things in it matter. First: “While many AI reports are determined not to have security impact when considered in the context of a realistic threat model, we very much welcome these reports, especially when combined with human triage, analysis, test-cases and particularly when accompanied by proposed fixes.” That is a maintainer team saying many AI reports turn out harmless in practice, and that the useful ones come with a patch.
Second, the reasoning for the schedule change: “We have seen a number of cases where a security bug identified by AI tools is subsequently independently discovered by a different researcher. This suggests that adversaries who do not report bugs to OSS projects are likely to be able to discover these bugs too.”
The 10.6p2 bug itself came out of that kind of work. The finder’s page, sshhole.com, says he built sshd every way he could think of, “threw like 17,600 weird logins at it”, and adds: “i had agent swarms. a lot of them.” The 10.6 notes also credit a Security bullet to “Chris Rohlf in collaboration with Claude and Anthropic Research”. If unrelated people find the same bug with a model, a third who never emails the project probably did too, and waiting for the next planned release hands that person weeks.
How much faster OpenSSH releases now come
Claims like “ships faster” are cheap, so I counted. From the dates on that same page, the last ten releases are 9.9 (2024-09-19), 9.9p2 (2025-02-18), 10.0 (2025-04-09), 10.1 (2025-10-06), 10.2 (2025-10-10), 10.3 (2026-04-02), 10.4 (2026-07-06), 10.5 (2026-08-11), 10.6 (2026-10-06) and 10.6p2 (2026-11-05).
The nine gaps in days, newest first: 30, 56, 36, 95, then 174, 4, 180, 50, and 152 for the oldest.
- Last four gaps: median 46 days.
- The four before that: median 112 days.
That is under half the wait. Nine gaps is a small sample and the notes themselves say “for now”, so I would not plan around 46 days as a law. I would plan around “more often than quarterly”.
I also counted the bullets under each release’s Security heading, because a faster rhythm only matters if something is in the box. The counts from 10.3 on are 5, 8, 3, 11 and 1. That is 28 security items in five releases. The same rule over the five releases before 10.3 gives 0, 2, 1, 1 and 0, which is 4 in all, and the one in 10.6p2 is the one the maintainers called critical.
What the 10.6p2 fix changes in the source
The fix is small. I pulled openssh-10.6p1.tar.gz and openssh-10.6p2.tar.gz from the OpenBSD CDN, using the same file names as the release. Both the SHA-1 and the base64 SHA-256 of the 10.6p2 file match the checksums on the release-notes page.
Then I ran diff -ruN on the two unpacked trees. The result: 16 files changed, 60 lines added and 37 removed. Six of the files are packaging, CI or version strings, and ten are C sources. The password bypass lives in auth-passwd.c, which now refuses to accept a login when the stored hash for the account is shorter than four characters, through a new constant, MIN_PASSWORD_HASH_LEN.
Why four characters? The finder’s own write-up, on sshhole.com, explains it. On musl, the C library under Alpine, crypt() returns a single when it fails, and it fails on a password longer than 256 bytes. An account stored as has the same character as the failure value, strcmp says they match, and the login succeeds. Accounts stored as ! do not collide. The notes credit the report to Özgün Kültekin of Wakefield and say the root cause is “outside sshd”. In the Hacker News thread a commenter points out that POSIX says crypt() should return null on failure and musl does not.
The notes limit the scope to Linux systems on musl with PAM disabled, so Debian, Ubuntu and Fedora on glibc with PAM sit outside it.
What to do about the SSH boxes you run
Bon. Here is the short version for a small team with six servers, a few containers and one forgotten router.
First, know what you run. On each box:
ssh -V
sshd -T | grep -iE '^(passwordauthentication|usepam)'
ldd "$(command -v sshd)" 2>&1 | grep -i muslThe first line prints the version, the second shows whether password logins and PAM are on, and the third prints a line only if sshd links against musl. Debian and Ubuntu backport fixes without changing the version string, so on those two do not compare against 10.6p2; read the package changelog for the CVE or the fix instead.
Second, you are exposed only if all four hold: musl, no PAM (UsePAM no), password logins on, and an account stored as beside accounts with a real hash. Check the last one with sudo awk -F: '$2==""{print $1}' /etc/shadow. If all four are true, turn passwords off, the quick fix one commenter gives in the thread. Lockout guard first: confirm a key login works in a second terminal and keep your current session open. Then set PasswordAuthentication no and update to 10.6p2. Alpine’s package page shows 10.6_p2 on edge only; the newest stable, v3.24, ships 10.3_p1-r2.
Third, stop treating the security page as your alert. The OpenSSH security page lists its newest advisory as April 9, 2025, and a commenter in that thread noticed the “critical” release was not listed there either. The release notes are where fixes now appear first. A weekly cron job is enough. The page heading carries the version as an anchor id, so this prints the newest one:
curl -s https://www.openssh.org/releasenotes.html | grep -m1 -oE "]*id='[^']+'" | grep -oE "id='[^']+'"
I ran it today and it printed id='10.6p2'. Store the answer, compare it to last week’s, and mail yourself when it changes.
Fourth, shrink what is reachable. One commenter on that thread puts servers inside a WireGuard network and allows SSH only from inside it, and I agree. In five months of my own web logs I counted 171,555 credential probes, and those were only web requests, not SSH. A fix that lands in days is worthless if your boxes sit open for weeks before anyone runs apt upgrade.
What a faster release rhythm costs you
The cost is yours, not the maintainers’. A project that releases every 30 to 50 days instead of every 112 asks its users to take a patch about every five to seven weeks, per box, forever. For a team without a patching routine, that is the real change in this story, and no tool fixes it for you.
Me, I would automate the boring half: staging first, production a day later, one chat line when the version changes.
The number I will keep watching is the next gap. If 10.6p2 is followed by another release in under 46 days, the median is moving the way the notes say. If the next one takes 95 days, the “for now” ran out. The release page will tell us either way, and I will count again.
