A locked vault door with a secret bypass lever that only exists if the builder custom-welded it in
CVE-2026-77185 is a signature-verification skip in the sshd-core component of Apache MINA SSHD, a pure-Java SSH library used to embed SSH client and server functionality into Java applications. Affected versions span 2.0.0 through 2.19.0 on the 2.x branch and 3.0.0-M1 through 3.0.0-M5 on the 3.x milestone branch. The flaw lives in the *asynchronous authentication* mechanism: when a developer's custom PublickeyAuthenticator or HostBasedAuthenticator implementation throws AsyncAuthException to signal deferred authentication, the library's internal state machine can skip or mis-evaluate the cryptographic signature check. An attacker connecting to such a server can authenticate with an invalid or absent private-key signature and gain the session identity of any authorized user.
The vendor scored this CVSS 9.1 CRITICAL with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, modeling it as an unauthenticated, low-complexity network attack with high confidentiality and integrity impact. That vector is technically correct *if you assume the async auth code path is reachable* — but the advisory itself says the pattern is "presumed rare" and requires explicit developer opt-in code. The async auth API isn't even documented in MINA SSHD's main server-setup guide. No mainstream product embedding MINA SSHD (Jenkins, Gerrit, Eclipse JGit, Apache Karaf, Apache OFBiz) is known to use async authentication for public-key or hostbased schemes. The CVSS AC:L rating fundamentally misrepresents this prerequisite — it's closer to a non-default configuration gate than a universally reachable attack surface, making the 9.1 score misleading for the vast majority of deployments.
4 steps from start to impact.
Identify a MINA SSHD server using async pubkey auth
PublickeyAuthenticator implementation throws AsyncAuthException to defer the authentication decision. This is not detectable from a banner or protocol probe — the attacker needs prior knowledge of the target application's authentication architecture, or must discover it through trial-and-error by sending crafted auth requests and observing timing behavior.- Target runs Apache MINA SSHD 2.0.0–2.19.0 or 3.0.0-M1–3.0.0-M5
- Server-side code explicitly implements async public-key or hostbased authentication via
AsyncAuthException - SSH port is network-reachable to the attacker
- The async auth pattern is "presumed rare" per the vendor's own advisory
- Async pubkey auth is not documented in the official server-setup guide — most developers use synchronous
boolean authenticate() - No mainstream MINA SSHD consumer (Jenkins, Gerrit, JGit, Karaf) uses this code path
- The attacker cannot distinguish async-auth servers from sync-auth servers remotely without probing
Send public-key auth request with invalid or missing signature
SSH_MSG_USERAUTH_REQUEST for publickey authentication. In the normal flow, the server verifies the signature over the session ID and auth data. When the async auth path is active, the flawed state machine in ServerUserAuthService can return a success result before or without validating the signature, or can mis-handle the AsyncAuthException callback to produce a wrong (accepting) result.- Attacker has a valid username (or can enumerate one)
- Attacker possesses any public key listed in the server's authorized keys (the *public* half only — no private key needed)
- Requires knowledge of a valid username on the target service
- Requires access to a public key the server would accept (though public keys are by definition public, many embedded SSH servers use application-specific key management)
- No public PoC or exploit tool exists — exploitation requires understanding MINA SSHD's internal auth state machine
Gain authenticated SSH session as target user
- Steps 1 and 2 succeeded
- Many embedded MINA SSHD servers provide limited command sets (e.g., Gerrit's SSH interface is scoped to Git operations, not a full shell)
- Application-level authorization may further restrict post-auth actions
Pivot or escalate from SSH session
- Application grants meaningful capabilities via SSH session
- Network position allows lateral movement from the compromised host
- Most MINA SSHD deployments are internal services, not internet-facing
- EDR and network monitoring should detect unusual post-auth behavior
AsyncAuthException thrown from PublickeyAuthenticator or HostBasedAuthenticator implementations. If found, you are in the vulnerable population and should treat this as CRITICAL and patch within 3 days. If not found (likely), you can confirm non-exposure and deprioritize. Run grep -r 'AsyncAuthException' --include='*.java' across your source trees. This is a no-mitigation-SLA MEDIUM — go straight to the 365-day remediation window.- Disabling public-key authentication entirely — While this would eliminate the vulnerable code path, it would also break legitimate SSH access patterns and is not practical for most deployments. The better approach is to verify you don't use async auth and patch.
- WAF or IDS SSH inspection — SSH is encrypted end-to-end; network-layer security tools cannot inspect the authentication exchange to detect exploitation of this flaw.
- Rotating SSH keys — The vulnerability bypasses signature verification, meaning the attacker doesn't need the private key at all. New keys are equally bypassable on an unpatched async-auth server.
The supporting signals.
| In-the-Wild Exploitation | None observed. Not listed on CISA KEV. No reports from threat intelligence feeds, GreyNoise, or Shadowserver as of 2026-10-01. |
|---|---|
| Proof-of-Concept Availability | No public PoC. Checked pocindex.io, GitHub (no repos named CVE-2026-77185), ExploitDB, and SecureWithUmer/CVE-2026-PoCs — zero results. The async auth state-machine flaw is non-trivial to weaponize without deep knowledge of MINA SSHD internals. |
| EPSS Score | 0.00% — bottom of the distribution, indicating near-zero predicted exploitation probability in the next 30 days. |
| KEV Status | Not listed on CISA Known Exploited Vulnerabilities catalog as of 2026-10-01. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — 9.1 CRITICAL. Network vector, no auth required, high C+I impact. However, AC:L does not account for the required non-default async auth code path, which functionally raises attack complexity significantly. |
| Affected Versions | 2.x: 2.0.0 through 2.19.0. 3.x: 3.0.0-M1 through 3.0.0-M5. The sshd-core artifact is the affected module. The library has ~571 Maven dependents total, ranking #886 on MvnRepository and #2 among Java SSH libraries. |
| Fixed Versions | 2.20.0 and 3.0.0-M6. The fix *removes* async auth support from public-key and hostbased authentication entirely — AsyncAuthException is no longer accepted in those code paths. If thrown, the session is terminated and a log entry is written. Dependabot PRs are rolling out across Apache OFBiz, Maven Wagon, Maven SCM, and Eclipse Dirigible. |
| Scanning / Exposure | MINA SSHD services are embedded in Java applications and do not expose a standard OpenSSH banner — Shodan/Censys SSH scans cannot reliably identify MINA SSHD instances, let alone those using async auth. Internet-facing exposure is estimated to be very low; most deployments are internal. |
| Disclosure Timeline | CVE reserved 2026-08-20. Public disclosure 2026-09-30 via Apache mailing list and Openwall oss-security. |
| Reporter | Chris Jarret-Davies, OpenAI Security Research Team. |
Sources.
- Apache MINA SSHD Advisory (Openwall oss-security)
- SecurityOnline — Apache MINA SSHD Vulnerabilities Patched
- CVE-2026-77185 — ThreatInt
- Strix.ai CVE-2026-77185 Detail
- Jenkins mina-sshd-api-plugin (GitHub)
- Apache MINA SSHD Server Setup Documentation
- Maven Repository — sshd-core dependents
- TheHackerWire — CVE-2026-77185 Analysis
Why this verdict
- Async auth is explicit opt-in, not default behavior. The vulnerable code path requires the developer to write a custom
PublickeyAuthenticatororHostBasedAuthenticatorthat throwsAsyncAuthException. The vendor's own advisory calls this pattern "presumed rare." This is not captured by the CVSSAC:Lrating — it functions as a non-default configuration gate that eliminates the vast majority of the ~571 Maven dependents from the vulnerable population. - No mainstream product uses the vulnerable path. Jenkins, Gerrit, JGit, Apache Karaf, Apache OFBiz, Maven Wagon, and Eclipse Dirigible all consume MINA SSHD but use synchronous authentication. The async pubkey auth pattern is not documented in the official server-setup guide. We could not identify a single widely-deployed product that implements async public-key or hostbased authentication.
- Zero exploitation evidence and zero PoC. EPSS is 0.00%, no KEV listing, no GreyNoise/Shadowserver hits, no public exploit code. The state-machine flaw requires deep understanding of MINA SSHD internals to weaponize, and the attacker must first identify a target that uses the rare async path.
- Role multiplier: MINA SSHD is embedded in CI/CD infrastructure (Jenkins, Gerrit) which are high-value targets. However, the chain does not succeed in these products because they use synchronous authentication — the
AsyncAuthExceptioncode path is never entered. For the chain to succeed in a high-value role, a bespoke Java application in that role would need to have been custom-coded with async pubkey auth. We estimate this represents well under 1% of the MINA SSHD installed base, failing the high-value-role floor threshold. - Network exposure is limited. Most MINA SSHD services are internal-facing embedded SSH endpoints, not internet-exposed servers. The library is not a replacement for OpenSSH — it's used for application-level SSH functionality where the service is typically behind firewalls and load balancers.
Why not higher?
The CVSS vector's AC:L and PR:N would justify CRITICAL or HIGH if the async auth path were reachable by default. However, the vendor explicitly characterizes the precondition as "presumed rare," no mainstream consumer product uses it, and we cannot identify ≥1% of the installed base occupying a high-value role where the chain succeeds. Without a single confirmed real-world product using async pubkey auth, elevating to HIGH would be modeling a theoretical population that may not meaningfully exist.
Why not lower?
The underlying flaw — skipping cryptographic signature verification in SSH authentication — is a severe primitive when it is reachable. A custom application that *does* implement async pubkey auth faces a genuine unauthenticated remote bypass with high-impact consequences. The 571 Maven dependents create a non-trivial long tail of custom Java applications where the pattern *could* appear. Dropping to LOW would understate the impact for the (small) population of affected servers.
Crowdsourced verification payload.
Run this script on any host where Java applications may embed Apache MINA SSHD. Execute as any user with read access to the application deployment directories. Usage: chmod +x check_cve_2026_77185.sh && ./check_cve_2026_77185.sh /opt/myapp/lib (pass the directory containing your application's JAR files). No special privileges required beyond read access.
#!/usr/bin/env bash
# CVE-2026-77185 Checker — Apache MINA SSHD Async Auth Bypass
# Checks for vulnerable sshd-core JARs and AsyncAuthException usage
# Exit codes: 0=PATCHED/NOT_PRESENT, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
SEARCH_DIR="${1:-.}"
VULN_FOUND=0
ASYNC_RISK=0
JARS_FOUND=0
echo "[*] Scanning for sshd-core JARs in: $SEARCH_DIR"
while IFS= read -r -d '' jar; do
JARS_FOUND=1
basename_jar=$(basename "$jar")
# Extract version from filename pattern sshd-core-X.Y.Z.jar
version=$(echo "$basename_jar" | sed -n 's/sshd-core-\([0-9][0-9a-zA-Z.\-]*\)\.jar/\1/p')
if [ -z "$version" ]; then
# Try extracting from MANIFEST.MF inside JAR
version=$(unzip -p "$jar" META-INF/MANIFEST.MF 2>/dev/null | grep -i 'Bundle-Version\|Implementation-Version' | head -1 | awk -F': ' '{print $2}' | tr -d '\r')
fi
if [ -z "$version" ]; then
echo "[?] UNKNOWN — Found $jar but could not determine version"
continue
fi
echo "[*] Found: $basename_jar (version: $version)"
# Check if version is in affected range
# Affected: 2.0.0-2.19.0, 3.0.0-M1-3.0.0-M5
# Safe: 2.20.0+, 3.0.0-M6+, 1.x
major=$(echo "$version" | cut -d. -f1)
minor=$(echo "$version" | cut -d. -f2)
if [ "$major" -eq 2 ] 2>/dev/null; then
if [ "$minor" -ge 0 ] && [ "$minor" -le 19 ] 2>/dev/null; then
echo "[!] VULNERABLE — $basename_jar ($version) is in affected range 2.0.0–2.19.0"
VULN_FOUND=1
else
echo "[+] PATCHED — $basename_jar ($version) is >= 2.20.0"
fi
elif [ "$major" -eq 3 ] 2>/dev/null; then
if echo "$version" | grep -qE '3\.0\.0-M[1-5]$'; then
echo "[!] VULNERABLE — $basename_jar ($version) is in affected range 3.0.0-M1–M5"
VULN_FOUND=1
else
echo "[+] PATCHED — $basename_jar ($version) is >= 3.0.0-M6"
fi
else
echo "[+] NOT AFFECTED — $basename_jar ($version) is outside affected major versions"
fi
done < <(find "$SEARCH_DIR" -name 'sshd-core-*.jar' -print0 2>/dev/null)
if [ "$JARS_FOUND" -eq 0 ]; then
echo "[+] NOT PRESENT — No sshd-core JARs found in $SEARCH_DIR"
echo "PATCHED"
exit 0
fi
# Bonus: check for AsyncAuthException usage in source trees
echo ""
echo "[*] Checking for AsyncAuthException usage in Java sources under $SEARCH_DIR..."
if find "$SEARCH_DIR" -name '*.java' -exec grep -l 'AsyncAuthException' {} + 2>/dev/null | head -5 | grep -q .; then
echo "[!!] WARNING — Found AsyncAuthException references in source code. Your application MAY use the vulnerable async auth path."
ASYNC_RISK=1
else
echo "[+] No AsyncAuthException usage found in source files — likely not using the vulnerable async auth pattern."
fi
if [ "$VULN_FOUND" -eq 1 ]; then
if [ "$ASYNC_RISK" -eq 1 ]; then
echo ""
echo "VULNERABLE (async auth pattern detected — HIGH RISK)"
else
echo ""
echo "VULNERABLE (but async auth pattern not detected in source — likely low practical risk)"
fi
exit 1
else
echo ""
echo "PATCHED"
exit 0
fi