CVE-2026-56968: GNU SASL NTLM Memory Disclosure Vulnerability

Technical summary

CVE-2026-56968 stems from improper input validation in the _gsasl_ntlm_client_step function within GNU SASL's NTLM client implementation. The flaw occurs when processing challenge data from a server; if the challenge is abnormally short and lacks proper bounds checking, uninitialized or adjacent heap memory may be read and processed as part of the authentication exchange. This creates a side-channel for memory disclosure. The issue affects GNU SASL versions prior to 2.2.4. The vulnerability is classified under CWE-839 (use of insufficiently random values) and CWE-908 (use of uninitialized resource), though the primary risk stems from the lack of sanitization rather than randomness issues per se.

Business impact

The business risk depends heavily on deployment context. Organizations relying on GNU SASL for NTLM-based single sign-on or legacy authentication may inadvertently expose sensitive data residing in process memory—such as credentials, tokens, or session keys—if they authenticate against a compromised or attacker-controlled server. The impact is lower in organizations using modern authentication protocols (OAuth 2.0, Kerberos, SAML) exclusively. For those maintaining NTLM infrastructure out of necessity, the information disclosure could enable secondary attacks, such as credential theft or token forgery. The CVSS score of 3.7 (LOW severity) reflects the requirement that an attacker control the server, which is a significant practical constraint.

Affected systems

GNU SASL versions before 2.2.4 are directly affected. The vulnerability is also referenced against Debian GNU/Linux, where the affected package(s) depend on the specific Debian release's pinned version of libgsasl. Organizations using GNU SASL in application code, libraries, or system-level authentication utilities should verify their current version. Debian users should check their release-specific security advisories for patched package versions. Other distributions shipping GNU SASL should similarly consult their security channels.

Exploitability

Exploitation requires an attacker to position themselves as a network endpoint—typically a server—that the vulnerable NTLM client connects to. This means the attacker must either control a legitimate server the client trusts or intercept traffic to impersonate one. While network-accessible and requiring no user interaction beyond normal authentication, the exploitation scenario is not trivial: it demands victim-initiated outbound connection to an attacker-controlled host. The vulnerability does not provide remote code execution, only memory disclosure, further limiting its appeal as an attack vector. The KEV catalog has not listed this vulnerability, consistent with its lower severity and situational exploitability.

Remediation

Upgrade GNU SASL to version 2.2.4 or later. Debian users should apply security updates provided by their distribution for the libgsasl package, tracking the official Debian security advisories. Organizations unable to upgrade immediately should review whether NTLM authentication is necessary in their environment and consider migrating to modern authentication protocols. Network segmentation and server authentication verification (certificate pinning, mutual TLS) can reduce the risk of connecting to rogue servers in the interim.

Patch guidance

Check your current GNU SASL version using `gsasl --version` or by querying package managers. For source builds, download GNU SASL 2.2.4 or later from the official GNU SASL project repository and rebuild. Debian/Ubuntu users should run `apt update && apt upgrade` and verify that libgsasl packages are updated to the patched version; consult your release's security page for specific version numbers. Other distributions should check their security advisories. After patching, restart any services or applications that link against libgsasl to ensure the updated library is in use.

Detection guidance

Monitor network traffic for NTLM authentication exchanges, particularly those terminating at unexpected or untrusted hosts. If running GNU SASL in server-facing roles, review authentication logs for failed or abnormal NTLM handshakes that might indicate exploit attempts. On the application side, enable debug logging for SASL operations if available to detect malformed challenge responses. However, memory disclosure may be silent; focus detection efforts on traffic and behavioral anomalies rather than relying solely on log signatures.

Why prioritize this

While the vulnerability carries LOW severity by CVSS, prioritization should account for your organization's reliance on NTLM and the sensitivity of systems where NTLM authentication is in use. If NTLM is primarily legacy or isolated to non-critical systems, remediation can be scheduled in routine patch windows. If NTLM is integral to high-value authentication flows (e.g., legacy ERP systems, domain authentication), prioritize patching sooner to reduce the window of exposure to memory disclosure. The absence of KEV listing and the requirement for attacker-controlled server access further support a standard patch cadence unless you have specific threat intelligence suggesting active exploitation in your environment.

Risk score, explained

The CVSS 3.1 score of 3.7 reflects: Network-accessible attack vector (AV:N), high attack complexity due to server-control requirement (AC:H), no privileges required (PR:N), no user interaction (UI:N), and confidentiality impact limited to memory disclosure with no integrity or availability impact (C:L/I:N/A:N). The attack complexity modifier is the primary dampener; without it, the score would be substantially higher. Organizations with NTLM-heavy environments may view this as understating practical risk, but the scoring is consistent with CVSS methodology.

Frequently asked questions