CVE-2026-11745: CWE-322 in LY Corporation Central Dogma
# 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<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.
AI Analysis
Technical Summary
CVE-2026-11745 is a vulnerability in the centraldogma-server-mirror-git component of LY Corporation's Central Dogma product. Versions prior to 0.84.0 do not verify remote host keys when connecting via git+ssh://, enabling an attacker positioned on the network path to intercept and manipulate mirrored Git repositories through man-in-the-middle attacks. This vulnerability relates to improper key management (CWE-322). No official remediation or patch information is currently available.
Potential Impact
An attacker capable of intercepting network traffic between the Central Dogma Git mirror client and the remote Git server can exploit this vulnerability to perform man-in-the-middle attacks. This can lead to compromise of the integrity and confidentiality of mirrored repositories, potentially allowing unauthorized code injection or data exposure.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, users should consider alternative secure methods for mirroring Git repositories or implement network-level protections to prevent man-in-the-middle attacks on git+ssh:// connections.
CVE-2026-11745: CWE-322 in LY Corporation Central Dogma
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<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.
CVSS v4.0
Score 8.8high
Affected software
LY Corporation
Central Dogma
pkg:github/line/centraldogma-server-mirror-gitRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
CVE-2026-11745 is a vulnerability in the centraldogma-server-mirror-git component of LY Corporation's Central Dogma product. Versions prior to 0.84.0 do not verify remote host keys when connecting via git+ssh://, enabling an attacker positioned on the network path to intercept and manipulate mirrored Git repositories through man-in-the-middle attacks. This vulnerability relates to improper key management (CWE-322). No official remediation or patch information is currently available.
Potential Impact
An attacker capable of intercepting network traffic between the Central Dogma Git mirror client and the remote Git server can exploit this vulnerability to perform man-in-the-middle attacks. This can lead to compromise of the integrity and confidentiality of mirrored repositories, potentially allowing unauthorized code injection or data exposure.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, users should consider alternative secure methods for mirroring Git repositories or implement network-level protections to prevent man-in-the-middle attacks on git+ssh:// connections.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- LY-Corporation
- Date Reserved
- 2026-06-09T06:46:10.431Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6a394305eed863c81eeb06e6
Added to database: 06/22/2026, 14:13:25 UTC
Last enriched: 06/22/2026, 14:13:33 UTC
Last updated: 09/21/2026, 10:01:30 UTC
Views: 130
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.