Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
18 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Repo under test: https://github.com/Netflix/lemur PUT /api/1/certificates/<id/revoke authorizes the caller against the Lemur database row (creator == current user, or CertificatePermission over the row's roles) rather than the underlying CA-side certificate identity. Separately, POST /api/1/certificates/upload lets any user passing StrictRolePermission create a new Certificate row while freely supplying body, authority (resolved by id/name with no AuthorityPermission check) and externalid; there is no uniqueness constraint on body, serial, or externalid. An attacker can therefore read a target certificate's public body, authority.id, and externalid via GET /certificates/<id, upload a duplicate row, and revoke that duplicate. The creator-bypass skips CertificatePermission, the empty-endpoints check passes because the duplicate has none, and service.revoke() then revokes at the CA using the attacker-supplied body (ACME) or externalid (DigiCert/Entrust/Google CA/CFSSL) under the…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The CertificateExport handler in lemur/certificates/views.py nests its entire ownership / CertificatePermission check inside an if plugin.requireskey: branch. When the selected export plugin advertises requireskey = False, the authorization check is skipped entirely and any authenticated user can invoke plugin.export(cert.body, cert.chain, cert.privatekey, options) against a certificate they do not own. The handler additionally writes a "keyview" audit-log event for every call, regardless of whether the plugin actually accessed the private key, polluting the audit trail with false positives. Root Cause lemur/certificates/views.py:1573: The authorization gate is structurally inside the if plugin.requireskey: block. With requireskey = False, control falls straight through to plugin.export(...) with no ownership check. The cert.privatekey is passed to the plugin regardless of the flag — the flag only describes what the plugin advertises it needs, not what it actually receives.…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Repo under test: https://github.com/Netflix/lemur When ADMINONLYAUTHORITYCREATION=False (an explicitly supported and documented configuration), POST /api/1/authorities with type=subca never verifies that the caller holds AuthorityPermission on the supplied parent authority. The parent field is resolved by AssociatedAuthoritySchema via a raw fetchobjects(Authority, data) lookup, then passed straight through service.create → mint → cryptography-issuer.createauthority, which loads options["parent"].authoritycertificate.privatekey and signs a brand-new intermediate CA on the caller's behalf. Any authenticated non-read-only user can therefore mint a sub-CA chained to any internal root whose private key Lemur holds — including roots they hold no role on — attach a role they already belong to, and immediately issue or offline-sign trusted leaf certificates for arbitrary names. Affected route POST /api/1/authorities (with type=subca) Affected code - lemur/authorities/views.py:231 —…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Repo under test: https://github.com/Netflix/lemur The certificate create and upload endpoints accept a replaces[] (alias replacements) array that is resolved to live Certificate ORM objects with no ownership or CertificatePermission check on the referenced certificates. The SQLAlchemy Certificate.replaces append listener then immediately sets victim.notify = False and populates victim.replaced. From that point the victim certificate is excluded from auto-reissue, its expiration notifications are silenced, and the periodic certificaterotate Celery task deploys the attacker's certificate (endpoint.certificate.replaced[0]) onto every endpoint serving the victim certificate. Any authenticated non-read-only user can therefore silently substitute their own certificate onto production load balancers and Kubernetes secrets they hold no role on, while suppressing the legitimate certificate's lifecycle automation. Affected route POST /api/1/certificates POST /api/1/certificates/upload…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Lemur's destination read endpoints -- GET /api/1/destinations and GET /api/1/destinations/<id -- return the full set of stored plugin option values to any authenticated user, with no authorization check and no redaction of secret-bearing options. The sibling write endpoints (POST/PUT/DELETE) are gated with @adminpermission.require(httpexception=403), but the two read handlers are protected only by loginrequired (inherited from AuthenticatedResource). They do not even exclude read-only users. The built-in SFTP destination plugin (sftp-destination) stores its password and privateKeyPass options in cleartext in the destinations.options column (the plugin's own docstring states "Passwords are not encrypted and stored as a plain text."). Because DestinationOutputSchema serializes every option value verbatim, any authenticated principal -- including a read-only user -- can retrieve these credentials and use them to authenticate to the remote SFTP server to which Lemur deploys…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for GHSA-v2wp-frmc-5q3v added validateacmeurl() to reject acmeurl values not in ACMEDIRECTORYHOSTALLOWLIST, but the validation is only called at authority creation time (POST). The authority update endpoint (PUT /api/1/authorities/<id) accepts and stores arbitrary options -- including a modified acmeurl -- without invoking the allowlist check. Any user with an authority role (granted by an admin to allow issuing certificates via that authority) can therefore overwrite the stored acmeurl with an internal IP or IMDS endpoint. The next certificate issuance via that authority causes Lemur's backend to fetch the attacker-controlled URL, achieving SSRF. Details Where the fix lives (POST path -- protected): lemur/plugins/lemuracme/plugin.py lines 333-337 (ACMEIssuerPlugin.createauthority): validateacmeurl at line 35: Where the gap is (PUT path -- unprotected): lemur/authorities/views.py lines 405-424 (Authorities.put): lemur/authorities/service.py lines 28-46 (update): Where…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (validaterevocationurl() in lemur /certificates/verify.py) can be bypassed. An operator-role user who uploads a certificate with attacker-controlled CRL/OCSP extensions can still make Lemur reach internal destinations (RFC1918, loopback, link-local 169.254.169.254) during verification. Affected version Tested against main (the commit that introduced validaterevocationurl). The 1.9.2 release predates that guard and is vulnerable to the original SSRF (GHSA-54vg-pfh7-jq95) directly; this bypass applies to the unreleased mitigation in main. Please map the affected range to whichever release will first contain validaterevocationurl. Bypass 1 — HTTP redirect (deterministic) The guard validates only the URL in the certificate; the CRL fetch then follows redirects without re-validating the target: The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location:…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ACME client (used to issue certificates from Let's Encrypt / Google Public CA / private ACME CAs) connects to an acmeurl, then issues requests to URLs that the ACME server returns in its directory/order/authorization/finalize responses - this is the classic ACME-client SSRF (RFC 8555 design). Lemur validates acmeurl against an allowlist of public ACME directories, but only at authority creation. The authority UPDATE path (PUT /authorities/<id) accepts a new options blob with an arbitrary acmeurl and never re-validates. An attacker who is a member of an authority's role can repoint an existing ACME authority at a malicious ACME server they control, which returns internal URLs in its responses - coercing Lemur into making JWS-signed POST requests to internal services during the next certificate issuance. Detail Defect A - allowlist only at creation. validateacmeurl (lemur/plugins/lemuracme/plugin.py:35-53) restricts the host to {acme-v02.api.letsencrypt.org,…
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
<!-- obsidian --<h1 data-heading="Lemur 1.9.0: any SSO-authenticated user achieves AWS IAM compromise and permanent PKI key access via ACME acmeurl SSRF and creator-equality IDOR"Lemur 1.9.0: any SSO-authenticated user achieves AWS IAM compromise and permanent PKI key access via ACME acmeurl SSRF and creator-equality IDOR</h1 <h2 data-heading="Vulnerability Summary"Vulnerability Summary</h2 Field | Value -- | -- Title | Lemur 1.9.0: any SSO-authenticated user achieves AWS IAM compromise and permanent PKI key access via ACME acmeurl SSRF and creator-equality IDOR Component | lemur/lemur/plugins/lemuracme/acmehandlers.py:161-201 (SSRF), lemur/lemur/certificates/views.py:734 (IDOR), lemur/lemur/auth/views.py:300-308 (SSO auto-provision) CWE | CWE-918 (SSRF) + CWE-639 (Authorization Bypass Through User-Controlled Key) + CWE-285 (Improper Authorization) Attack Prerequisite | A valid SSO session against the deployment's IdP. Lemur auto-provisions any new SSO identity at active=True, so an…
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
<!-- obsidian --<h1 data-heading="Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure"Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure</h1 <h2 data-heading="Vulnerability Summary"Vulnerability Summary</h2 Field | Value -- | -- Title | Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure Component | lemur/lemur/auth/service.py:130-137 CWE | CWE-347 (Improper Verification of Cryptographic Signature) Attack Prerequisite | Defense-in-depth gap on its own — no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMURTOKENSECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur version = "1.9.0". Same code…
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
lemur.users.service.update() writes a user's new password as plaintext to the users.password column. The User model wires bcrypt hashing to SQLAlchemy's beforeinsert event but registers no equivalent listener for beforeupdate, and service.update() does not call user.hashpassword() after assigning the new value. Every password change performed through the admin-gated PUT /api/1/users/<id endpoint persists the user's password to the database in cleartext. Root Cause lemur/users/models.py: lemur/users/service.py: No beforeupdate listener exists. User.password is a plain Column(String(128)) with no property setter that hashes on assignment. The bcrypt code path is bypassed entirely on every UPDATE statement that touches this column. Affected Endpoints | Method | Path | Source | |---|---|---| | PUT | /api/1/users/<id | lemur/users/views.py:274 (gated by @adminpermission.require) | lemur/auth/views.py:323 also calls userservice.update() during SSO/OAuth login, but passes only six…
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PUT /api/1/roles/<id handler in lemur/roles/views.py gates only on RoleMemberPermission(roleid).can(), which is satisfied for any user who is already a member of the target role. The handler then passes data["users"] and data["name"] directly to service.update(), permitting any role member to rewrite that role's membership list and name. The companion DELETE handler on the same resource is correctly gated by @adminpermission.require; the asymmetry between PUT and DELETE on identical resources indicates an authorization oversight rather than a deliberate design choice. Root Cause lemur/roles/views.py:298: lemur/auth/permissions.py:56: flaskprincipal.Permission.allows() is OR-semantic across needs, so RoleMemberPermission(roleid).can() returns True if the caller is either an admin or a member of roleid. The PUT handler treats membership-of-self as sufficient to mutate the role; DELETE does not. Affected Endpoints | Method | Path | Source | |---|---|---| | PUT |…
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When verifying an uploaded certificate, lemur/certificates/verify.py extracts the CRL Distribution Point URL and the OCSP responder URL directly from the certificate's extensions and issues outbound requests to those URLs without scheme restriction or destination allow-listing. An authenticated user holding the operator role (required by StrictRolePermission on POST /certificates/upload) can craft a certificate whose extensions point at internal services - instance metadata endpoints, internal Kubernetes API servers, RFC1918 hosts, link-local addresses - and cause the Lemur host to issue requests against those destinations during verification. Root Cause lemur/certificates/verify.py, crlverify: lemur/certificates/verify.py, ocspverify: In both code paths the URL flows from attacker-controlled certificate-extension content to a network sink with no validation against an allow-list of hostnames, no scheme restriction beyond rejecting LDAP via InvalidSchema, and no filtering of…
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flaskprincipal.Permission.init() with zero Needs when their config flags are unset. Both flags defaulted to False in code prior to the fix, so this was the state of any Lemur install that hadn't explicitly opted in. Flask-Principal's Permission.allows() returns True whenever self.needs is empty. The .can() gate therefore passes for every authenticated identity, including the lowest-privilege role Lemur ships (read-only). A user holding only read-only can create root Certificate Authorities, create and edit notifications (an SSRF sink), create domain entries, and upload arbitrary certificates. These classes are the sole authorization check on those endpoints. Root Cause flaskprincipal.Permission.allows() (upstream, v0.4.0): When self.needs == set(), the first guard is falsy and is skipped. excludes is also empty, so allows() returns True for any identity. AuthenticatedResource (the parent…
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Overview Lemur's LDAP authentication module (lemur/auth/ldap.py) constructs LDAP search filters using unsanitized user input via Python string interpolation. An authenticated LDAP user can inject LDAP filter metacharacters through the username field to manipulate group membership queries and escalate their privileges to administrator. Vulnerable Code Location: lemur/auth/ldap.py, bind() method Filter 1 — User lookup (line ~161): self.ldapprincipal is derived directly from args["username"] submitted at POST /auth/login with no sanitization. The ldap.filter.escapefilterchars() function is never called. Filter 2 — Active Directory group lookup (line ~189): The userdn value is derived from the LDAP response to the first unsanitized query, making it potentially tainted as well. Impact An authenticated LDAP user can: 1. Inject LDAP filter syntax into the username field during login 2. Manipulate the group membership query to return arbitrary groups 3. Be assigned the admin role…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Overview When LDAP TLS is enabled (LDAPUSETLS = 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 positioned between Lemur and the LDAP server to intercept all authentication credentials. Vulnerable Code Location: lemur/auth/ldap.py, bind() method, line ~172 Key issues: 1. ldap.setoption() is a global call (as opposed to self.ldapclient.setoption()), meaning it disables TLS verification for the entire Python process, not just this connection 2. OPTXTLSNEVER means no certificate validation is performed whatsoever — self-signed, expired, wrong hostname, and revoked certificates are all silently accepted 3. There is no configuration option to override this behavior — TLS verification is always disabled when TLS is enabled Impact A network-positioned attacker (man-in-the-middle) between Lemur and the LDAP server can: - Intercept all LDAP credentials…
Recommended action: Upgrade to 1.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Lemur was using insecure random generation for its example configuration file, as well as for some utilities. Impact The potentially affected generated items include: | Configuration item | Config option name (if applicable) | Documentation link (if applicable) | Rotation option | Code reference(s) | | ----------- | ----------- | ----------- | ----------- |----------- | | Flask session secret | SECRETKEY | Flask documentation | Generate a new secret and place in config; all existing sessions will be invalidated | N/A, internal to Flask | | Lemur token secret | LEMURTOKENSECRET | Lemur's configuration documentation | Generate a new secret and place in config; all existing JWTs will be invalidated and must be regenerated (including API keys) | 1, 2 | | Lemur database encryption key | LEMURENCRYPTIONKEYS | Lemur's configuration documentation | A new key can be generated and added to this list, but existing data encrypted with prior keys cannot be re-encrypted unless you write a…
Recommended action: Upgrade to 1.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Lemur 0.1.4 does not use sufficient entropy in its IV when encrypting AES in CBC mode.
Recommended action: Upgrade to 0.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.