← Back to Feed CACHED · 2026-10-01 13:34:32 · CACHE_KEY CVE-2026-77185
CVE-2026-77185 · CWE-305 · Disclosed 2026-09-30

Authentication bypass in sshd-core in Apache MINA SSHD versions 2.0.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5…

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Auth bypass requires rare async code path most MINA SSHD users never write — downgrade to MEDIUM"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify a MINA SSHD server using async pubkey auth

The attacker must locate an SSH service backed by Apache MINA SSHD where the developer's 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Standard SSH banner grabs will identify the SSH implementation string but cannot distinguish async vs sync auth. No Nuclei template, Nessus plugin, or Qualys QID exists for this CVE as of 2026-10-01.
STEP 02

Send public-key auth request with invalid or missing signature

The attacker initiates an SSH session and sends an 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.
Conditions required:
  • 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)
Where this breaks in practice:
  • 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
STEP 03

Gain authenticated SSH session as target user

With the signature check bypassed, the attacker obtains a fully authenticated SSH session with the privileges of the target user identity. Depending on the application embedding MINA SSHD, this could grant shell access, SFTP file operations, Git repository access, or application-specific command execution. The impact scales with the application's privilege model.
Conditions required:
  • Steps 1 and 2 succeeded
Where this breaks in practice:
  • 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
Detection/coverage: SSH session establishment will appear in server logs. Anomalous authentication from unexpected source IPs or for unexpected users may trigger SIEM alerts if SSH auth logging is forwarded.
STEP 04

Pivot or escalate from SSH session

From the authenticated session, the attacker performs lateral movement or privilege escalation depending on the application context. On a CI/CD system this could mean injecting build pipeline code; on a Git server this could mean pushing malicious commits; on a general-purpose server this could mean file exfiltration or command execution. The blast radius depends entirely on what the MINA SSHD-backed application does.
Conditions required:
  • Application grants meaningful capabilities via SSH session
  • Network position allows lateral movement from the compromised host
Where this breaks in practice:
  • Most MINA SSHD deployments are internal services, not internet-facing
  • EDR and network monitoring should detect unusual post-auth behavior
Detection/coverage: Post-exploitation activity (file access, process creation, network connections) should be visible to EDR agents and network monitoring.
03 · Compensating Control

1
MEDIUM 5.3→IGNORE 0.0
SEVERITY REDUCED
Audit your codebase for AsyncAuthException usage in pubkey/hostbased authenticators — Search your Java source and decompiled dependencies for 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.
2
MEDIUM 5.3→IGNORE 0.0
SEVERITY REDUCED
Upgrade to MINA SSHD 2.20.0 or 3.0.0-M6 — The patched versions remove async authentication support from public-key and hostbased authentication entirely, closing the vulnerable code path at the library level. This is the definitive fix. For a MEDIUM verdict, the noisgate remediation SLA is 365 days, but given the trivial upgrade path (minor version bump, no breaking API changes for sync auth users), aim to include it in your next quarterly dependency refresh.
3
MEDIUM 5.3→LOW 2.5
SEVERITY REDUCED
Restrict network access to embedded SSH ports — If your application exposes a MINA SSHD-backed SSH port, ensure it is firewalled to only authorized source networks. This reduces the attacker's ability to reach the service even if the async auth path were present. Deploy within the 365-day remediation window as defense-in-depth.
4
MEDIUM 5.3→MEDIUM 5.3
Enable SSH authentication logging and forward to SIEM — Ensure that your MINA SSHD server configuration logs all authentication attempts, including the authentication method and outcome. Forward these logs to your SIEM and alert on authentication successes from unexpected sources. This provides detection but not prevention.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed on CISA KEV. No reports from threat intelligence feeds, GreyNoise, or Shadowserver as of 2026-10-01.
Proof-of-Concept AvailabilityNo 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 Score0.00% — bottom of the distribution, indicating near-zero predicted exploitation probability in the next 30 days.
KEV StatusNot listed on CISA Known Exploited Vulnerabilities catalog as of 2026-10-01.
CVSS VectorCVSS: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 Versions2.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 Versions2.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 / ExposureMINA 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 TimelineCVE reserved 2026-08-20. Public disclosure 2026-09-30 via Apache mailing list and Openwall oss-security.
ReporterChris Jarret-Davies, OpenAI Security Research Team.

Sources.

  1. Apache MINA SSHD Advisory (Openwall oss-security)
  2. SecurityOnline — Apache MINA SSHD Vulnerabilities Patched
  3. CVE-2026-77185 — ThreatInt
  4. Strix.ai CVE-2026-77185 Detail
  5. Jenkins mina-sshd-api-plugin (GitHub)
  6. Apache MINA SSHD Server Setup Documentation
  7. Maven Repository — sshd-core dependents
  8. TheHackerWire — CVE-2026-77185 Analysis
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (5.3/10)

Why this verdict

  • Async auth is explicit opt-in, not default behavior. The vulnerable code path requires the developer to write a custom PublickeyAuthenticator or HostBasedAuthenticator that throws AsyncAuthException. The vendor's own advisory calls this pattern "presumed rare." This is not captured by the CVSS AC:L rating — 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 AsyncAuthException code 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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously