Lemur vulnerabilities

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

Lemur before version 1.9.2 has a vulnerability in lemur.users.service.update that assigns a replacement password directly to users.password, without invoking hash_password (registered only for the before_insert event). As a result, administrator-initiated password changes via PUT /api/1/users/ are stored in plaintext, preventing normal login and exposing passwords.

Lemur before version 1.9.2 has a vulnerability in PUT /api/1/roles/ that authorizes updates based on role membership rather than administrator-only. This allows a non-admin member to add or remove other users and rename the role, potentially leading to privilege escalation and denial of access.

Lemur before version 1.9.2 has a vulnerability in lemur/certificates/verify.py that accepts CRL and OCSP URLs from uploaded certificates without adequate destination validation. An authenticated operator can upload a certificate via POST /api/1/certificates/upload and cause verify_string to reach internal addresses such as loopback, RFC1918, link-local, or instance-metadata (e.g., 169.254.169.254). Additionally, the CRL path uses an unbounded cache, potentially leading to memory exhaustion.

Lemur before version 1.9.1 has the ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT flags disabled by default, causing the permission check to pass any authenticated user, including the read-only role. A user can create certificate authorities, upload certificates, create notifications, and create domain entries.

Lemur manages TLS certificate creation. Prior to 1.9.0, when LDAP TLS is enabled (LDAP_USE_TLS = True), Lemur's LDAP authentication module unconditionally disables TLS certificate verification at the global ldap module level. This allows a man-in-the-middle attacker between Lemur and the LDAP server to intercept all authentication credentials.