Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Apache Druid’s Kerberos authenticator uses a weak fallback secret when the druid.auth.authenticator.kerberos.cookieSignatureSecret configuration is not explicitly set. In this case, the secret is generated using ThreadLocalRandom, which is not a crypto-graphically secure random number generator. This may allow an attacker to predict or brute force the secret used to sign authentication cookies, potentially enabling token forgery or authentication bypass. Additionally, each process generates its own fallback secret, resulting in inconsistent secrets across nodes. This causes authentication failures in distributed or multi-broker deployments, effectively leading to a incorrectly configured clusters. Users are advised to configure a strong druid.auth.authenticator.kerberos.cookieSignatureSecret This issue affects Apache Druid: through 34.0.0. Users are recommended to upgrade to version 35.0.0, which fixes the issue making it mandatory to set…
Recommended action: Upgrade to 35.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Severity: medium (5.8) / important Server-Side Request Forgery (SSRF), Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Apache Druid. This issue affects all previous Druid versions. When using the Druid management proxy, a request that has a specially crafted URL could be used to redirect the request to an arbitrary server instead. This has the potential for XSS or XSRF. The user is required to be authenticated for this exploit. The management proxy is enabled in Druid's out-of-box configuration. It may be disabled to mitigate this vulnerability. If the management proxy is disabled, some web console features will not work properly, but core functionality is unaffected. Users are recommended to upgrade to Druid 31.0.2 or Druid 32.0.1, which fixes the issue.
Recommended action: Upgrade to 32.0.1 or 31.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Druid allows users with certain permissions to read data from other database systems using JDBC. This functionality allows trusted users to set up Druid lookups or run ingestion tasks. Druid also allows administrators to configure a list of allowed properties that users are able to provide for their JDBC connections. By default, this allowed properties list restricts users to TLS-related properties only. However, when configuration a MySQL JDBC connection, users can use a particularly-crafted JDBC connection string to provide properties that are not on this allow list. Users without the permission to configure JDBC connections are not able to exploit this vulnerability. CVE-2021-26919 describes a similar vulnerability which was partially addressed in Apache Druid 0.20.2. This issue is fixed in Apache Druid 30.0.1.
Recommended action: Upgrade to 30.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Druid 0.22.1 and earlier, the server did not set appropriate headers to prevent clickjacking. Druid 0.23.0 and later prevent clickjacking using the Content-Security-Policy header.
Recommended action: Upgrade to 0.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Druid 0.22.1 and earlier, certain specially-crafted links result in unescaped URL parameters being sent back in HTML responses. This makes it possible to execute reflected XSS attacks. This issue is patched in version 0.23.0.
Recommended action: Upgrade to 0.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When LDAP authentication is enabled in Apache Druid 0.17.0, callers of Druid APIs with a valid set of LDAP credentials can bypass the credentialsValidator.userSearch filter barrier that determines if a valid LDAP user is allowed to authenticate with Druid. They are still subject to role-based authorization checks, if configured. Callers of Druid APIs can also retrieve any LDAP attribute values of users that exist on the LDAP server, so long as that information is visible to the Druid server. This information disclosure does not require the caller itself to be a valid LDAP user.
Recommended action: Upgrade to 0.17.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Druid allows users to read data from other database systems using JDBC. This functionality is to allow trusted users with the proper permissions to set up lookups or submit ingestion tasks. The MySQL JDBC driver supports certain properties, which, if left unmitigated, can allow an attacker to execute arbitrary code from a hacker-controlled malicious MySQL server within Druid server processes. This issue was addressed in Apache Druid 0.20.2
Recommended action: Upgrade to 0.20.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Druid includes the ability to execute user-provided JavaScript code embedded in various types of requests. This functionality is intended for use in high-trust environments, and is disabled by default. However, in Druid 0.20.0 and earlier, it is possible for an authenticated user to send a specially-crafted request that forces Druid to run user-provided JavaScript code for that request, regardless of server configuration. This can be leveraged to execute code on the target machine with the privileges of the Druid server process.
Recommended action: Upgrade to 0.20.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.