Apache Druid, a high-performance analytics data store, includes a Kerberos authenticator component that relies on a secret to sign authentication cookies. In versions up to 34.0.0, if the configuration parameter 'druid.auth.authenticator.kerberos.cookieSignatureSecret' is not explicitly set by the administrator, the system falls back to generating a secret using Java's ThreadLocalRandom. ThreadLocalRandom is a pseudo-random number generator designed for performance and concurrency but is not cryptographically secure, making the generated secret predictable or brute-forceable by attackers. This weakness can allow an attacker to forge authentication tokens or bypass authentication controls, compromising the confidentiality and integrity of the system. Furthermore, because each process generates its own fallback secret independently, in multi-node or distributed Apache Druid clusters, the secrets differ across nodes, causing authentication failures and effectively misconfiguring the cluster. This can lead to availability issues and operational disruptions. The vulnerability is classified under CWE-338 (Use of Cryptographically Weak PRNG). The Apache Software Foundation addressed this issue in version 35.0.0 by requiring the explicit setting of a strong 'cookieSignatureSecret' and preventing services from starting if it is missing, thereby eliminating the fallback to a weak secret. No known exploits are reported in the wild as of now, but the risk remains significant due to the potential for token forgery and authentication bypass.

For European organizations leveraging Apache Druid for analytics, especially those using Kerberos authentication, this vulnerability poses a risk of unauthorized access through forged authentication cookies. Attackers could impersonate legitimate users or services, leading to data confidentiality breaches and potential data manipulation. The inconsistent fallback secrets across nodes in distributed deployments can cause authentication failures, resulting in service outages or degraded cluster functionality, impacting availability. Organizations in sectors with strict data protection regulations (e.g., GDPR) could face compliance issues and reputational damage if exploited. The risk is heightened in environments where the default configuration is used without setting a strong secret, which may be common in less mature deployments or during rapid scaling. Given Apache Druid's adoption in finance, telecommunications, and government sectors across Europe, the impact could be widespread, affecting critical analytics infrastructure and decision-making processes.

European organizations should immediately upgrade Apache Druid to version 35.0.0 or later, which enforces the mandatory configuration of a strong 'druid.auth.authenticator.kerberos.cookieSignatureSecret'. Until upgrade is possible, administrators must explicitly set a cryptographically secure secret in this configuration parameter to prevent fallback to the weak PRNG. The secret should be generated using a cryptographically secure random number generator (e.g., Java's SecureRandom) and be of sufficient length and complexity to resist brute force attacks. Additionally, organizations should audit their current Druid deployments to identify any instances running vulnerable versions with default or unset secrets. Monitoring authentication logs for suspicious token usage or repeated authentication failures can help detect exploitation attempts. For distributed clusters, ensure consistent secret configuration across all nodes to avoid authentication inconsistencies. Finally, incorporate this configuration check into deployment automation and configuration management to prevent recurrence.