Total
9 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-45384 | 1 Apache | 1 Druid | 2024-11-21 | N/A | 5.3 MEDIUM |
| Padding Oracle vulnerability in Apache Druid extension, druid-pac4j. This could allow an attacker to manipulate a pac4j session cookie. This issue affects Apache Druid versions 0.18.0 through 30.0.0. Since the druid-pac4j extension is optional and disabled by default, Druid installations not using the druid-pac4j extension are not affected by this vulnerability. While we are not aware of a way to meaningfully exploit this flaw, we nevertheless recommend upgrading to version 30.0.1 or higher which fixes the issue and ensuring you have a strong druid.auth.pac4j.cookiePassphrase as a precaution. | |||||
| CVE-2022-28889 | 1 Apache | 1 Druid | 2024-11-21 | 4.3 MEDIUM | 4.3 MEDIUM |
| 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. | |||||
| CVE-2021-44791 | 1 Apache | 1 Druid | 2024-11-21 | 4.3 MEDIUM | 6.1 MEDIUM |
| 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. | |||||
| CVE-2021-36749 | 1 Apache | 1 Druid | 2024-11-21 | 4.0 MEDIUM | 6.5 MEDIUM |
| In the Druid ingestion system, the InputSource is used for reading data from a certain data source. However, the HTTP InputSource allows authenticated users to read data from other sources than intended, such as the local file system, with the privileges of the Druid server process. This is not an elevation of privilege when users access Druid directly, since Druid also provides the Local InputSource, which allows the same level of access. But it is problematic when users interact with Druid indirectly through an application that allows users to specify the HTTP InputSource, but not the Local InputSource. In this case, users could bypass the application-level restriction by passing a file URL to the HTTP InputSource. This issue was previously mentioned as being fixed in 0.21.0 as per CVE-2021-26920 but was not fixed in 0.21.0 or 0.21.1. | |||||
| CVE-2021-26920 | 1 Apache | 1 Druid | 2024-11-21 | 4.0 MEDIUM | 6.5 MEDIUM |
| In the Druid ingestion system, the InputSource is used for reading data from a certain data source. However, the HTTP InputSource allows authenticated users to read data from other sources than intended, such as the local file system, with the privileges of the Druid server process. This is not an elevation of privilege when users access Druid directly, since Druid also provides the Local InputSource, which allows the same level of access. But it is problematic when users interact with Druid indirectly through an application that allows users to specify the HTTP InputSource, but not the Local InputSource. In this case, users could bypass the application-level restriction by passing a file URL to the HTTP InputSource. | |||||
| CVE-2021-26919 | 1 Apache | 1 Druid | 2024-11-21 | 6.5 MEDIUM | 8.8 HIGH |
| 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 | |||||
| CVE-2021-25646 | 1 Apache | 1 Druid | 2024-11-21 | 9.0 HIGH | 8.8 HIGH |
| 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. | |||||
| CVE-2020-1958 | 1 Apache | 1 Druid | 2024-11-21 | 3.5 LOW | 6.5 MEDIUM |
| 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. | |||||
| CVE-2024-45537 | 1 Apache | 1 Druid | 2024-10-01 | N/A | 6.5 MEDIUM |
| 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. | |||||