GHSA-vjfw-cpmh-xwv3: Maven/com.linecorp.centraldogma:centraldogma-server-mirror-git vulnerability

Published Sep 11, 2026
·
Updated

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 knownhosts 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/C1sshhostkeybypass/ 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 LOCALTOREMOTE: 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 REMOTETOLOCAL: 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<String> 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 <remote> 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.

Affected Software

1 affected componentFixes available
maven/com.linecorp.centraldogma:centraldogma-server-mirror-git<0.84.0
0.84.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/com.linecorp.centraldogma:centraldogma-server-mirror-git to a version that resolves this vulnerability.

    Fixed in 0.84.0
  2. Configuration

    Replace the Apache MINA SSHD ServerKeyVerifier accept-all lambda at SshGitMirror.java:149 (currently `... -> true`) with a verifier that computes the SHA-256 fingerprint of the presented SSH server host key and compares it against the mirror credential’s allowlist (`acceptedHostKeys`) using constant-time comparison; do not implement implicit TOFU and refuse the connection when `acceptedHostKeys` is empty (fail-closed).

    Central Dogma Git mirror SSH client (SshGitMirror.java) serverKeyVerifier = Verifier that computes SHA-256 fingerprint of presented host key and compares it against credential allowlist using constant-time comparison (fail-closed when acceptedHostKeys is empty)
  3. Configuration

    Add an `acceptedHostKeys: List<String>` field to `SshKeyCredential` and `PasswordCredential` (or to `MirrorContext`) so outbound `git+ssh://` mirror connections can be pinned to specific trusted server host key SHA-256 fingerprints.

    Central Dogma credentials / mirror configuration acceptedHostKeys (new field) = Add `acceptedHostKeys: List<String>` to `SshKeyCredential` and `PasswordCredential` (or to `MirrorContext`)
  4. Configuration

    Ensure the mirror SSH client does not rely on `known_hosts` or `~/.ssh/config` fallbacks, and that there is no repo-wide reliance on unpinned trust mechanisms (no `knownHosts`, `KnownHostsServerKeyVerifier`, `StaticServerKeyVerifier`, or `RequiredServerKeyVerifier`); host key verification must come from `acceptedHostKeys` allowlists. (This aligns with the described accompanying lines that disable known_hosts and ~/.ssh/config fallbacks.)

    Central Dogma mirror connector hardening known_hosts / ssh config fallbacks = Disabled (as currently implemented)
  5. Operational

    Add/update tests to prevent silent regression: update `SshGitMirrorTest.java` and `it/mirror/*` tests to pin a test server host key fingerprint (SHA-256 form) or to use the explicit admin-only `dogma mirror probe-host-key <remote>` trust-once tool so regressions cannot reintroduce the accept-all verifier behavior.

Event History

Sep 11, 2026
Advisory Published
via GitHub·08:45 PM
Data Sourced
via GitHub·08:45 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed?

Deployments using Central Dogma's Git mirror functionality with git+ssh:// mirror URLs are exposed. The affected SSH client is used for every outbound SSH mirror connection.

2

What does an attacker need to exploit this?

An attacker needs to be able to intercept or redirect an outbound SSH connection to a Git mirror, or otherwise present a malicious SSH server in place of the intended host. Because any presented host key is accepted, the client does not authenticate the remote server.

3

Are default SSH trust mechanisms available as a mitigation?

No. The implementation disables known_hosts and ~/.ssh/config fallbacks, and the available data indicates there is no host-key pinning or verification mechanism in server-mirror-git. Operators have no opt-in configuration to enable verification.

4

How can I determine whether my environment is affected?

Review mirror configuration for git+ssh:// URLs and confirm whether the Central Dogma Git mirror component is in use. Such outbound mirror connections blindly trust the remote host key under the described implementation.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203