OpenSSH 10.6's notes cite no CVEs, yet MITRE issued 11 within 12 hours; none is for the post-quantum key

The notes cite no CVE. CVE.org holds 11 for the release

The OpenSSH 10.6 release notes, dated 6 October 2026, run to 48 entries under six headings. Eleven are under Security, and no CVE identifier appears anywhere in them. CVE.org holds 11 records for the release, all assigned by the MITRE CVE Numbering Authority and published between 20:20 and 23:42 UTC on 6 October. That is 8 hours 9 minutes to 11 hours 31 minutes after the maintainers' announcement to the oss-security mailing list at 12:11 UTC (computed from the list's timestamp and each record's publication time). Matched by description, every security entry has exactly one CVE.

Help Net Security led with a different fact: that 10.6 enables a post-quantum signature algorithm, so experimental keys need replacing. That is true. None of the 11 CVEs concerns the new key type.

What the 11 records do not establish, as read between 11:12 and 11:40 BST on 7 October 2026:

• Exploitation. CISA's Known Exploited Vulnerabilities (KEV) catalogue, version 2026.10.04, released 4 October at 18:52 UTC, has no OpenSSH entry. That describes one catalogue version, not the world, and the CISA-ADP exploitation assessment is not yet attached to any of the 11.
• Low severity. The only scores are MITRE's, 2.2 to 6.5 on CVSS v3.1. NVD lists all 11 as Received, not analysed, with no score of its own. For the 12 CVEs of OpenSSH 10.3 and 10.4 that carry both scores, NVD's was higher than MITRE's in 11 and equal in one.
• AI discovery. The notes credit an AI model by name in 2 of 48 entries and say nothing about where the other reports came from.
• Any effect of the post-quantum signature. A signature authenticates a host or a user. It does not protect the confidentiality of a session, which is the recorded-traffic risk and is already covered by the hybrid key exchange.

What the maintainers state about AI-found reports, and what they do not

The paragraph about AI in the 10.6 notes is word for word the paragraph in the 10.5 notes of 11 August 2026: 873 characters in each once the emphasis marks are removed, checked by script. It is 56 days old, not new in 10.6. Table 1 sets it beside what it leaves out.

Table 1. What the OpenSSH 10.6 notes of 6 October 2026 say about AI-found reports and release cadence, and what they leave out. Quotes are from the notes; the paragraph is identical in the 10.5 notes.

1. Topic

   Volume

   Stated in the notes

   A "large number of security bug reports, many of which are findings from AI models or made with AI assistance"

   Not stated

   How many reports, how many from AI, how many were valid, over what period

2. Topic

   Impact

   Stated in the notes

   "many AI reports are determined not to have security impact" in a realistic threat model

   Not stated

   Which reports, or what share. The entries that did matter are not marked

3. Topic

   Rediscovery

   Stated in the notes

   In "a number of cases" a bug found by AI tools was later found independently by a different researcher

   Not stated

   How many, which fixes, how long between the two finds, whether anyone else exploited one

4. Topic

   Adversaries

   Stated in the notes

   This "suggests" that adversaries who do not report bugs "are likely to be able to discover these bugs too"

   Not stated

   Any observed exploitation. The notes give none and KEV lists none, read 7 October

5. Topic

   Cadence

   Stated in the notes

   More frequent releases "for now", instead of batching fixes for the next planned release

   Not stated

   How often, or until when. Gaps in days: 10.3 to 10.4 95, 10.4 to 10.5 36, 10.5 to 10.6 56 (computed)

6. Topic

   Which tools

   Stated in the notes

   Two entries credit work "in collaboration with Claude and Anthropic Research"

   Not stated

   Any other tool or vendor, and which of the 11 security entries came from AI

Topic	Stated in the notes	Not stated
Volume	A "large number of security bug reports, many of which are findings from AI models or made with AI assistance"	How many reports, how many from AI, how many were valid, over what period
Impact	"many AI reports are determined not to have security impact" in a realistic threat model	Which reports, or what share. The entries that did matter are not marked
Rediscovery	In "a number of cases" a bug found by AI tools was later found independently by a different researcher	How many, which fixes, how long between the two finds, whether anyone else exploited one
Adversaries	This "suggests" that adversaries who do not report bugs "are likely to be able to discover these bugs too"	Any observed exploitation. The notes give none and KEV lists none, read 7 October
Cadence	More frequent releases "for now", instead of batching fixes for the next planned release	How often, or until when. Gaps in days: 10.3 to 10.4 95, 10.4 to 10.5 36, 10.5 to 10.6 56 (computed)
Which tools	Two entries credit work "in collaboration with Claude and Anthropic Research"	Any other tool or vendor, and which of the 11 security entries came from AI

"AI-found" reads as a flood of new flaws. The maintainers say something narrower and more useful: many AI reports have no security impact, and where a real bug is found, someone else is likely to find it too. If that holds, the time between a release and your patch is the exposure, and a report count says little about it.

The count of security entries per release gives a sense of the movement, with the caveats it needs. From 10.0 to 10.6 the notes list 1, 1, 0, 5, 8, 3 and 11 (counted by script). That counts entries, not flaws, and not who found them: 10.4 listed 8 before the AI paragraph first appeared in 10.5. The notes name one AI product family, Claude, in credit lines: in two 10.6 entries and, through an employer, in two 10.5 bugfix entries. They name no other AI vendor. The authors of the compression paper behind one entry state that they used ChatGPT, Gemini and Claude to edit their text and Claude Code to write proof-of-concept code, which they reviewed. In the paper's own account those tools were editors and coding assistants, not finders.

Google took a different course on 1 October and paused its open-source bounty for product flaws over automated submissions, as our earlier briefing records, and what a count measures was the lesson of the 1,313 CVEs in one Debian kernel advisory. A volume figure is a bookkeeping result until someone says what it counts.

The post-quantum signature protects no recorded traffic

The change in the headlines is ssh-mldsa44-ed25519, a composite of ML-DSA-44 and Ed25519. ML-DSA is NIST's FIPS 204, published 13 August 2024; NIST's page carries a 31 July 2026 planning note that a list of minor errata will be corrected in a future revision. The pairing is the safety net: the IETF draft says the composite stays at least as secure as the classical algorithm alone if a flaw is found in the post-quantum part.

OpenSSH 10.4 added an experimental form on 6 July 2026, "not enabled by default". 10.6 is 92 days later. The draft the 10.4 notes cited, posted 2 June 2026, is now marked replaced: first by a broader individual draft, then by draft-ietf-sshm-composite-sigs-00 of 21 August 2026, an IETF working group document and not an RFC. IANA's registry (page updated 8 September 2026) already lists the algorithm name with that last draft as its reference.

The notes say only "enable". The 10.6 source, read at tag V_10_6_P1 on 7 October, shows what that means. The algorithm and its certificate form sit last in each default algorithm list, after Ed25519 and RSA. sshd's default host key list includes ssh_host_mldsa44_ed25519_key, and ssh-keygen -A generates that key. The same key file names exist in the 10.4 and 10.5 source, and the ssh-keygen -A text there already named mldsa44-ed25519. Our reading: a host that ran ssh-keygen -A on an upstream 10.4 or 10.5 build probably holds an experimental key at the path 10.6 now uses. The notes say old keys "must be regenerated and/or removed" and not what happens if one is left in place.

Keys and signatures get much larger. The composite public key is 1,344 bytes against 32 for Ed25519, and a signature is 2,484 bytes against 64 (derived: 1,312 plus 32 and 2,420 plus 64, from FIPS 204 Table 2 and the draft). As an authorized_keys or known_hosts entry that is about 1,828 characters of base64 against 68 (derived). Check anything that stores keys in a field with a length limit.

Table 2. Two post-quantum jobs in OpenSSH, kept apart. Sources: the OpenSSH release notes 9.0, 9.9, 10.0, 10.4 and 10.6, the maintainers' post-quantum page, FIPS 204 and the IETF datatracker.

1. Question

   What it protects

   Key exchange (hybrid)

   The confidentiality of a session

   Signature (new in 10.6)

   Who a server or user is

2. Question

   Recorded traffic at risk today

   Key exchange (hybrid)

   Yes: the maintainers call it "store now, decrypt later"

   Signature (new in 10.6)

   No: the maintainers state "no risk to existing traffic" from signatures

3. Question

   OpenSSH status

   Key exchange (hybrid)

   Hybrid default since 9.0, 8 April 2022. ML-KEM hybrid default since 10.0, 9 April 2025

   Signature (new in 10.6)

   Experimental in 10.4, 6 July 2026. In the default lists, last in preference, since 10.6

4. Question

   Standards status

   Key exchange (hybrid)

   Both hybrids are, the maintainers say, being standardised for SSH

   Signature (new in 10.6)

   FIPS 204 final, 13 August 2024. The SSH composite is an IETF working group draft

5. Question

   What a 10.6 upgrade changes

   Key exchange (hybrid)

   sshd now logs connections without post-quantum key exchange, on by default

   Signature (new in 10.6)

   A new key type, and a warning that old experimental keys stop working

Question	Key exchange (hybrid)	Signature (new in 10.6)
What it protects	The confidentiality of a session	Who a server or user is
Recorded traffic at risk today	Yes: the maintainers call it "store now, decrypt later"	No: the maintainers state "no risk to existing traffic" from signatures
OpenSSH status	Hybrid default since 9.0, 8 April 2022. ML-KEM hybrid default since 10.0, 9 April 2025	Experimental in 10.4, 6 July 2026. In the default lists, last in preference, since 10.6
Standards status	Both hybrids are, the maintainers say, being standardised for SSH	FIPS 204 final, 13 August 2024. The SSH composite is an IETF working group draft
What a 10.6 upgrade changes	sshd now logs connections without post-quantum key exchange, on by default	A new key type, and a warning that old experimental keys stop working

The maintainers' own post-quantum page puts it plainly: for signatures there is "no risk to existing traffic", and the only urgency is retiring classical signature keys before cryptographically relevant quantum computers exist. That is the separation our briefing on Cloudflare's post-quantum CA drew between certificates and recorded traffic. Key exchange has been hybrid by default for 1,642 days (4.5 years) as of 10.6, counted from 9.0 on 8 April 2022. Whether a given host benefits is a version test, not a verdict, as our briefing on Forescout's 6% for medical devices showed.

The one new lever on that front is operational. sshd in 10.6 has WarnWeakCrypto, on by default, which logs when a client uses a key agreement that is not post-quantum safe. The notes do not say how noisy that is. Read as a free inventory, it lists the clients that still need updating.

Eleven entries, eleven CVEs, one scorer so far

The records are MITRE's. The OpenSSH security page, read at 11:10 BST, lists nothing for 2026 and its newest entry is dated 9 April 2025, so the maintainers' own channel carries no advisory or rating for any 2026 release. Table 3 matches each security entry in the notes to its record.

Table 3. The 11 security entries of OpenSSH 10.6 and the CVE record for each, matched by description. Scores are MITRE's CVSS v3.1 base scores as shown in NVD, read 11:12 BST on 7 October 2026 and again between 11:33 and 11:40. NVD status for all 11: Received.

1. Security entry in the 10.6 notes

   sftp: server-returned paths validated more strictly

   CVE

   CVE-2026-106552

   MITRE score

   4.2 medium

2. Security entry in the 10.6 notes

   sshd: GSSAPI credentials stored only after authentication succeeds

   CVE

   CVE-2026-106553

   MITRE score

   2.2 low

3. Security entry in the 10.6 notes

   sshd: GSSAPIAuthentication state reset before authentication

   CVE

   CVE-2026-106555

   MITRE score

   2.2 low

4. Security entry in the 10.6 notes

   ssh and sshd: LZ77 dictionary coder disabled (compression side channel)

   CVE

   CVE-2026-106582

   MITRE score

   3.7 low

5. Security entry in the 10.6 notes

   ssh: dollar sign and backslash refused in command-line usernames

   CVE

   CVE-2026-106583

   MITRE score

   2.5 low

6. Security entry in the 10.6 notes

   ssh-keygen: Daylight Saving Time handling in certificate dates

   CVE

   CVE-2026-106584

   MITRE score

   2.5 low

7. Security entry in the 10.6 notes

   ssh and sshd: decompressed payload checked against the maximum packet length

   CVE

   CVE-2026-106585

   MITRE score

   6.5 medium

8. Security entry in the 10.6 notes

   sshd: authorized_keys restrict now applied to tunnel forwarding

   CVE

   CVE-2026-106586

   MITRE score

   2.5 low

9. Security entry in the 10.6 notes

   sshd: "none" in some options no longer read as a file name

   CVE

   CVE-2026-106587

   MITRE score

   3.6 low

10. Security entry in the 10.6 notes

    sshd: macOS SDK 27 or later loses sandboxing (affects "through 10.6")

    CVE

    CVE-2026-106588

    MITRE score

    3.1 low

11. Security entry in the 10.6 notes

    sshd: post-authentication process keeps root on QNX 6, SCO OpenServer 5, --disable-fd-passing builds (affects "through 10.6")

    CVE

    CVE-2026-106589

    MITRE score

    2.9 low

Security entry in the 10.6 notes	CVE	MITRE score
sftp: server-returned paths validated more strictly	CVE-2026-106552	4.2 medium
sshd: GSSAPI credentials stored only after authentication succeeds	CVE-2026-106553	2.2 low
sshd: GSSAPIAuthentication state reset before authentication	CVE-2026-106555	2.2 low
ssh and sshd: LZ77 dictionary coder disabled (compression side channel)	CVE-2026-106582	3.7 low
ssh: dollar sign and backslash refused in command-line usernames	CVE-2026-106583	2.5 low
ssh-keygen: Daylight Saving Time handling in certificate dates	CVE-2026-106584	2.5 low
ssh and sshd: decompressed payload checked against the maximum packet length	CVE-2026-106585	6.5 medium
sshd: authorized_keys restrict now applied to tunnel forwarding	CVE-2026-106586	2.5 low
sshd: "none" in some options no longer read as a file name	CVE-2026-106587	3.6 low
sshd: macOS SDK 27 or later loses sandboxing (affects "through 10.6")	CVE-2026-106588	3.1 low
sshd: post-authentication process keeps root on QNX 6, SCO OpenServer 5, --disable-fd-passing builds (affects "through 10.6")	CVE-2026-106589	2.9 low

Two records give the affected range as "through 10.6", not "before 10.6": CVE-2026-106588 and CVE-2026-106589. On those records upgrading to 10.6 does not clear them. Debian's tracker disagrees on both: it marks the first not affected outside macOS and lists 1:10.6p1-1 as the fix for the second. Two published records disagree and we do not pick between them.

The pattern is not new. For 10.3 to 10.5 the notes list 5, 8 and 3 security entries, and CVE.org holds 16 records, all from MITRE, so 27 entries and 27 records across four releases. For 10.5 a participant on oss-security wrote on 11 August that MITRE "has now published CVE ids for these". What changes is the scoring. Of the 12 CVEs from 10.3 and 10.4 that now carry both a MITRE and an NVD score, NVD's is higher in 11 and equal in one, six reach 7 or above on NVD's score against two on MITRE's, and the widest gap is 4.5 points: CVE-2026-35386, the earlier command-line username fix, scored 3.6 by MITRE and 8.1 by NVD. That is inference from 12 records, not a forecast for any one of the 11: the 10.6 scores can move either way.

The patch gap is the open part

If the maintainers are right that a bug found once is likely to be found again, the date that matters is the one on which your build is fixed. The record for one earlier flaw shows how far apart those dates can be. CVE-2026-60002, in OpenSSH 10.4, is a client-side use-after-free when a server changes its host key during key re-exchange. It has the highest NVD score of the 12 that NVD has scored among the 27 CVEs for 10.3 to 10.6. CISA-ADP recorded exploitation as none on 8 July and it is not in KEV.

Debian's own definition explains the Debian bars. The "no-dsa" state is for issues that do not warrant an immediate advisory, and such issues "can still get fixed via a point update" or alongside a later fix. Debian's tracker reads the same for all 11 CVEs from 10.4 and 10.5, 57 to 91 days after publication at 7 October, and for the 10.6 CVEs it shows a bare "vulnerable" with no note yet. Red Hat's Enterprise Linux 10.0 Extended Update Support advisory for CVE-2026-60002 came 63 days after publication.

None of the stable releases in Table 4 ships a version that reads 10.6, so a banner check says nothing about a fix. Table 4 shows where each stood the morning after release.

Table 4. What Debian, Ubuntu and Red Hat showed for the 11 OpenSSH 10.6 CVEs on 7 October 2026: Debian between 11:17 and 11:19 BST from its security tracker, Ubuntu and Red Hat between 11:33 and 11:40 BST from their CVE data feeds, shipped versions from Debian's tracker, Launchpad and Red Hat's data.

1. Distribution

   Debian 13 (trixie)

   OpenSSH it ships

   10.0p1 with Debian patches

   Status of the 10.6 CVEs

   10 of 11 vulnerable, no fix. 1:10.6p1-1 is in unstable only

2. Distribution

   Debian 12 (bookworm)

   OpenSSH it ships

   9.2p1 with Debian patches

   Status of the 10.6 CVEs

   10 of 11 vulnerable, no fix

3. Distribution

   Ubuntu 26.04, 24.04, 22.04

   OpenSSH it ships

   10.2p1, 9.6p1 and 8.9p1 with Ubuntu patches

   Status of the 10.6 CVEs

   No record for any of the 11 identifiers

4. Distribution

   Red Hat Enterprise Linux 9 and 10

   OpenSSH it ships

   9.9p1 builds with Red Hat patches

   Status of the 10.6 CVEs

   No record for any of the 11 identifiers

Distribution	OpenSSH it ships	Status of the 10.6 CVEs
Debian 13 (trixie)	10.0p1 with Debian patches	10 of 11 vulnerable, no fix. 1:10.6p1-1 is in unstable only
Debian 12 (bookworm)	9.2p1 with Debian patches	10 of 11 vulnerable, no fix
Ubuntu 26.04, 24.04, 22.04	10.2p1, 9.6p1 and 8.9p1 with Ubuntu patches	No record for any of the 11 identifiers
Red Hat Enterprise Linux 9 and 10	9.9p1 builds with Red Hat patches	No record for any of the 11 identifiers

"No record" is not "not affected". It means the distribution has not yet published an assessment, which is the normal state a few hours after release and the reason to read these pages again before acting. The eleventh, the macOS-only CVE, is marked not affected. For 1:10.6p1-1, Debian's package tracker showed on 7 October that the upload to unstable on 6 October had not yet migrated to testing, blocked at that time by a missing riscv64 build.

What 10.6 changes in your estate

Seven changes need a decision. Each is the maintainers' wording first and our reading second.

• Compression. The notes say ssh and sshd now disable the LZ77 dictionary coder, so the Compression option is "less effective", and recommend application-level compression. In the 10.6 source the sending side starts zlib with its Huffman-only strategy, where 10.5 used the default. Because the compression paper says each direction of a connection has its own context, our inference is that a direction is protected only where its sender runs 10.6. ssh_config defaults to no compression. sshd_config defaults to yes, but on our reading of the negotiation rule the paper describes, a connection compresses only when the client prefers it. Ansible's default ssh arguments include -C, so every Ansible-driven connection asks for it. The paper says compression is preferred by default in only 4 of 33 clients it surveyed, that 28.1 million of 30.2 million servers (93%) offer it, and that "exposure remains unquantified".
• Usernames from untrusted sources. ssh now refuses command-line usernames containing a dollar sign or a backslash, because a name from an untrusted source could inject into a shell context through ProxyCommand or Match exec. Names set with the User directive in config are exempt. This is the third tightening in a year: 10.1 (6 October 2025) refused control characters, 10.3 (2 April 2026) moved the check earlier and validated ProxyJump names. The maintainers say mitigations like this "can not be absolute" and keep recommending against exposing ssh command lines to untrusted input. Likely casualties, our reading: automation that builds a command from a ticket field, a repository name or a domain-qualified account written with a backslash.
• GSSAPI and Kerberos. Two entries: sshd stores GSSAPI credentials only after authentication succeeds, and resets its GSSAPI state before authentication. Both concern GSSAPIAuthentication, so check where Kerberos single sign-on is enabled.
• Certificate dates. ssh-keygen mishandled Daylight Saving Time when converting dates, so certificates could be created with expiry times off by up to an hour (two in the Antarctica/Troll time zone). UK clocks go back on 25 October 2026. The notes do not say which forms of the validity option were affected, and our reading is that certificates already issued keep whatever expiry they were given.
• sftp paths. The sftp client now validates paths returned by a server more strictly. Relevant wherever recursive copies run against servers you do not control, for example a supplier's drop point.
• Legacy platforms. On QNX 6, SCO OpenServer 5 and builds made with --disable-fd-passing, the post-authentication process keeps root, so GatewayPorts and StreamLocalForwarding are disabled there and support is to be removed in future. Our reading: where they survive in UK estates they will be old appliances or embedded systems. The notes do not say.
• Experimental ML-DSA keys. Regenerate or remove them before upgrading, as above.

For UK estates: the clock, the inventory and the order of work

The NCSC's migration timeline, version 1.0 of 20 March 2025, asks organisations to "Complete the discovery and assessment phase" by 2028, to "Complete your highest priority migration activities to protect your most critical assets" by 2031, and to "Complete your migration to PQC" by 2035. The gaps are 3 and 4 years, and from 2026 the three dates are 2, 5 and 9 calendar years away. SSH host keys, user keys, certificate authorities and the algorithms in use belong in that discovery work, with key exchange and signatures as separate rows, as in our briefing on Forescout's report.

For UK Linux and network administrators, hosting providers, managed service providers, universities and NHS suppliers, the order below follows the notes. Items 5, 8 and 9 include our judgement.

# Read-only checks, run as an administrator on a host you own.
ssh -V
ls -l /etc/ssh/ssh_host_mldsa44_ed25519_key* ~/.ssh/id_mldsa44_ed25519* 2>/dev/null
ssh -Q sig | grep -i mldsa
sshd -T | grep -i -E 'hostkey|compression|warnweakcrypto'
grep -rn -i 'compression' /etc/ssh/ssh_config /etc/ssh/ssh_config.d/ ~/.ssh/config 2>/dev/null

The question that exposes the gap

OpenSSH says others are likely to find the same bugs, and its notes cite no CVE, rate nothing and promise only "more frequent releases" for now. The post-quantum signature is about authentication on the NCSC's 2035 horizon. The 11 fixes are about what can be done to an unpatched host this month.

For each OpenSSH build you run, which date does your record call patched: the day upstream released, the day your distribution marked a status, or the day the last jump host restarted sshd?

Key facts