CVE-2026-11745 - Central Dogma Git mirror SSH host-key verification bypass

CVE-2026-11745 affects centraldogma-server-mirror-git before 0.84.0. The Git mirror SSH client accepts git+ssh:// remotes without verifying the remote host key, so an on-path attacker can impersonate the mirror target, inject commits into mirrored repositories, or capture credentials used by the mirror job.

Exposure exists when the repository or deployment owns Central Dogma Git mirroring over SSH, not merely because Central Dogma is installed.

When to use it

Use this recipe when a repository deploys Central Dogma Git mirrors over SSH or owns equivalent mirror workers that fetch code/config from remote repositories. It is designed for source-code/deployment remediation, SSH host-key trust review, mirror credential rotation, repository provenance audit, and evidence that mirror jobs fail closed on host-key mismatch.

Inputs

  • Central Dogma mirror package version, Maven/Gradle lock state, mirror config, git+ssh:// remotes, known-hosts or host-key pinning, deployment manifests, and generated dependency/SBOM reports.
  • Source/config paths that define mirror jobs, SSH credentials, host-key policy, repository sync ownership, network placement, or wrapper code around mirror execution.
  • Regression or deployment checks for fixed versions, pinned host keys, mismatch failures, mirror credential rotation notes, and repository integrity review.
  • Boundary evidence: mirrored repositories, credential scope, commit provenance checks, on-path network risk, logs, mirror worker owner, and rollout owner.

Affected versions

Package Vulnerable versions Fixed versions
centraldogma-server-mirror-git < 0.84.0 0.84.0+

Indicator-of-exposure

  • The repository resolves centraldogma-server-mirror-git < 0.84.0.
  • Git mirror definitions use git+ssh:// remotes.
  • Mirror jobs run from networks where on-path tampering is plausible.
  • No explicit host-key pinning or known-hosts enforcement exists in owned configuration or wrapper code.

Quick checks:

rg -n "centraldogma|mirror|git\\+ssh|known_hosts|StrictHostKeyChecking|ssh" .

Windows:

rg -n "centraldogma|mirror|git\\+ssh|known_hosts|StrictHostKeyChecking|ssh" .

Do not validate exposure by intercepting live SSH traffic.

Remediation strategy

  • Upgrade to 0.84.0+.
  • Pin remote host keys for mirrored repositories and fail closed on host-key mismatch.
  • Prefer network paths that reduce on-path exposure and segment mirror workers from untrusted networks.
  • Rotate SSH keys or tokens used by affected mirror jobs after the upgrade if there is any chance they traversed an untrusted path.
  • Review recent mirror syncs, commit provenance, and repository integrity for unexplained changes.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-11745 / GHSA-vjfw-cpmh-xwv3, a Central Dogma Git
mirror flaw where `git+ssh://` remotes are accepted without host-key
verification. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Central Dogma, enforces
  host-key verification, hardens mirror configuration, and documents key
  rotation and integrity-review follow-up, or
- TRIAGE.md if this repository does not control an affected Central Dogma Git
  mirror runtime or configuration.

## Rules

- Scope only CVE-2026-11745 and directly related SSH mirror trust,
  known-hosts, credential, and integrity-verification paths.
- Treat SSH keys, known_hosts material, mirrored repositories, and sync logs as
  sensitive.
- Do not attempt man-in-the-middle testing against a live mirror.
- Do not disable SSH mirroring silently if it is a required product function;
  use triage if safe hardening is out of scope.
- Do not auto-merge.

## Steps

1. Inventory every controlled Central Dogma Git mirror dependency, image,
   config file, and mirror definition.
2. Resolve versions. Any `centraldogma-server-mirror-git < 0.84.0` is
   vulnerable.
3. Identify every `git+ssh://` mirror target and how its host key is currently
   validated.
4. If this repository does not own the mirror runtime or configuration, stop
   with `TRIAGE.md`.
5. Upgrade all controlled Central Dogma mirror components to `0.84.0+`.
6. Add or enforce host-key pinning/known-hosts configuration for every SSH
   mirror target.
7. Ensure mirror setup docs and examples require explicit trust material rather
   than permissive defaults.
8. Add safe regression checks showing SSH mirror configuration fails closed when
   trust material is absent.
9. Add a PR body section named `CVE-2026-11745 operator actions` covering:
   - versions before and after;
   - which mirrors use SSH;
   - how host keys are now pinned;
   - whether credentials need rotation;
   - what repository integrity logs operators should review.
10. Run relevant validation: dependency resolution, config render, mirror
    configuration tests, and deployment diff checks.
11. Use PR title:
    `fix(sec): harden Central Dogma SSH mirror trust`.

## Stop conditions

- No controlled SSH mirror path exists.
- Mirror host-key material is managed in another system and cannot be safely
  changed here.
- Verification would require intercepting or tampering with live SSH traffic.

Output contract

  • A reviewer-ready PR or change request that upgrades Central Dogma mirror components, pins/validates SSH host keys, refreshes deployment artifacts, and documents credential/provenance review.
  • Or a TRIAGE.md file that lists inspected dependencies/config, owner, observed version, SSH mirror boundary, affected credentials, required fix, and residual risk.
  • The output must include exact validation commands and must not intercept live SSH traffic, expose mirror private keys, or mutate mirrored repositories during validation.

Verification - what the reviewer looks for

  • No controlled Central Dogma mirror runtime resolves < 0.84.0.
  • SSH mirrors require explicit host trust material.
  • Documentation and examples no longer imply permissive host acceptance.
  • Operator notes cover integrity review and credential rotation where needed.

Watch for

  • Upgrading the package but leaving unmanaged mirror definitions untouched.
  • Pinning host keys in one environment while omitting staging or disaster recovery mirrors.
  • Forgetting post-upgrade integrity review of previously mirrored commits.

References