CVE-2026-71317

Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3.

Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3.

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…

Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3.

Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3.

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…

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…