CVE-2026-53561: Apache Hive Authentication Bypass Vulnerability

CVE-2026-53561 Overview

CVE-2026-53561 is an improper authentication vulnerability [CWE-287] in Apache Hive HiveServer2 SAML bearer-token validation. The flaw affects Apache Hive versions 4.0.0 through 4.2.0 running with HTTP transport and hive.server2.authentication=SAML. An unauthenticated network attacker can forge an Authorization: Bearer token and send it to the /cliservice HTTP endpoint to authenticate as any Hive user. Exploitation requires no Hive credentials, no Security Assertion Markup Language (SAML) Identity Provider (IdP) login, and no knowledge of the server signing secret. Deployments where Apache Knox handles single sign-on and HiveServer2 uses LDAP or Kerberos are not affected.

Critical Impact
An unauthenticated attacker with network access to the HiveServer2 HTTP port can obtain an authenticated session as an arbitrary Hive user, gaining query execution privileges against the data warehouse.

Affected Products

Apache Hive 4.0.0
Apache Hive 4.1.0
Apache Hive 4.2.0 (and later unreleased branches)

Discovery Timeline

2026-08-25 - CVE-2026-53561 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-53561

Vulnerability Analysis

The vulnerability resides in HiveServer2's SAML bearer-token validation logic within ThriftHttpServlet and HiveSamlAuthTokenGenerator. When a client sends an HTTP request with an Authorization: Bearer <token> header to /cliservice, HiveServer2 parses the token to extract the authenticated user identity and relay state. The pre-patch code path failed to properly enforce cryptographic validation of the token payload before extracting user attributes. An attacker who crafts a token structured in the format the parser expects can bypass the intended signature verification and obtain a HiveServer2 session bound to any username of their choice.

The vulnerability is exploitable only against deployments configured with hive.server2.transport.mode=http and hive.server2.authentication=SAML. Reverse proxies such as Apache Knox that forward unauthenticated HTTP requests directly to HiveServer2 also expose the flaw. Successful exploitation grants query and metadata access equivalent to the impersonated user.

Root Cause

The root cause is improper authentication [CWE-287] in the SAML bearer-token parsing routine. The token supplied in the Authorization header was consumed by HiveSamlAuthTokenGenerator.parse() without the correct decoding and integrity validation step. The patch introduces Base64 decoding of the raw token bytes prior to parsing, ensuring that the token structure and signature checks operate on the intended byte representation rather than on attacker-controlled formatting.

Attack Vector

The attacker requires only network reachability to the HiveServer2 HTTP endpoint. No prior credentials, IdP session, or knowledge of the SAML signing secret is needed. The attacker sends a crafted HTTP request containing a forged bearer token identifying a target Hive user. The server accepts the token and issues an authenticated session cookie.

java

// Patch: service/src/java/org/apache/hive/service/cli/thrift/ThriftHttpServlet.java
LOG.info("Successfully validated the token for user {}", user);
// token is valid; now confirm if the client identifier matches with the relay state.
Map<String, String> keyValues = new HashMap<>();
-if (HiveSamlAuthTokenGenerator.parse(token, keyValues)) {
+String decodedToken = new String(Base64.getDecoder().decode(token), java.nio.charset.StandardCharsets.UTF_8);
+if (HiveSamlAuthTokenGenerator.parse(decodedToken, keyValues)) {
   String relayStateKey = keyValues.get(HiveSamlAuthTokenGenerator.RELAY_STATE);
   if (!HiveSamlRelayStateStore.get()
       .validateClientIdentifier(relayStateKey, clientIdentifier)) {
// Source: https://github.com/apache/hive/commit/6ca06ca1104ff7462363087a867d70d546134774

The patch decodes the incoming token from Base64 before invoking the parser, forcing validation to operate on the canonical token structure and blocking the forgery technique.

Detection Methods for CVE-2026-53561

Indicators of Compromise

HTTP requests to /cliservice containing an Authorization: Bearer header from source IP addresses not associated with the organization's SAML IdP or user population.
HiveServer2 log entries showing Successfully validated the token for user <name> immediately followed by queries from IP addresses that never completed a SAML IdP redirect flow.
New or unexpected HiveServer2 sessions authenticated as privileged users during periods when those users are known to be inactive.

Detection Strategies

Correlate HiveServer2 access logs with IdP authentication events. Sessions established without a preceding IdP assertion indicate potential forgery.
Alert on repeated Authorization: Bearer requests to /cliservice originating from IP addresses outside expected client ranges.
Monitor for anomalous Hive query patterns from user accounts that historically access the warehouse only through business intelligence tools.

Monitoring Recommendations

Enable verbose authentication logging in HiveServer2 and forward logs to a centralized analytics platform.
Track the ratio of successful bearer-token authentications to SAML IdP-issued assertions; a divergence suggests token forgery.
Inspect Apache Knox access logs when Knox fronts HiveServer2, focusing on requests that reach /cliservice without a valid Knox SSO cookie.

How to Mitigate CVE-2026-53561

Immediate Actions Required

Upgrade Apache Hive to version 4.2.1, which contains the fix committed in Apache Hive commit 6ca06ca.
Restrict network access to the HiveServer2 HTTP port so that only trusted proxies and application hosts can reach /cliservice.
Audit HiveServer2 and Apache Knox logs for unexpected bearer-token authentication events since the deployment of Hive 4.0.0.

Patch Information

The fix is tracked as Apache JIRA issue HIVE-29653 and merged in pull request #6534. Users must upgrade to Apache Hive 4.2.1 or later. Additional discussion is available on the Apache mailing list thread.

Workarounds

Switch hive.server2.authentication from SAML to LDAP or KERBEROS until the upgrade is complete, delegating SSO to Apache Knox where applicable.
Place HiveServer2 behind an authenticating reverse proxy that terminates SAML and forwards only validated requests with server-controlled headers.
Apply network access control lists that block direct client connections to the HiveServer2 HTTP port from untrusted networks.

bash

# Example: enforce Kerberos authentication as an interim workaround
# in hive-site.xml
# <property>
#   <name>hive.server2.transport.mode</name>
#   <value>http</value>
# </property>
# <property>
#   <name>hive.server2.authentication</name>
#   <value>KERBEROS</value>
# </property>

# Restrict the HiveServer2 HTTP port at the host firewall
iptables -A INPUT -p tcp --dport 10001 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 10001 -j DROP