CVE-2016-3083
HighSummary
Apache Hive (JDBC + HiveServer2) before version 1.2.2 and 2.0.x before 2.0.1 does not verify the common name attribute of the certificate during SSL connection setup. This allows a certificate issued for a different domain to be accepted, potentially leading to man-in-the-middle attacks.
Risk Assessment
The lack of common name verification increases the risk of data interception by unauthorized entities, which can lead to serious security breaches within the organization.
Recommendation
It is recommended to upgrade Apache Hive to version 1.2.2 or 2.0.1 and enable common name verification in the SSL configuration.
Related vulnerabilities
- CVE-2026-82843Critical
The WP OAuth Server (Login with WordPress) WordPress plugin before 6.4.0 does not bind the OpenID Connect identity assertion it issues to the authorization grant being exchanged, returning instead the assertion belonging to whichever user authenticated most recently. This allows users with the Subscriber role and above to obtain a validly signed identity assertion for another user, including an administrator, and authenticate as them at any application that uses the site for single sign-on.
- CVE-2026-75799Critical
The YAHMAN Add-ons WordPress plugin before 0.9.31 does not validate the type of the remote files it caches in a publicly accessible directory, allowing unauthenticated attackers to write arbitrary PHP files on the server and achieve RCE when the relevant feature is enabled.
- CVE-2026-96257Critical
A flaw has been found in Fast FAC1203R Gigabit Edition 2.0.4 in the copy_msg_element function of the Device Discovery Service component. Input manipulation can lead to a stack-based buffer overflow, and the attack can be executed remotely. The exploit has been published and may be used; the vendor did not respond to the disclosure.
- CVE-2026-18169Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to obtain sensitive information due to improper validation of symbolic links.
- CVE-2026-18163Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to execute arbitrary code due to improper deserialization of untrusted data.
- CVE-2026-18162Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to execute arbitrary code due to improper neutralization of user-controlled input within the new Function constructor.
- CVE-2026-19202Critical
A caching flaw in the toolbox-core package of the mcp-toolbox-sdk-python SDK causes the same Google ID token to be cached and reused across different audiences. If an application uses the SDK to authenticate to two or more different audiences within the same process, the module-level token cache fails to key its cached tokens by the requested audience. Consequently, a valid, unexpired token minted for a sensitive service (Service A) can be retrieved from the cache and sent to a secondary service (Service B). An attacker who operates, compromises, or monitors traffic to Service B can capture this token and replay it to impersonate the victim application against Service A.
- CVE-2026-17645Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to gain elevated privileges due to improper privilege management.
- CVE-2026-17635Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to perform unauthorized actions due to improper configuration of HTTP method-based security constraints.
- CVE-2026-17472Critical
IBM Concert 1.0.0 through 3.0.0 could allow a remote authenticated attacker to access or modify unauthorized resources due to the use of wildcards in RBAC permission definitions.
Original NVD description (English source)
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.

