CVE-2026-93994
Description
A flaw was found in Apache MINA SSHD. When the server is configured to require multiple Secure Shell (SSH) public keys for authentication, it fails to verify that the submitted keys are distinct. A remote user can exploit this flaw by presenting the same public key twice to satisfy multi-key authentication requirements. This flaw results in an authentication bypass, allowing an attacker to gain unauthorized access using fewer credentials than mandated by the security policy.
Statement
A flaw was found in Apache MINA SSHD's authentication implementation in the sshd-core component. When an SSH server is configured to require multi-factor authentication using two different public keys (configured as AuthenticationMethods "publickey,publickey" in OpenSSH or equivalent in Apache MINA SSHD), the server does not validate that the two public keys presented during authentication are actually different. An attacker who possesses one valid SSH key authorized for an account can successfully authenticate by presenting the same key twice, bypassing the requirement for a second key. This is a partial authentication bypass that completely negates the security benefit of multi-key authentication configurations.
Red Hat ships vulnerable versions of Apache MINA SSHD in JBoss EAP 7/8/XP, JBoss Fuse 7 (Extended Lifecycle Support), Red Hat SSO 7, OpenShift Tools 4.x, Red Hat build of Apache Camel (Quarkus and Spring Boot variants), and RHEL-based Java packages. Fixed version 2.20.0 is available, which addresses this issue by enforcing that two distinct public keys must be presented for multi-key authentication.
Mitigation
There is no mitigation available for this issue. Apply updates as they become available from Red Hat product teams. As a temporary workaround, if using Apache MINA SSHD with multi-key authentication configured, consider implementing additional authentication mechanisms (password, OTP) or restricting SSH access to trusted networks until patches are applied.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 8.1 | N/A | 8.1 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
