High Org.apache.hive CVEs with no public exploit
6 CVEs, 1 protected by Waratek
Overview 6 matches · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
1
16.7%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
5
83.3%
blocked by ARMR today
1
16.7%
partly blocked
0
0.0%
not blocked
5
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
6
100.0%
split by
peak 1 / year
20151
No exploit published1
High1
not blocked1
No public exploit1
20161
No exploit published1
High1
not blocked1
No public exploit1
20171
No exploit published1
High1
not blocked1
No public exploit1
20181
No exploit published1
High1
not blocked1
No public exploit1
20190
20200
20210
20221
No exploit published1
High1
not blocked1
No public exploit1
20230
20241
Protected by Waratek1
High1
blocked by ARMR today1
No public exploit1
2015201620172018201920202021202220232024
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| 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-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-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-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. |