Central Dogma Advisory: Hard-Coded ZooKeeper Secret Enables Cluster Takeover in HA Deployments

What happened

A GitHub Security Advisory (GHSA-2j95-gqxf-v3vg, tracked as CVE-2026-11746) reports that com.linecorp.centraldogma:centraldogma-server ships a hard-coded ZooKeeper replication secret, ch4n63m3, that is silently substituted whenever an operator omits the replication.secret config value. According to the advisory, this default is used for both the client-facing SASL authentication context and the inter-peer quorum/learner SASL contexts of Central Dogma's embedded ZooKeeper instance — a single leaked credential that authenticates against both surfaces. A working proof-of-concept is public, demonstrating unauthenticated read access to the replication log over the loopback-bound client port when the config default is left in place.

Why it matters

Central Dogma does not connect to an external ZooKeeper ensemble — each replica embeds its own ZooKeeper server, so the cluster's inter-replica network effectively is the ZooKeeper ensemble. The advisory states this is applicable only when replication.method is set to ZOOKEEPER (the standard HA production configuration); standalone (NONE) deployments are not affected. Per the advisory, the replication log carries the full stream of committed changes, including session/master-key management commands, so an attacker who obtains the secret could read sensitive replicated data and, in configurations where the quorum port is reachable beyond loopback, potentially attempt to join the cluster as a peer. The advisory notes the fix path requires the code to fail closed instead of silently defaulting, and that credential rotation alone may not be sufficient remediation if the log was accessed during an exposure window.

Who is affected

• Any deployment of centraldogma-server running with replication.method: ZOOKEEPER that has not explicitly set a unique, non-default replication.secret
• Standalone (NONE replication) deployments are explicitly called out as not applicable

What defenders should do now

• Check every Central Dogma cluster configuration for an explicitly set, unique replication.secret — do not assume a value was set just because the config file references the key
• If the secret was never set, treat it as compromised: rotate it and review replication logs for the exposure window per the advisory's guidance
• Audit network exposure of ZooKeeper client, quorum, and election ports associated with Central Dogma replicas — the advisory notes client-port binding is loopback-only by design, but quorum/election ports bind to the configured replication host and may be reachable on shared networks (e.g., shared VPC/VLAN, multi-tenant Kubernetes)
• Hunt for unexpected connections to Central Dogma's ZooKeeper ports (default client port, quorum, and election ports) from unfamiliar hosts or processes, particularly any SASL authentication attempts using the super username
• Track vendor guidance for a patched release that removes the hard-coded default and enforces a mandatory, validated secret

Developing intel

This is based on a same-day GitHub Security Advisory with a public PoC for the read-only attack path; the more severe peer-impersonation scenario is documented in the advisory but was not weaponized. Details, including a patched release, may evolve — refer to the original advisory for authoritative updates: GHSA-2j95-gqxf-v3vg.