Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings

Vulnerability

Apache Solr versions prior to 8.8.2, when configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, fail to treat security.json as a sensitive path. If an optional read-only user is configured, that user can read the znode. Additionally, with any ZkACLProvider, if security.json already exists, Solr does not automatically update its ACLs during startup [1][2].

Exploitation

For exploitation, an attacker must have network access to the ZooKeeper ensemble and have credentials for a read-only digest user (configured via -DzkDigestReadonlyUsername). If the system is started without pre-existing security.json, the znode is created with ACLs granting read access to that read-only user. The attacker can then authenticate as the read-only user and read the security.json znode contents. No additional authentication to Solr itself is required for this read operation on ZooKeeper [2].

Impact

Successful exploitation allows the attacker to read the security.json file, which may contain sensitive data such as authentication realm configurations and, in some implementations, hashed credentials. While the hashing algorithm used by Solr is not computationally slow (like bcrypt), the exposure of these hashes could facilitate offline brute-force attacks, leading to further compromise of the Solr authentication mechanism. The confidentiality of the security configuration is breached [2].

Mitigation

Upgrade to Apache Solr version 8.8.2 or later, which was released concurrently with the CVE publication (2021-04-13) [1]. In the fixed version, Solr correctly sets ACLs on the security.json znode during startup and restricts read access from the read-only user. No workaround is explicitly documented; the upgrade is the recommended mitigation. The vulnerability is also tracked under SOLR-15249 in the Apache Solr issue tracker [2].