OpenSSH stops batching: 10.5 ships 36 days after 10.4, and the release notes say why

A cadence change, announced before the bugs

OpenSSH 10.5 was released on 2026-08-11, 36 days after OpenSSH 10.4 (2026-07-06) — which itself arrived 95 days after 10.3 (2026-04-02). The release notes explain the broken rhythm before they get to a single line of code, and the explanation is the most consequential thing in the file.

"Recently the OpenSSH team have received a large number of security bug reports, many of which are findings from AI models or made with AI assistance," the announcement says. It is not a complaint: "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."

The operative observation is the next paragraph. "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."

Given this, the OpenSSH team will, for now, be making more frequent releases to get bugfixes into users' hands more quickly rather than batching them until the next planned release.

OpenSSH 10.5 release notes, 2026-08-11

That is a release-engineering policy derived from a threat model, and it inverts the usual argument for batching. Batching exists because releases cost users something: packaging, testing, restarts. It only pays if the bugs sitting in the queue stay private while they wait. The team is saying that assumption no longer holds — if a class of bug is now cheap enough to find that two independent parties keep finding the same one, then time-in-queue is exposure, not prudence. Anyone downstream who plans OpenSSH upgrades on a quarterly cycle should expect that cycle to stop matching upstream.

Three fixes on three different boundaries

The three security entries are not variations on one theme; each one is a place where a restriction did not reach as far as its name implied.

The first is in ssh-agent(1), which now fixes "an interaction between agent locking and the session-bind@openssh.com extension that is used to identify forwarded agents. These binding requests were refused when the agent was locked, with the result that operations that were intended to be limited to local use only could be performed remotely, including the ability to add PKCS#11 tokens and make use of keys that had destination restrictions applied." The shape is worth sitting with: locking the agent — the defensive action — is what disabled the mechanism that tells the agent a request arrived over a forwarded channel. Destination restrictions (ssh -A with per-hop binding, the feature that made agent forwarding tolerable again) depend on that binding being present. Reported by sn0x-sharma.

The second is client-side memory safety: ssh(1) will "avoid potential realloc use-after-free in the client if a remote forwarding is added via the local session multiplexing socket while a remote forwarding open request is pending with the server." It needs a multiplexed control socket and a race between two forwarding operations — narrow, but it is the client process holding your keys. Report and fix from Brian Mingus of Cognatory.

The third is sshd(8): the release makes "the authorized_keys 'restrict' keyword apply correctly to tunnel forwarding too (which is administratively disabled by default)." The parenthetical is the mitigation. restrict is documented as the deny-everything baseline you add permissions back to, and tunnel forwarding was outside it — but tunnel devices require PermitTunnel to be enabled server-wide, which it is not by default. If you enable PermitTunnel and hand out restrict-prefixed keys, this one is yours. Reported by Erichen, Institute of Computing Technology, Chinese Academy of Sciences.

The change that lands on packagers, not admins

The single potentially-incompatible change is a build-time requirement: "Portable OpenSSH now requires ECC (Elliptic Curve Cryptography) support in libcrypto, including support for the NISTP521 curve." The notes immediately defuse it — "ECC is included in the default build configurations of all versions of all libcrypto implementations currently supported by OpenSSH, including LibreSSL, OpenSSL, BoringSSL and AWS LC" — and add that "The --without-openssl build configuration is not affected."

So this bites exactly one population: anyone building portable OpenSSH against a deliberately trimmed libcrypto, which in practice means embedded and hardened-distribution packagers who compiled ECC out. For everyone installing from a distribution package, it is invisible.

The rest of the file

Two of the bugfixes are pre-auth hardening credited to Christopher Paul Rohlf of Anthropic: sshd(8) now moves "check of public key type against allowed algorithms to before parsing of the key sent by the peer. This removes at least some key parsing and verification paths from the pre-auth attack surface," and ssh-keygen(1) gets fixes for "double frees (impossible to reach outside of a test harness)" plus wider use of freezero. Reordering the algorithm check ahead of the parse is the kind of change that produces no user-visible difference and shrinks the surface an unauthenticated peer can reach — which is the same economy of effort the cadence note is describing.

One regression is worth flagging for anyone who deployed 10.4 quickly: sshd(8) "fix GSSAPI option names, that were broken during a servconf.c refactoring in openssh-10.4; bz3974." Also fixed in this release: ChannelTimeout and RekeyLimit were not being applied inside sshd_config Match blocks — a silent policy gap if you scoped either directive per-user or per-address.

On the feature side, ssh(1) gains a diagnostic mode worth knowing about — ssh -Z user@host "prints the keys that will be tried for public key authentication in the order that they will be used" — and the client now orders certificate attempts to "prefer FIDO keys that do not require user presence (touch) first, and FIDO keys that require user verification via PIN or biometrics last," so the low-friction authenticator is tried before the one that makes you tap.

What to check this week

Upgrade normally; the fixes reach you through your distribution. Beyond that, three questions have concrete answers: do you rely on ssh-agent locking as a control while forwarding an agent (it was not the boundary you thought until 10.5); is PermitTunnel enabled anywhere alongside restrict keys; and did anything in your GSSAPI configuration quietly stop applying when 10.4 landed in July. And if your patch process assumes OpenSSH releases arrive on a predictable schedule, that assumption is the thing the release notes just retired.

Primary sources: OpenSSH 10.5 release notes, OpenSSH 10.4 release notes, OpenSSH 10.3 release notes, read 2026-08-14.