CVE-2026-55166 - Lemur ACME SSRF and creator-equality IDOR

Lemur before 1.9.2 let any SSO-authenticated user combine an ACME acme_url SSRF path with weak creator-based authorization checks and reach internal AWS IAM, certificate, or PKI operations. The vulnerable shapes include untrusted ACME endpoint selection and certificate ownership logic that trusts creator equality rather than stronger authorization.

This is a chained server-side request forgery plus authorization failure with direct impact on cloud identity and certificate material.

When to use it

  • A repository deploys, packages, configures, or extends Lemur before 1.9.2.
  • Users can create or edit ACME-backed certificate workflows or influence outbound ACME endpoints.
  • Lemur can reach AWS metadata/IAM, private PKI, CA services, or certificate management endpoints.
  • You need a bounded PR or triage note that upgrades Lemur, restricts ACME egress, and fixes certificate object authorization.

Inputs

  • Python manifests, lockfiles, images, deployment manifests, SBOMs, generated reports, Lemur config, SSO provisioning, and ACME integration code.
  • ACME endpoint validation, outbound network policy, certificate ownership checks, IAM/CA token exposure, and audit log ownership.
  • Available tests, build, image build, deployment render, egress policy, SBOM, and dependency/security scan commands.

Affected versions

  • Vulnerable: lemur <1.9.2
  • Fixed: lemur 1.9.2+
  • Affected surface: ACME handlers, certificate views, and SSO-driven user provisioning or ownership flows

Indicator-of-exposure

  • The repository deploys Lemur <1.9.2.
  • Users can create or edit ACME-backed certificate workflows.
  • Lemur can reach internal metadata, AWS APIs, private PKI endpoints, or certificate-management services.
  • Authorization paths compare only creator identity or similar weak ownership fields for privileged certificate actions.

Quick checks:

rg -n "acme_url|lemur_acme|creator|certificate.*owner|SSO|auth/views|certificates/views" .
pip show lemur

Windows:

rg -n "acme_url|lemur_acme|creator|certificate.*owner|SSO|auth/views|certificates/views" .
pip show lemur

Remediation strategy

  • Upgrade Lemur to 1.9.2+.
  • Reject untrusted ACME URLs and enforce strict allow-lists for outbound ACME endpoints.
  • Replace creator-equality authorization with explicit role, tenancy, and object-level access checks.
  • Review whether AWS IAM credentials, CA tokens, certificate private keys, or issuance logs require rotation and incident review.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-55166 / GHSA-v2wp-frmc-5q3v in Lemur. ACME URL
SSRF and weak creator-based authorization can expose AWS IAM and PKI material.
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Lemur, constrains ACME
  egress, hardens certificate authorization, adds regression tests, and
  documents operator cleanup, or
- TRIAGE.md if this repository does not control an affected Lemur deployment.

## Rules

- Scope only CVE-2026-55166 and directly related SSRF and authorization paths.
- Treat certificate private keys, AWS credentials, CA tokens, and audit logs as
  sensitive.
- Do not send live requests to attacker-controlled or production-internal
  endpoints to prove exposure.
- Do not auto-merge.

## Steps

1. Inventory every Lemur dependency, image, manifest, and deployment controlled
   by this repository.
2. Confirm whether any runtime resolves `<1.9.2`.
3. Trace ACME endpoint configuration, outbound request validation, and
   certificate authorization checks.
4. If this repository does not control an affected Lemur runtime, stop with
   `TRIAGE.md` naming the owner and required fixed version `1.9.2+`.
5. Upgrade to `1.9.2+` and refresh locks, images, SBOMs, and deployment docs.
6. Enforce a strict allow-list for ACME endpoints and block internal or
   metadata destinations.
7. Replace creator-equality checks with explicit authorization for certificate
   reads, writes, issuance, and ownership-changing actions.
8. Add regression tests proving an authenticated low-privilege user cannot
   redirect ACME traffic or act on certificates they do not explicitly own.
9. Add a PR body section named `CVE-2026-55166 operator actions` covering:
   - versions before and after;
   - whether SSO auto-provisioning and ACME were enabled;
   - which cloud credentials, CA tokens, or keys need review;
   - which logs should be inspected for suspicious outbound ACME requests or
     certificate access;
   - validation that passed.
10. Run available validation: tests, build, image build, deployment render, and
    dependency/security scans.
11. Use PR title:
    `fix(sec): remediate Lemur ACME SSRF and certificate IDOR`.

## Stop conditions

- No affected Lemur runtime is controlled by this repository.
- Verification would require sending live SSRF traffic to sensitive endpoints.
- Certificate authorization is owned entirely outside this repository.
- Validation fails for unrelated pre-existing reasons; document those failures.

Verification - what the reviewer looks for

  • No controlled Lemur runtime resolves <1.9.2.
  • ACME endpoints are allow-listed and internal destinations are blocked.
  • Certificate actions require explicit authorization beyond creator equality.
  • Operator notes cover cloud and PKI key review if exposure existed.

Output contract

  • Reviewer-ready PR upgrading Lemur to 1.9.2+ and refreshing locks, images, SBOMs, deployment docs, and generated reports.
  • ACME endpoint allow-listing and internal-destination blocking in config or code where this repository owns egress controls.
  • Explicit certificate authorization checks replacing creator equality, plus tests for low-privilege SSRF and IDOR attempts.
  • TRIAGE.md when runtime, certificate authorization, or cloud/PKI review is outside repository ownership.

Watch for

  • Fixing SSRF while leaving weak certificate ownership checks in place.
  • Blocking UI choices but still accepting raw ACME URLs through the API.
  • Forgetting background jobs or provisioning paths that reuse the same trust assumptions.

References