Locking the SSH agent disabled its own restrictions

There is a fairly common habit among those of us who administer servers: locking the SSH agent with ssh-add -x when you step away from the desk, and unlocking it when you come back. Sounds reasonable. On 11 August, OpenSSH released version 10.5, and one of its three security fixes says, in short, that with the agent locked, forwarding sessions were treated as local rather than remote.

Local and remote are not decorative labels inside the agent: they are exactly the boundary that decides what can be done with your keys. This post is about why it happened, who it actually affects, and about one detail we find more important than the bug itself: it got its CVE number the same day, it scores 3.5 out of 10, and with that score it lands on nobody's to-do list.

What the release note says

The OpenSSH text is short and worth reading in full before forming an opinion. On ssh-agent: "fix an interaction between agent locking and the [email protected] 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". Reported by sn0x-sharma.

The message of the commit that fixes it, dated 7 August, is even more direct than the note: "Allow [email protected] requests when the agent is locked, otherwise forwarding sessions established with an agent was locked will be treated as local, rather than remote". Four days later the release was out.

What marks "this came from outside"

To understand the effect you need one fact about the agent protocol that Damien Miller wrote down in 2022 and that is still the best summary of the problem: "A forwarded agent appears effectively identical to a local one, as (until now) the protocol offered no way to distinguish between them". That sentence comes from the document with which OpenSSH 8.9 (February 2022) introduced agent restrictions.

What 8.9 added was exactly that way of telling them apart. The ssh client sends a [email protected] message as the first message on every connection to the agent, and that message cryptographically links the SSH session identifier with the server's host key. With that chain of links, the agent can reconstruct the path a request travelled and enforce the destination constraints you attached to a key when adding it with ssh-add -h.

One honest caveat, because we do not want to oversell this: OpenSSH does not publish the exact exploitation sequence. The window you can infer from the fix is narrow — a forwarding session established while the agent was locked, used afterwards — and it matches the high attack complexity its own CVE record assigns. What is documented is the property that broke and the two consequences the project names: adding PKCS#11 tokens, and using keys with destination constraints from the far side of the forward.

Who this actually touches

For the bug to have consequences, three things have to line up:

That third point is the one we find most interesting for a small company with a jump host. OpenSSH's documentation has said since 2022 that "it is generally better for users to avoid the use of a forwarded agent altogether (e.g. using the ProxyJump directive)". Anyone who took that advice four years ago has nothing to review today. Anyone who set up forwarding and then added constraints to sleep better is precisely the profile this fix matters to.

The other two fixes, in proportion

The second is a use-after-free in the client, when a remote forwarding is added through the local multiplexing socket while a remote-open request is still pending with the server. Reported and fixed by Brian Mingus of Cognatory. The third fixes the fact that the restrict keyword in authorized_keys — the one you use to say "this key may do nothing beyond what I explicitly allow" — was not being applied to tunnel forwarding as well. Reported by Erichen, Institute of Computing Technology, Chinese Academy of Sciences.

OpenSSH itself adds in parentheses that tunnel forwarding is "administratively disabled by default", and that is a caveat worth respecting: if you never enabled PermitTunnel, that third bug opens nothing for you. We think that is a healthy way to document a bug, which is why we repeat it here instead of leading with all three at once.

One figure deserves to be called out separately: two of the three fixes are client-side (ssh-agent and ssh) and only one is server-side. Most patching inventories we come across point at servers. The laptop an administrator connects to everything from tends to update when its operating system decides, not when OpenSSH publishes.

They have numbers, and still nothing moves

All three bugs have had a CVE since 11 August: CVE-2026-73281 for the agent one, CVE-2026-73282 for the client one and CVE-2026-73283 for the restrict one. And their scores came with them: 3.5, 4.8 and 2.5 out of ten. None reaches "medium-high", the threshold most organisations — including the ones that hire us — use to sort what earns a maintenance window from what waits for the quarterly cycle.

The score is fair, and that is the interesting part. The vector for the agent bug says high attack complexity, local privileges required and no impact on confidentiality or availability: that is an honest 3.5. CVSS measures the damage done, and here the direct damage is small. What it does not measure, because it is not designed to, is that you have stopped having a control you believed you had. Your destination constraints do not break loudly: they simply stop being enforced.

And the other link in the chain is not sprinting either. Checking Debian's tracker today, the packaged OpenSSH version is 10.4p1-4 in sid (unstable), 10.0p1 in Debian 13 trixie and 9.2p1 in Debian 12 bookworm. Five days after the release, 10.5 has not even reached unstable. That is not a complaint: it is how a stable distribution works, and that unhurried pace is exactly why most of us prefer the distribution to do the updating. But it is worth knowing that the clock upstream and the clock downstream are not the same one, as we wrote this very morning about what apt will not tell you once Proxmox VE 8 goes out of support.

Debian has already made its call, too, and written it down. On the record for all three CVEs, the annotation for trixie is <no-dsa> (Minor issue): no dedicated security advisory, it will be fixed in due course. The state in unstable is (unfixed), tracked as Debian bug 1144192, and all four suites — from bullseye to sid — are listed as vulnerable. All of that is coherent and defensible from Debian's side; it is just worth reading in full before assuming that "it is in the tracker" means it will land on its own next week.

Why this release came thirty-six days later

Version 10.4 came out on 6 July and 10.5 on 11 August: thirty-six days. Between 10.3 and 10.4 there had been ninety-five, and between 10.2 and 10.3, one hundred and seventy-four. The project has shipped fast before when it had to — four days separated 10.1 from 10.2 — so what stands out is not the speed itself but that this time they explain it. The note puts it plainly: "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". And immediately after comes the caveat that usually gets trimmed off: "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".

The argument that settles it, though, is the one that follows: "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". Hence the more frequent releases, phrased with a caution worth respecting: for now they will release more often "to get bugfixes into users' hands more quickly rather than batching them until the next planned release".

What has changed there is exclusivity of discovery: if a tool anyone can run finds something, you have to assume somebody else with the same tool and less inclination to report it will find it too. It is the same arithmetic we discussed around how briefly vCenter's "no known exploitation" held up, and the reason we started looking seriously at what happens when the attacker automates their side of the work. A project that decides to release sooner is telling you it has recalculated its window. If your maintenance window is still quarterly, the gap between the two is on you.

What we are reviewing this week

What we are not going to do

The part that stays

What we take to the next customer review has little to do with this particular release. Restriction levers — locking, restrict, destination constraints — are code like everything else and they fail like everything else, with one difference: when they fail, nobody notices. Their job is for nothing to happen, and nothing happening looks a great deal like working. Since 2022 the agent's destination constraints had not produced a single visible problem; they would still not be producing one had sn0x-sharma not looked. Worth remembering, too, that Damien Miller introduced them at the time as an experimental set.

That is why we run access reviews by checking what a configuration permits today, rather than by reading what somebody wrote the day they set it up. In a well-built Zero Trust access model, every control earns trust only after it has been tested, starting with the one you bought precisely in order to relax.

Sources (verified on 16 August 2026): OpenSSH release notes for 10.5 (11 Aug 2026), 10.4 (6 Jul 2026), 10.3 (2 Apr 2026), 10.2 (10 Oct 2025), 10.1 (6 Oct 2025) and 8.9 (23 Feb 2022), the source of the three security fix texts, the paragraph on AI-assisted reports and the intervals between releases — openssh.com/releasenotes.html; commit message of the agent fix (7 Aug 2026, 6a57081dc3) in the openssh-portable repository; records for CVE-2026-73281, CVE-2026-73282 and CVE-2026-73283 at MITRE (published 11 Aug 2026, CVSS 3.1 scores of 3.5, 4.8 and 2.5); status, the <no-dsa> (Minor issue) annotation and bug 1144192 at security-tracker.debian.org, plus packaged versions at sources.debian.org; Damien Miller's "SSH agent restriction" document (last modified 10 Jan 2022) for how [email protected] and ssh-add -h work and for the ProxyJump recommendation — openssh.com/agent-restrict.html. The reading of the exploitation window, and of what CVSS does not measure, is ours and not the sources'.