CVE-2026-71317

Lemur version 0.1.4 does not use sufficient entropy in its initialization vector (IV) when encrypting AES in CBC mode, which may weaken data security.

Lemur before version 1.9.2 has a vulnerability that allows authenticated users to influence the ACME authority URL (acme_url) without effective server-side destination restriction, enabling SSRF attacks on internal services or cloud metadata. Additionally, there is an authorization weakness that could preserve access to private keys after ownership changes.

Lemur before version 1.9.3 contains a vulnerability in API endpoints that allows an unprivileged user to create a duplicate certificate without required permissions and then revoke it, potentially leading to denial of service for all certificates. The fix in version 1.9.3 rejects duplicates and requires authority access.

Lemur prior to 1.9.3 has a vulnerability in CertificateExport where the CertificatePermission ownership check was inside the plugin.requires_key branch. A plugin with requires_key false bypassed the check, and the handler still passed the private key and logged a key_view audit event. The fix does not pass private keys to plugins that do not require them.

Lemur up to version 1.9.3 did not enforce CertificatePermission checks when assigning identifiers to the replaces field in certificate create, upload, and edit requests. This allowed an attacker with non-read-only access to disable victim certificate notifications and mark them as replaced, potentially leading to deployment of attacker certificates on victim endpoints. The issue is fixed in version 1.9.3.

Lemur before version 1.9.3 exposed GET /api/1/destinations and GET /api/1/destinations/ with only authentication, without requiring admin permission, and responses included raw options with plaintext passwords and private keys. This allowed a read-only user to retrieve credentials for remote certificate-deployment hosts. The issue is fixed in version 1.9.3.

Lemur before version 1.9.3 did not enforce the ACME directory host allowlist when updating acme_url via PUT /api/1/authorities/, allowing an authority-role user to set the URL to an internal service or cloud metadata address (e.g., 169.254.169.254). During the next issuance operation, Lemur made an outbound request to that address, potentially exposing internal services or cloud metadata. The issue is fixed in version 1.9.3.

Lemur before version 1.9.3 allowed an authority-role user to update acme_url without revalidation and direct the ACME client to an attacker-controlled server. That server could return URLs (newNonce, newOrder, authorizations, finalize) pointing to internal services or cloud metadata, and Lemur followed them without host validation. The issue is fixed in version 1.9.3.

Lemur before version 1.9.3 contains a vulnerability in _validate_revocation_url that does not properly validate URLs after HTTP redirects, allowing access to internal addresses (loopback, RFC1918, link-local, instance-metadata). Additionally, there is a time-of-check time-of-use window enabling DNS rebinding attacks. An operator uploading a certificate via POST /api/1/certificates/upload can trigger unwanted internal requests.

Lemur before version 1.9.2 has a vulnerability in the JWT verifier that uses an unverified algorithm from the token header. In the default configuration, PyJWT rejects alg=none, so it is not a direct authentication bypass, but it is a defense-in-depth gap. After migration to asymmetric signing, algorithm confusion may occur, and algorithm-based anomaly detection is weakened.