Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)

Reading time: 6 minutes

Summary

CVE-2024-28080 is an authentication bypass in Gitblit’s embedded SSH service due to incorrect session state handling when integrating with Apache MINA SSHD. If a user account has at least one SSH public key registered, an attacker who knows the username and any of that user’s public keys can authenticate without the private key and without the password.

• Affected: Gitblit < 1.10.0 (observed on 1.9.3)
• Fixed: 1.10.0
• Requirements to exploit:
  • Git over SSH enabled on the instance
  • Victim account has at least one SSH public key registered in Gitblit
  • Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/.keys)

Root cause (state leaks between SSH methods)

In RFC 4252, public‑key authentication proceeds in two phases: the server first checks whether a provided public key is acceptable for a username, and only after a challenge/response with a signature does it authenticate the user. In MINA SSHD, the PublickeyAuthenticator is invoked twice: on key acceptance (no signature yet) and later after the client returns a signature.

Gitblit’s PublickeyAuthenticator mutated the session context on the first, pre‑signature call by binding the authenticated UserModel to the session and returning true ("key acceptable"). When authentication later fell back to password, the PasswordAuthenticator trusted that mutated session state and short‑circuited, returning true without validating the password. As a result, any password (including empty) was accepted after a prior public‑key "acceptance" for the same user.

High‑level flawed flow:

1. Client offers username + public key (no signature yet)
2. Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable")
3. Client cannot sign (no private key), so auth falls back to password
4. Password auth sees a user already present in session and unconditionally returns success

Step‑by‑step exploitation

• Collect a victim’s username and one of their public keys:
  • GitHub exposes public keys at https://github.com/.keys
  • Public servers often expose authorized_keys
• Configure OpenSSH to present only the public half so signature generation fails, forcing a fallback to password while still triggering the public‑key acceptance path on the server.

Example SSH client config (no private key available):

# ~/.ssh/config
Host gitblit-target
  HostName <host-or-ip>
  User <victim-username>
  PubkeyAuthentication yes
  PreferredAuthentications publickey,password
  IdentitiesOnly yes
  IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)

Connect and press Enter at the password prompt (or type any string):

ssh gitblit-target
# or Git over SSH
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>

Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.

Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.

Impact

• Full impersonation of any Gitblit user with at least one registered SSH public key
• Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
• Potential administrative impact if targeting an admin user
• Pure network exploit; no brute force or private key required

Detection ideas

• Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password
• Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username

Mitigations

• Upgrade to Gitblit v1.10.0+
• Until upgraded:
  • Disable Git over SSH on Gitblit, or
  • Restrict network access to the SSH service, and
  • Monitor for suspicious patterns described above
• Rotate affected user credentials if compromise is suspected

General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)

Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:

• Presenting a legitimate public key for the target user (no private key)
• Forcing the client to fail signing so the server falls back to password
• Supplying any password while the password authenticator short‑circuits on leaked state

Practical tips:

• Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys
• Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
• MINA SSHD integration pitfalls:
  • PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
  • PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method

Related protocol/design notes and literature:

• SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
• Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior

References

• Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)
• Gitblit v1.10.0 release notes
• Apache MINA SSHD project
• PublickeyAuthenticator API
• RFC 4252: The Secure Shell (SSH) Authentication Protocol