CVE-2026-70667

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 prior to 1.9.3 did not require AuthorityPermission on the parent authority when creating a sub-CA if ADMIN_ONLY_AUTHORITY_CREATION was false. An authenticated non-read-only user could create a sub-CA and use the parent's private key to sign a new intermediate, allowing issuance of trusted certificates outside normal controls.

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.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.