Apache Impala CVE-2026-56207

Requires the target Apache Impala (4.0.0-4.5.1) to have SAML2 authentication enabled on the hs2-http (HiveServer2 over HTTP) interface - this is the specific feature that carries the unverified Bearer token step and is not enabled by default. Given that configuration, exploitation is remote and unauthenticated (PR:N): the attacker needs network reachability to the hs2-http port and the ability to supply a Bearer token, but no valid credentials or signing key, because the signature is never checked. Limiting factors: deployments not using SAML2 on hs2-http are not exploitable via this path, and network segmentation restricting hs2-http reachability reduces exposure.

The CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), reflecting a trivially exploitable, network-reachable authentication bypass once the vulnerable path is used. However, EPSS is only 0.16% (5th percentile) and there is no KEV listing or known public exploit, indicating no observed widespread exploitation to date. The critical caveat the raw score hides is a configuration prerequisite: exploitation requires SAML2 authentication to be enabled on the hs2-http interface, which is a deliberate, non-default deployment choice, so the real-world exposed population is narrower than a 9.8 suggests. For organizations that DO run SAML2 SSO on hs2-http this is a genuine high priority (full identity spoofing to any user, including admins); for those that do not, effective risk is low. The 'Information Disclosure' tag understates the impact - this is impersonation/authentication bypass affecting confidentiality AND integrity, not read-only disclosure.

An attacker who can send HTTP requests to an Impala hs2-http endpoint configured for SAML2 SSO submits a Bearer token whose asserted username has been changed to a privileged account (e.g., an admin or another analyst). Because the signature is never validated, Impala accepts the altered identity and the attacker executes queries and accesses data as that user. No public proof-of-concept is currently identified, but the AV:N/AC:L/PR:N vector implies exploitation is straightforward against a vulnerable configuration.