CVE-2026-6908

Overview

Drupal is an open-source content management system known for its flexibility, robust features, and strong community support. Organizations of all sizes use it to build and manage dynamic websites and web applications.

The Drupal 7 LDAP module has an information-disclosure vulnerability that can write a service account's bind password into the site's database log in plain text. When the LDAP server connection is misconfigured in a particular way and an administrator uses the module's "Test" function, the module logs the password as part of an error message. That log is visible in the site's admin reports and is stored in the database, so it also ends up in any database backup. This is especially damaging for sites that use secure secret storage (such as Key, Lockr, or Pantheon Secrets) to keep the password out of the database in the first place, since logging it in the clear defeats that protection. The exposure requires a specific misconfiguration and administrator action rather than a remote attack, and the fix simply stops the password from being logged.

Information exposure, often referred to as information disclosure or sensitive data exposure, can be a high-severity vulnerability where applications inadvertently reveal confidential or useful details to unauthorized parties due to inadequate protections, such as weak cryptography, misconfigurations, or flawed access controls. According to OWASP, this can stem from transmitting data in clear text, using outdated cryptographic algorithms, improper key management, or failing to sanitize error messages and responses, allowing attackers to intercept, infer, or directly access information like configurations, server details, user credentials, or API keys. It aligns with OWASP Top 10 categories including A01:2021 – Broken Access Control (ranked first) and A05:2021 – Security Misconfiguration (ranked fifth), as well as evolving from the 2017 A3: Sensitive Data Exposure, now encompassed in A02:2021 – Cryptographic Failures (ranked second). Attackers exploit this through techniques like network sniffing, analyzing error outputs, or leveraging misconfigured endpoints, potentially leading to escalated attacks.

Ramifications include:

• Data breaches
• Identity theft
• Financial losses
• Further exploits
• Legal penalties, and
• Reputational damage.

‍

Details

Module Info

• Product: Drupal 7
• Affected packages: LDAP
• Affected versions: >=7.x-2.0 <7.x-2.7
• Repository: https://git.drupalcode.org/project/ldap
• Published packages: https://www.drupal.org/project/ldap
• Package manager: composer
• Fixed in: LDAP NES 7.2.7

‍

Vulnerability Info

This low-severity vulnerability is found in versions of the LDAP module for Drupal 7 sites from 7.x-2.0 up to and including 7.x-2.6.

The Drupal 7 LDAP module contains an information-disclosure vulnerability in the LdapServer::bind() method (around line 434 of ldap_servers/LdapServer.class.php, introduced in 2013): when a non-anonymous bind is attempted with a DN that is empty but a password that is present, the error-handling branch passes both the username and the password into watchdog(), writing the plaintext bind password into the database log (dblog), where it is visible in the UI's log report and persisted in the database — and therefore in any database backup — in the clear.

This is especially damaging for sites using the Key/Lockr/Pantheon Secrets integration patch, since it stores only a key label rather than the raw password precisely to keep the secret out of the database, and logging the resolved password here defeats that protection. Exploitation requires a specific misconfiguration (an empty DN with a non-empty password) triggered via the LDAP server's "Test" function, so it is not remotely exploitable, but the fix is simply to stop logging the password — separating the empty-DN and empty-password checks and emitting a standard error message (or logging only the username) instead.

Addressing the Issue

Users of this module should apply one of the following mitigations:

• If the risk is unacceptable, avoid triggering the LDAP server "Test" function on misconfigured servers, and remove any exposed passwords already written to the database log.
• Ensure LDAP server bind settings are correctly configured (a valid, non-empty bind DN paired with the bind password) so the vulnerable error path is never reached.
• Restrict access to the site's log reports (admin/reports/dblog) and to LDAP server administration to trusted administrators, and rotate any bind password that may have been logged.
• Sign up for post-EOL security support—HeroDevs customers get immediate access to a patched version of this module.

‍

Credits

• Caroline Boyden (cboyden)