Apache Storm: a read-only view exposed a write credential

Apache Storm runs data-processing jobs across many machines. A running job is called a topology, and its workers run on those machines. The workers share state through ZooKeeper, a service that stores small records for a whole cluster. One such record is a heartbeat, which says that a worker is still alive.

When ZooKeeper login is turned on, workers need a credential, a secret that lets them write these records. Storm keeps it in the topology's configuration, in a field called storm.zookeeper.topology.auth.payload, so that each worker can read it. That choice is deliberate. The pseudocode calls this field AUTH_PAYLOAD.

# When a job is submitted
submit_topology(conf):
    if not zookeeper_login_configured():
        conf.remove(AUTH_SCHEME)
        conf.remove(AUTH_PAYLOAD)
    # Otherwise the secret stays in conf.
    store(conf)

# When a user asks for the job's settings
get_topology_conf(id):
    conf = read_topology_conf(id)
    merged = merge(cluster_conf, conf)
    name = merged[TOPOLOGY_NAME]
    # Read-only users pass this check.
    check_authorization(name, merged,
                        "getTopologyConf")
    # conf still holds AUTH_PAYLOAD.
    return to_json(conf)

Storm's central server, called Nimbus, also shows a topology's configuration to users. In the pseudocode, submit_topology removes the secret only when ZooKeeper login is off. So get_topology_conf reads a configuration that still holds it. That function checks that the caller may read this topology, and then it returns the whole configuration.

The permission check works correctly, because the caller really does have read permission. The problem is the content of the answer. A read permission controls who sees a value. It does not limit what that value can do afterward.

Here the value is a write credential. ZooKeeper checks that a caller holds the secret, and it does not know how the caller got it. So a user with read-only access to a topology could write to some of its records.

The write access has limits. The Apache advisory says that the holder could forge or remove the topology's heartbeats, backpressure signals and error state. The credential did not permit changes to assignments, the records that say which machine runs which work. So the documented effect is narrower than control of the whole cluster.

The secret also reached the logs. The client that submits a topology logged it at INFO level, and the login handlers logged it at DEBUG level. So it could also reach log collectors and support bundles.

Apache gives this flaw 10.0 under CVSS 4.0. CISA gives it 6.5 under CVSS 3.1, which rates it as a read-only exposure by a low-privilege user.

Apache credits Claude agents with the discovery, and Apache Storm validated and reported it. The fix is in version 3.1.0.