CVE-2026-25644: DataHub LDAP TLS Downgrade Vulnerability

CVE-2026-25644 Overview

CVE-2026-25644 is a Man-in-the-Middle (MITM) vulnerability affecting DataHub, an open-source metadata platform. Prior to version 1.3.1.8, the LDAP ingestion source is vulnerable to MITM attacks through TLS downgrade. This vulnerability is classified under CWE-295 (Improper Certificate Validation), indicating that the platform fails to properly validate TLS certificates during LDAP communication, allowing attackers to intercept and potentially modify sensitive authentication data.

Critical Impact

Attackers positioned on the network path between DataHub and the LDAP server can intercept authentication credentials and sensitive metadata by forcing a TLS downgrade, potentially compromising organizational directory services and user credentials.

Affected Products

• DataHub versions prior to 1.3.1.8
• DataHub LDAP Ingestion Source component
• Organizations using LDAP authentication with DataHub metadata platform

Discovery Timeline

• February 6, 2026 - CVE-2026-25644 published to NVD
• February 9, 2026 - Last updated in NVD database

Technical Details for CVE-2026-25644

Vulnerability Analysis

This vulnerability exists in DataHub's LDAP ingestion source component, which is responsible for connecting to LDAP directories to ingest metadata. The core issue stems from improper certificate validation (CWE-295) during TLS handshake negotiation with LDAP servers.

When DataHub initiates an LDAP connection, it should enforce strict TLS requirements to protect credentials and data in transit. However, vulnerable versions fail to properly validate certificates or enforce TLS, making the connection susceptible to downgrade attacks. An attacker with network access can exploit this weakness to force the connection to use weaker or no encryption, enabling interception of LDAP bind credentials and query responses.

The network-accessible nature of this vulnerability means any attacker positioned between DataHub and the LDAP server—whether on the same network segment, through ARP spoofing, or via compromised network infrastructure—can exploit this flaw without requiring any privileges or user interaction.

Root Cause

The root cause is improper certificate validation in the LDAP ingestion source. The application does not adequately verify the authenticity of the LDAP server's TLS certificate, nor does it enforce minimum TLS version requirements. This allows attackers to present fraudulent certificates or force protocol downgrades to intercept communications.

Specifically, the LDAP client configuration likely:

• Accepts self-signed or invalid certificates without proper verification
• Does not enforce a minimum TLS version (such as TLS 1.2 or higher)
• Fails to validate the certificate chain against trusted Certificate Authorities
• May allow fallback to unencrypted LDAP connections

Attack Vector

The attack vector is network-based, requiring the attacker to position themselves between the DataHub instance and the LDAP server. The attack flow typically involves:

1. Network Positioning: The attacker gains a network position allowing traffic interception (ARP spoofing, DNS poisoning, or compromised network device)
2. TLS Interception: When DataHub initiates an LDAP connection, the attacker intercepts the TLS handshake
3. Certificate Spoofing/Downgrade: The attacker either presents a fraudulent certificate or forces a downgrade to weaker encryption
4. Credential Capture: With the secure channel compromised, LDAP bind credentials and subsequent queries are exposed
5. Data Exfiltration: Sensitive directory information, user credentials, and metadata can be captured or modified

The vulnerability requires no authentication and no user interaction, making it exploitable by any network-adjacent attacker. For additional technical details, see the GitHub Security Advisory.

Detection Methods for CVE-2026-25644

Indicators of Compromise

• Unexpected LDAP connections using unencrypted protocols (port 389 instead of 636)
• TLS certificate warnings or errors in DataHub logs during LDAP ingestion
• Network traffic showing LDAP BIND operations without TLS encryption
• Unusual network devices or ARP entries indicating potential MITM positioning

Detection Strategies

• Monitor network traffic between DataHub instances and LDAP servers for unencrypted LDAP communications
• Configure network intrusion detection systems to alert on LDAP traffic over non-TLS channels
• Review DataHub application logs for certificate validation failures or TLS negotiation errors
• Implement network segmentation monitoring to detect unauthorized devices in trusted network paths

Monitoring Recommendations

• Enable verbose logging for LDAP ingestion components to capture TLS negotiation details
• Deploy network monitoring to track all LDAP traffic patterns and encryption status
• Set up alerts for any LDAP connections that do not use LDAPS (port 636) or StartTLS
• Regularly audit network infrastructure for signs of ARP spoofing or DNS poisoning attempts

How to Mitigate CVE-2026-25644

Immediate Actions Required

• Upgrade DataHub to version 1.3.1.8 or later immediately
• Audit current LDAP configurations to verify TLS enforcement settings
• Review network access controls between DataHub and LDAP infrastructure
• Rotate LDAP service account credentials if compromise is suspected

Patch Information

The DataHub project has released version 1.3.1.8 which addresses this TLS downgrade vulnerability. Organizations should upgrade to this version or later to remediate the issue. The patch ensures proper certificate validation and enforces secure TLS connections for LDAP ingestion operations.

For detailed patch information, consult the GitHub Security Advisory.

Workarounds

• Configure network firewalls to only allow encrypted LDAP traffic (port 636/LDAPS) between DataHub and LDAP servers
• Implement network segmentation to isolate DataHub and LDAP infrastructure from untrusted network segments
• Deploy mutual TLS (mTLS) at the network layer if immediate patching is not possible
• Use VPN tunnels or encrypted network overlays to protect LDAP traffic paths until the patch can be applied

# Configuration example - Verify LDAP connection uses secure port
# Ensure DataHub LDAP configuration uses LDAPS (port 636)
# Review ingestion source configuration file

# Example: Check for secure LDAP URI format in configuration
# Secure: ldaps://ldap.example.com:636
# Insecure: ldap://ldap.example.com:389

# Network-level mitigation: Block unencrypted LDAP
iptables -A OUTPUT -p tcp --dport 389 -d <LDAP_SERVER_IP> -j DROP
iptables -A OUTPUT -p tcp --dport 636 -d <LDAP_SERVER_IP> -j ACCEPT