Cyber Resilience

CVE-2026-59998

Openbsd Openssh ≤ 10.4

Published
08 July 2026
Modified
09 July 2026
CVSS Score v3.1 4.8
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score 0.0018 8th percentile
Risk Priority 37 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2026-59998 is a medium-severity Improper Following of Specification by Caller (CWE-573) vulnerability in Openbsd Openssh. Its CVSS base score is 4.8 (Medium).

Operationally, ranked at the 8th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

sshd in OpenSSH before 10.4 has an undocumented security-relevant behavior: GSSAPIStrictAcceptorCheck has no value if the server is in Windows Active Directory.

CWE(s)
CWE-573

Related Threats

CVEs Like This One

CVE-2026-35386Same product: Openbsd Openssh
CVE-2026-59996Same product: Openbsd Openssh
CVE-2026-60001Same product: Openbsd Openssh
CVE-2026-60002Same product: Openbsd Openssh
CVE-2026-59999Same product: Openbsd Openssh
CVE-2026-35387Same product: Openbsd Openssh
CVE-2026-35385Same product: Openbsd Openssh
CVE-2026-59995Same product: Openbsd Openssh
CVE-2026-35388Same product: Openbsd Openssh
CVE-2026-35414Same product: Openbsd Openssh

Affected Assets

openbsd
openssh
≤ 10.4

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

SA-11 Developer Testing and Evaluation good match

Developer testing and evaluation can discover cases where callers fail to follow required specifications or APIs.

SA-15 Development Process, Standards, and Tools partial match

Requiring a documented development process and standards reduces the chance that callers will deviate from language, framework, or protocol specifications.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly enforce correct adherence to language, framework, protocol and platform specifications during implementation.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

A.8.29 Security testing in development and acceptance mostly match
finds

Security testing can detect specification non-compliance but does not itself prevent the weakness.

A.8.25 Secure development life cycle partial match
prevents

Secure development life cycle mandates adherence to language, framework and protocol specifications, directly reducing improper caller behavior.

A.8.26 Application security requirements partial match
prevents

Application security requirements explicitly capture specification compliance obligations that callers must follow.

A.8.27 Secure system architecture and engineering principles partial match
prevents

Secure system architecture and engineering principles include specification adherence as a design constraint.

A.8.28 Secure coding partial match
prevents

Secure coding standards enforce correct use of APIs, protocols and language features, mitigating caller specification violations.

A.8.32 Change management partial match
prevents

Change management can catch specification drift during updates but is not a primary mitigation.

References