SURIQ
If you run Central Dogma across more than one server, check one setting before you finish this paragraph. Versions before 0.84.0 can guard the entire cluster with a password that is printed in the project's own public source code, and they do it without telling you.
Central Dogma is an open-source service-configuration store from LY Corporation, the company behind the LINE messaging app. Teams use it to hold application settings and hand them out to running services. In its high-availability setup, several Central Dogma servers stay in sync through an embedded copy of ZooKeeper, the coordination service that keeps a cluster's nodes agreeing on shared state. That sync channel is meant to be locked with a secret you choose.
The flaw, tracked as CVE-2026-11746 and rated 9.4 out of 10, is about what happens when you never choose one. Rather than refuse to start, the server quietly drops in a built-in default: the string ch4n63m3, leetspeak for "change me." There is no warning, no log line, no startup error. LY Corporation's own security advisory confirms the value lives in the public repository, so anyone can read it.
Why a silent default is worse than a normal bug
A coding mistake is an accident you patch and move on from. A credential that switches itself on without a word is a design that turns one skipped configuration step into an open door. The operator who omits replication.secret gets a cluster that boots, passes health checks, and looks completely normal. Nothing signals that the lock is one everybody already has a key to. The insecure path is the frictionless one, which is exactly how these defaults survive for years.
Who is exposed, and from where
Two things have to be true. Replication has to be set to ZooKeeper mode, the usual choice for any production cluster, and replication.secret has to be empty or missing. A standalone, single-node install does not replicate and is not affected. The advisory lays out two routes in.
- From the same machine. A local attacker can speak to the ZooKeeper port bound to localhost using the known secret and read the full sync log, which carries configuration data and key-management commands.
- From a neighbor on the network. Where the cluster's coordination ports are reachable by other workloads, an attacker can pretend to be a peer, join the group, and push commands that every node then runs.
The severity vector marks this as an adjacent-network attack rather than an internet-wide one. That distinction comforts fewer people than it should. In a shared Kubernetes cluster, "adjacent" can mean a pod that belongs to a completely different team sitting one network hop away from your coordination ports. The blast radius the advisory describes is the whole group of replicas.
The part that should worry you most
Central Dogma can encrypt what it stores, and the commands that rotate its master encryption key travel through the same ZooKeeper channel this secret protects. Read the sync log and you can see that key-management traffic. The practical result: "our configuration is encrypted at rest" is not an answer to this problem. An attacker who joins the group can also inject commands that replicate to every node, so this is not only an exposure of data but a path to changing it across the cluster.
What to do now
Treat any cluster that ran without an explicit secret as already exposed, then work in this order.
- Upgrade to 0.84.0 or later. The fix deletes the built-in secret, demands an explicit value of at least 32 characters, refuses obvious placeholders, and fails to start if replication is on without one.
- Set
replication.secretto a unique, random value and roll it out to every node. - If you ever ran on the default, rotate the secret and assume the old one is public, because it always was.
- Audit the commands that moved through the cluster while the default was active, with extra attention to master-key rotation.
- Restrict network reach to the client and coordination ports so only cluster members can talk to them.
There is no gentle workaround on an unpatched version. Your only real interim choices are to turn ZooKeeper replication off entirely or to set a proper secret and rotate it, then upgrade as soon as you can.
The same story, a different name
We keep writing this post. A Squid proxy weakness leaked other users' credentials and the headline update did not close it. Gravity SMTP handed out live email API keys to anyone who asked. An authentication library let a stranger sign in with nothing but an email address. The pattern under all of them is the same: when the secret is the problem, the patch is only half the work. Patching removes the default. It cannot un-publish a value that sat in a public repository for as long as the feature existed. Rotate first, patch second, then go read what passed through your cluster while the door stood open.