PT-2026-80275 · Pypi · Lemur

Published

2026-08-18

·

Updated

2026-08-18

CVSS v3.1

6.5

Medium

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

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

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

Fix

Missing Authorization

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-862

Related Identifiers

GHSA-G7P5-89MH-248H

Affected Products

Lemur