GitHub Advisoryadvisory · Maven

GHSA-vjfw-cpmh-xwv3 Central Dogma: SSH host-key verification permanently disabled in Git mirror (SshGitMirror)

HIGH Published 2026-09-11 Modified 2026-09-11 Official page ↗
Aliases
CVE-2026-11745
Ecosystem
Maven
Packages
com.linecorp.centraldogma:centraldogma-server-mirror-git
Severity
High
CVSS vector
CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:L
Weaknesses
CWE-322
Reviewed
2026-09-11

Affected packages

• Maven com.linecorp.centraldogma:centraldogma-server-mirror-git: < 0.84.0 → fixed in 0.84.0

Description

Vulnerability Central Dogma's Git mirror SSH client installs an Apache MINA SSHD `ServerKeyVerifier` lambda that returns `true` unconditionally for every outbound SSH connection used by `git+ssh://` mirrors. The accompanying lines disable the `known_hosts` and `~/.ssh/config` fallbacks, and a repo-wide search confirms that no host-key pinning mechanism (no `acceptedHostKeys`, `knownHosts`, `KnownHostsServerKeyVerifier`, `StaticServerKeyVerifier`, or `RequiredServerKeyVerifier`) exists anywhere in `server-mirror-git/`. Operators have no opt-in way to enable verification. Every outbound mirror connection blindly trusts whatever host key the remote presents. Evidence File: `server-mirror-git/src/main/java/com/linecorp/centraldogma/server/internal/mirror/SshGitMirror.java` Lines 143-160 (especially 149) on branch `main` @ commit `d64a5151`: ```java private SshClient createSshClient() { final ClientBuilder builder = ClientBuilder.builder(); // Do not use local file system. builder.hostConfigEntryResolver(HostConfigEntryResolver.EMPTY); // line 146 builder.fileSystemFactory(NoneFileSystemFactory.INSTANCE); // line 147 // Do not verify the server key. builder.serverKeyVerifier((clientSession, remoteAddress, serverKey) -> true); // line 149 ... } ``` Verification: • Read confirmed on 2026-05-21 against `main` @ `d64a5151`. • A multi-agent code audit verified that no operator-facing pinning field exists on `SshKeyCredential`, `PasswordCredential`, or `MirrorContext`. • Exploit PoC reproduced locally with a `paramiko`-based fake SSH server bound to 127.0.0.1. The fake server presents an ephemeral RSA host key never seen before; the Central Dogma mirror client accepts the connection and proceeds to authentication, logging the offered username and public-key fingerprint. A correctly hardened SSH client would refuse the connection before reaching the authentication phase. • Full PoC artifacts (read-only, loopback-only) at `~/centraldogma-poc/C1_ssh_hostkey_bypass/` on the reporter's workstation. Impact Threat model: An on-path attacker on the corporate network — ARP spoofing on the LAN, internal DNS poisoning, malicious internal DNS overriding `github.com` or the configured internal git hostname, BGP hijack, sidecar/CNI compromise in Kubernetes, or any process able to answer TCP on the resolved IP. No Central Dogma account required; only network position. 1. Direction `LOCAL_TO_REMOTE`: the attacker impersonating the remote git server receives the entire mirrored repository contents over the SSH session. Central Dogma is a configuration store, so this typically exfiltrates DB credentials, third-party API keys, certificates, feature flags, and any other secret configuration committed to mirrored repositories. 2. Direction `REMOTE_TO_LOCAL`: the attacker can serve arbitrary commits which Central Dogma materializes into the local repo and then broadcasts to every subscribing microservice via the watch API. This is a supply-chain root-of-trust compromise across all downstream services consuming Central Dogma configuration. 3. Credential theft chain with finding H2 (mirror credentials are not bound to a hostname): an SSH key or access token configured for `github.com` can be captured by the attacker's fake server and replayed against the real upstream, extending impact beyond Central Dogma itself. Scope is `Changed` (CVSS) because exploitation alters trust assumptions of every downstream client of Central Dogma, not just Central Dogma itself. How to fix 1. Add an `acceptedHostKeys: List` field to `SshKeyCredential` and `PasswordCredential` (or to `MirrorContext`). Values are SHA-256 fingerprints of trusted remote SSH server host keys, e.g. `SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8`. 2. Replace the accept-all lambda at `SshGitMirror.java:149` with a verifier that computes the SHA-256 fingerprint of the presented host key and compares it against the credential's allowlist using a constant-time comparison. 3. Refuse to connect when `acceptedHostKeys` is empty — fail-closed. Do not implement implicit TOFU. 4. Optionally provide an admin-only `dogma mirror probe-host-key ` tool that performs a single audited connection, prints the server's fingerprint, and prompts the operator to add it to the credential. This makes TOFU an explicit, audited operation. 5. Update `SshGitMirrorTest.java` and `it/mirror/*` tests to pin a test fingerprint or use the explicit trust-once tool, so the regression cannot silently return.

Related

Alias · CVE (1)

  • CVE-2026-11745 A vulnerability has been identified in centraldogma-server-mirror-git versions prior to 0.84.0, where the Git mirror SSH client does not… vulnerability

Weakness · CWE (1)

  • CWE-322 Key Exchange without Entity Authentication weakness

References