CVE-2026-71307 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.3, GET /api/1/destinations and GET /api/1/destinations/ relied only on authentication while sibling write handlers required admin_permission. DestinationOutputSchema returned raw options and copied them into pluginOptions without redacting sensitive values. The sftp-destination plugin stored password and privateKeyPass values in plaintext, allowing even a read-only user to retrieve credentials for remote certificate-deployment hosts. The exposed credentials could permit direct access to SFTP systems and TLS material outside the Lemur security boundary. The fix requires administrator permission for destination reads and redacts options marked sensitive. This issue is fixed in version 1.9.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur, a system responsible for managing Transport Layer Security certificate creation and deployment, represents a critical failure in access control logic and data handling practices within versions prior to 1.9.3. The core issue stems from an inconsistent enforcement of authorization policies across different API endpoints related to destination configurations. Specifically, the read-only endpoints GET /api/1/destinations and GET /api/1/destinations/{id} were configured to rely solely on user authentication for access control. This design decision failed to account for the sensitivity of the data returned by these endpoints, which included detailed configuration parameters necessary for deploying certificates to remote hosts. In contrast, sibling write handlers correctly required admin_permission, creating a significant disparity where authenticated users with minimal privileges could retrieve sensitive infrastructure details that should have been restricted to administrators only.
From a technical perspective, the flaw is compounded by how the DestinationOutputSchema processed and serialized destination options. The schema functioned as an intermediary layer between the database storage and the API response, but it failed to implement proper data sanitization for fields designated as sensitive. When constructing the pluginOptions object, the system copied raw configuration values directly into the output payload without redacting or masking credentials such as passwords and private key passphrases. This lack of obfuscation meant that any user capable of authenticating to the Lemur application could extract plaintext secrets intended exclusively for secure transmission to remote SFTP servers used in certificate deployment workflows. The absence of a clear separation between configuration metadata and secret material allowed these high-value credentials to be exposed through standard read operations, effectively bypassing the principle of least privilege.
The operational impact of this vulnerability is severe, as it allows an attacker with low-level access to Lemur to compromise downstream infrastructure security. By retrieving plaintext passwords and private key passphrases for SFTP destinations, a malicious actor or compromised account can gain direct unauthorized access to remote systems involved in the certificate lifecycle management process. This exposure extends beyond simple credential theft; it permits potential manipulation of TLS material deployment processes, which could lead to man-in-the-middle attacks if certificates are replaced with attacker-controlled ones. Furthermore, the leakage of these credentials violates fundamental security boundaries established by Lemur’s intended architecture, exposing internal network topology and authentication mechanisms for remote hosts that were not meant to be visible to non-administrative users. This scenario aligns closely with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials in terms of data exposure risks, while also reflecting ATT&CK techniques related to Credential Dumping from local systems or API endpoints.
To mitigate this vulnerability, it is imperative that organizations running Lemur upgrade immediately to version 1.9.3 or later, where the access control logic has been corrected to require administrator permission for all destination read operations. This ensures that only privileged users can view sensitive configuration details. Additionally, developers and security teams should verify that any custom plugins or extensions adhere to strict data redaction standards, ensuring that fields marked as sensitive are never returned in plaintext within API responses. Implementing robust input validation and output encoding practices is essential to prevent similar information disclosure flaws. Regular audits of API endpoint permissions against the principle of least privilege will help maintain a secure environment where credential confidentiality is preserved even when read access to configuration structures is granted.