Hive CVEs
18 CVEs, 3 protected by Waratek
Overview 18 matches · 3 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
3
16.7%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
15
83.3%
blocked by ARMR today
3
16.7%
partly blocked
0
0.0%
not blocked
15
83.3%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
18
100.0%
split by
peak 5 / year
20141
No exploit published1
Low1
not blocked1
No public exploit1
20151
No exploit published1
High1
not blocked1
No public exploit1
20161
No exploit published1
High1
not blocked1
No public exploit1
20172
No exploit published2
High1
Medium1
not blocked2
No public exploit2
20185
Protected by Waratek1
No exploit published4
Critical1
High1
Medium1
Low2
blocked by ARMR today1
not blocked4
No public exploit5
20190
20200
20211
No exploit published1
Medium1
not blocked1
No public exploit1
20221
No exploit published1
High1
not blocked1
No public exploit1
20230
20243
Protected by Waratek1
No exploit published2
High1
Medium2
blocked by ARMR today1
not blocked2
No public exploit3
20253
Protected by Waratek1
No exploit published2
Medium3
blocked by ARMR today1
not blocked2
No public exploit3
201420152016201720182019202020212022202320242025
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2025-62728 | Medium | 2025-11-26 | Protected by Waratek | No public exploit | SQL injection vulnerability in Hive Metastore Server (HMS) when processing delete column statistics requests via the Thrift APIs. The vulnerability is only exploitable by trusted/authorized users/applications that are allowed to call directly the Thrift APIs. In most real-world deployments, HMS is accessible to only a handful of applications (e.g., Hiveserver2) thus the vulnerability is not exploitable. Moreover, the vulnerable code cannot be reached when metastore.try.direct.sql property is set to false. This issue affects Apache Hive: from 4.1.0 before 4.2.0. Users are recommended to upgrade to version 4.2.0, which fixes the issue. Users who cannot upgrade directly are encouraged to set metastore.try.direct.sql property to false if the HMS Thrift APIs are exposed to general public. |
| CVE-2024-29869 | Medium | 2025-01-28 | No exploit published | No public exploit | Hive creates a credentials file to a temporary directory in the file system with permissions 644 by default when the file permissions are not set explicitly. Any unauthorized user having access to the directory can read the sensitive information written into this file. Users are recommended to upgrade to version 4.0.1, which fixes this issue. |
| CVE-2024-23953 | Medium | 2025-01-28 | No exploit published | No public exploit | Use of Arrays.equals() in LlapSignerImpl in Apache Hive to compare message signatures allows attacker to forge a valid signature for an arbitrary message byte by byte. The attacker should be an authorized user of the product to perform this attack. Users are recommended to upgrade to version 4.0.0, which fixes this issue. The problem occurs when an application doesn’t use a constant-time algorithm for validating a signature. The method Arrays.equals() returns false right away when it sees that one of the input’s bytes are different. It means that the comparison time depends on the contents of the arrays. This little thing may allow an attacker to forge a valid signature for an arbitrary message byte by byte. So it might allow malicious users to submit splits/work with selected signatures to LLAP without running as a privileged user, potentially leading to DDoS attack. More details in the reference section. |
| CVE-2024-23945 | Medium | 2024-12-23 | No exploit published | No public exploit | Signing cookies is an application security feature that adds a digital signature to cookie data to verify its authenticity and integrity. The signature helps prevent malicious actors from modifying the cookie value, which can lead to security vulnerabilities and exploitation. Apache Hive’s service component accidentally exposes the signed cookie to the end user when there is a mismatch in signature between the current and expected cookie. Exposing the correct cookie signature can lead to further exploitation. The vulnerable CookieSigner logic was introduced in Apache Hive by HIVE-9710 (1.2.0) and in Apache Spark by SPARK-14987 (2.0.0). The affected components are the following: * org.apache.hive:hive-service * org.apache.spark:spark-hive-thriftserver_2.11 * org.apache.spark:spark-hive-thriftserver_2.12 |
| CVE-2022-41137 | High | 2024-12-05 | Protected by Waratek | No public exploit | Apache Hive Metastore (HMS) uses SerializationUtilities#deserializeObjectWithTypeInformation method when filtering and fetching partitions that is unsafe and can lead to Remote Code Execution (RCE) since it allows the deserialization of arbitrary data. In real deployments, the vulnerability can be exploited only by authenticated users/clients that were able to successfully establish a connection to the Metastore. From an API perspective any code that calls the unsafe method may be vulnerable unless it performs additional prerechecks on the input arguments. |
| CVE-2023-35701 | Medium | 2024-05-03 | No exploit published | No public exploit | Improper Control of Generation of Code ('Code Injection') vulnerability in Apache Hive. The vulnerability affects the Hive JDBC driver component and it can potentially lead to arbitrary code execution on the machine/endpoint that the JDBC driver (client) is running. The malicious user must have sufficient permissions to specify/edit JDBC URL(s) in an endpoint relying on the Hive JDBC driver and the JDBC client process must run under a privileged user to fully exploit the vulnerability. The attacker can setup a malicious HTTP server and specify a JDBC URL pointing towards this server. When a JDBC connection is attempted, the malicious HTTP server can provide a special response with customized payload that can trigger the execution of certain commands in the JDBC client.This issue affects Apache Hive: from 4.0.0-alpha-1 before 4.0.0. Users are recommended to upgrade to version 4.0.0, which fixes the issue. |
| CVE-2021-34538 | High | 2022-07-16 | No exploit published | No public exploit | Apache Hive before 3.1.3 "CREATE" and "DROP" function operations does not check for necessary authorization of involved entities in the query. It was found that an unauthorized user can manipulate an existing UDF without having the privileges to do so. This allowed unauthorized or underprivileged users to drop and recreate UDFs pointing them to new jars that could be potentially malicious. |
| CVE-2020-1926 | Medium | 2021-03-16 | No exploit published | No public exploit | Apache Hive cookie signature verification used a non constant time comparison which is known to be vulnerable to timing attacks. This could allow recovery of another users cookie signature. The issue was addressed in Apache Hive 2.3.8 |
| CVE-2018-1314 | Medium | 2018-11-08 | No exploit published | No public exploit | In Apache Hive 2.3.3, 3.1.0 and earlier, Hive "EXPLAIN" operation does not check for necessary authorization of involved entities in a query. An unauthorized user can do "EXPLAIN" on arbitrary table or view and expose table metadata and statistics. |
| CVE-2018-11777 | High | 2018-11-08 | No exploit published | No public exploit | In Apache Hive 2.3.3, 3.1.0 and earlier, local resources on HiveServer2 machines are not properly protected against malicious user if ranger, sentry or sql standard authorizer is not in use. |
| CVE-2018-1315 | Low | 2018-04-05 | No exploit published | No public exploit | In Apache Hive 2.1.0 to 2.3.2, when 'COPY FROM FTP' statement is run using HPL/SQL extension to Hive, a compromised/malicious FTP server can cause the file to be written to an arbitrary location on the cluster where the command is run from. This is because FTP client code in HPL/SQL does not verify the destination location of the downloaded file. This does not affect hive cli user and hiveserver2 user as hplsql is a separate command line script and needs to be invoked differently. |
| CVE-2018-1284 | Low | 2018-04-05 | No exploit published | No public exploit | In Apache Hive 0.6.0 to 2.3.2, malicious user might use any xpath UDFs (xpath/xpath_string/xpath_boolean/xpath_number/xpath_double/xpath_float/xpath_long/xpath_int/xpath_short) to expose the content of a file on the machine running HiveServer2 owned by HiveServer2 user (usually hive) if hive.server2.enable.doAs=false. |
| CVE-2018-1282 | Critical | 2018-04-05 | Protected by Waratek | No public exploit | This vulnerability in Apache Hive JDBC driver 0.7.1 to 2.3.2 allows carefully crafted arguments to be used to bypass the argument escaping/cleanup that JDBC driver does in PreparedStatement implementation. |
| CVE-2017-12625 | Medium | 2017-11-01 | No exploit published | No public exploit | Apache Hive 2.1.x before 2.1.2, 2.2.x before 2.2.1, and 2.3.x before 2.3.1 expose an interface through which masking policies can be defined on tables or views, e.g., using Apache Ranger. When a view is created over a given table, the policy enforcement does not happen correctly on the table for masked columns. |
| CVE-2016-3083 | High | 2017-05-30 | No exploit published | No public exploit | Apache Hive (JDBC + HiveServer2) implements SSL for plain TCP and HTTP connections (it supports both transport modes). While validating the server's certificate during the connection setup, the client in Apache Hive before 1.2.2 and 2.0.x before 2.0.1 doesn't seem to be verifying the common name attribute of the certificate. In this way, if a JDBC client sends an SSL request to server abc.com, and the server responds with a valid certificate (certified by CA) but issued to xyz.com, the client will accept that as a valid certificate and the SSL handshake will go through. |
| CVE-2015-7521 | High | 2016-01-29 | No exploit published | No public exploit | The authorization framework in Apache Hive 1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0 and 1.2.1, on clusters protected by Ranger and SqlStdHiveAuthorization, allows attackers to bypass intended parent table access restrictions via unspecified partition-level operations. |
| CVE-2015-1772 | High | 2015-12-21 | No exploit published | No public exploit | The LDAP implementation in HiveServer2 in Apache Hive before 1.0.1 and 1.1.x before 1.1.1, as used in IBM InfoSphere BigInsights 3.0, 3.0.0.1, and 3.0.0.2 and other products, mishandles simple unauthenticated and anonymous bind configurations, which allows remote attackers to bypass authentication via a crafted LDAP request. |
| CVE-2014-0228 | Low | 2014-11-16 | No exploit published | No public exploit | Apache Hive before 0.13.1, when in SQL standards based authorization mode, does not properly check the file permissions for (1) import and (2) export statements, which allows remote authenticated users to obtain sensitive information via a crafted URI. |