CVE-2026-116200 in Snipe-IT
Summary
by MITRE • 10/25/2026
Snipe-IT before 8.6.3 ignores the ldap_start_tls() return value in Ldap::connectToLdap(), allowing on-path attackers to force cleartext LDAP binds. Attackers can answer the StartTLS request with a protocol error to capture service-account credentials and end-user login passwords.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Snipe-IT versions prior to 8.6.3 represents a critical failure in cryptographic implementation within its Lightweight Directory Access Protocol integration module. Specifically, the flaw resides in the Ldap::connectToLdap() function where the application fails to validate the return value of the ldap_start_tls() operation. This oversight creates a scenario where the software proceeds with establishing an LDAP connection without ensuring that the transport layer has been successfully upgraded from plaintext to encrypted TLS. In standard secure communication protocols, initiating a StartTLS request is merely the first step; the client must verify that the server responds positively and completes the handshake before transmitting sensitive data. By ignoring this return value, Snipe-IT effectively allows the connection to fall back or remain in an unencrypted state even when encryption was requested, thereby nullifying the intended security controls designed to protect data in transit.
From a technical perspective, this flaw enables on-path attackers positioned between the Snipe-IT server and the LDAP directory service to perform man-in-the-middle attacks with relative ease. An attacker can intercept the StartTLS negotiation phase and respond to the client's request not with a successful TLS handshake completion message, but with a protocol error or by simply dropping the connection attempt in a way that causes the application to proceed without encryption due to the missing validation logic. Once this condition is met, all subsequent communications between Snipe-IT and the LDAP server occur over cleartext TCP connections. This includes authentication exchanges where service account credentials are used for directory queries and end-user login passwords when users authenticate against the integrated identity provider. The absence of encryption means that these sensitive strings can be captured in plain text by any network observer with access to the traffic flow, such as through packet sniffing on a shared network segment or via compromised intermediate routing devices.
The operational impact of this vulnerability is severe, primarily concerning confidentiality and integrity of authentication data. Service account credentials are often privileged within Active Directory environments, possessing permissions to read user attributes, modify group memberships, or even reset passwords depending on the configuration. If an attacker captures these service account secrets, they can impersonate the Snipe-IT application itself, gaining unauthorized access to directory information that may include personally identifiable information of employees such as names, email addresses, phone numbers, and departmental structures. Furthermore, capturing end-user login passwords allows for credential stuffing attacks against other systems where users have reused their LDAP credentials, leading to broader organizational compromise. The ability to intercept these credentials also facilitates persistent access if the attacker replays them or uses them to create new backdoor accounts within the directory service.
This vulnerability aligns with CWE-319, which classifies cleartext transmission of sensitive information over a network that is not protected by adequate cryptographic mechanisms. It also maps directly to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle (AitM), where attackers intercept and potentially alter communication between two parties who believe they are directly communicating with each other. The specific action of answering a StartTLS request with a protocol error to force cleartext falls under the broader category of cryptographic failures that undermine transport security guarantees. Organizations relying on Snipe-IT for asset management must recognize that this flaw compromises the integrity of their identity infrastructure integration, potentially exposing high-value assets and sensitive personnel data to interception by any actor capable of network-level observation.
Mitigation strategies focus primarily on immediate software remediation and secondary hardening measures. The definitive solution is to upgrade Snipe-IT to version 8.6.3 or later, where the developers have implemented proper validation of the ldap_start_tls() return value, ensuring that connections are only established after a successful TLS handshake has been verified. Until an upgrade can be performed in test environments and deployed to production, administrators should consider network-level mitigations such as enforcing strict firewall rules that restrict LDAP traffic (ports 389 for cleartext or 636 for LDAPS) exclusively between the Snipe-IT server IP and the specific LDAP directory servers. This isolation reduces the attack surface by preventing on-path attackers from intercepting the traffic in shared network segments. Additionally, organizations should audit their LDAP configurations to ensure that StartTLS is strictly enforced at the directory service level where possible, although this does not fully compensate for the application-side flaw if the client ignores server responses. Regular vulnerability scanning and patch management processes are essential to prevent such cryptographic implementation errors from persisting in production environments.