CVE-2025-68637

Published Jan 7, 2026

Last updated 6 months ago

CVSS critical 9.1
SSL

Overview

Description
The Uniffle HTTP client is configured to trust all SSL certificates and disables hostname verification by default. This insecure configuration exposes all REST API communication between the Uniffle CLI/client and the Uniffle Coordinator service to potential Man-in-the-Middle (MITM) attacks. This issue affects all versions from before 0.10.0. Users are recommended to upgrade to version 0.10.0, which fixes the issue.
Source
security@apache.org
NVD status
Analyzed
Products
uniffle

Risk scores

CVSS 3.1

Type
Secondary
Base score
9.1
Impact score
5.2
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Severity
CRITICAL

Weaknesses

security@apache.org
CWE-297

Social media

Hype score
Not currently trending

  1. #VulnerabilityReport #ApacheSpark CVE-2025-68637: Critical Apache Uniffle Flaw Exposes Clusters to Eavesdropping https://t.co/mR1tNzDtJJ

    @Komodosec

    15 Feb 2026

    54 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  2. CVE-2025-68637: Critical Apache Uniffle Flaw Exposes Clusters to Eavesdropping https://t.co/VXMoh5RBRR

    @Karma_X_Inc

    12 Jan 2026

    56 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. CVE-2025-68637 [Man-in-the-Middle in the Cluster]: How Insecure SSL in Apache Uniffle Exposes Your Big Data Pipeline Read the full report on - https://t.co/Xzft0X42hm https://t.co/PJ3Bay58mJ

    @cyberbivash

    12 Jan 2026

    6 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. Critical Apache Uniffle flaw CVE-2025-68637 (CVSS 9.1) exposes Big Data clusters to MITM attacks. Update to v0.10.0 immediately to secure traffic. #ApacheUniffle #BigData #CyberSecurity #CVE202568637 #ApacheSpark #Hadoop #InfoSec #DataEngineering https://t.co/axqVIYluez

    @Daily_CyberSec

    12 Jan 2026

    206 Impressions

    1 Retweet

    1 Like

    1 Bookmark

    0 Replies

    0 Quotes

  5. 🔴 CVE-2025-68637 - Critical The Uniffle HTTP client is configured to trust all SSL certificates and disables hostname verification by default. This insecure configuration exposes all REST API communication between ... https://t.co/Eb6wiJbrgw https://t.co/2HUv1BAcHy

    @TheHackerWire

    7 Jan 2026

    36 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  6. CVE-2025-68637 The Uniffle HTTP client is configured to trust all SSL certificates and disables hostname verification by default. This insecure configuration exposes all REST API c… https://t.co/eb5Yg95FLq

    @CVEnew

    7 Jan 2026

    195 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. CVE-2025-68637: Uniffle HTTP Client: Insecure SSL Configuration https://t.co/wptj2Zrxwj

    @oss_security

    28 Dec 2025

    424 Impressions

    1 Retweet

    3 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. CVE-2025-68637 CVE-2025-68637 https://t.co/HI3da0XDr7

    @VulmonFeeds

    27 Dec 2025

    4 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. Nexus Repository 3 is vulnerable to Server-Side Request Forgery (SSRF) via the SSL Certificate Retrieval endpoint. A user holding the nexus:ssl-truststore:read permission could cause the server to initiate outbound connections to internal or otherwise restricted network hosts. This issue affects Nexus Repository 3.0.0 through versions prior to 3.94.0.•CVE-2026-7494
  2. The Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tls_handshake_1_3:handle_pre_shared_key/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tls_server_session_ticket:use/4, which crashes the session ticket handler process. An unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected. This issue affects OTP from 22.2 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.•CVE-2026-55952
  3. X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.•CVE-2026-11310
  4. X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.•CVE-2026-11999
  5. Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) mishandle the authentication of AAD (Additional Authenticated Data) with an empty ciphertext allowing a forgery of such messages. Impact summary: An attacker can forge empty messages with arbitrary AAD to the victim's application using these ciphers. AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD modes: they accept a key, nonce, optional AAD (bytes that are authenticated but not encrypted), and plaintext, and produces ciphertext plus a 16-byte tag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only if the tag is verified succesfully. In OpenSSL's provider implementation of these ciphers, the expected tag is computed only when decryption function is invoked with non-empty data. If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without invocation of the ciphertext update, which can happen when the received ciphertext length is zero, the tag is never recalculated and still holds its all-zeros value. When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty ciphertext, and all-zeros tag passes authentication under any key they do not know, single-shot. When AES-SIV is used, for mounting the attack it's necessary for the application to reuse the decryption context without resetting the key. AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since OpenSSL 3.2. No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must implement their own protocol and use the EVP interface. Also they must skip the ciphertext update when a message with an empty ciphertext arrives. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as these algorithms are not FIPS approved and the affected code is outside the OpenSSL FIPS module boundary.•CVE-2026-45446

References

Sources include official advisories and independent security research.