{"id":"CVE-2026-71317","aliases":["EUVD-2026-61156","GHSA-g7p5-89mh-248h","PYSEC-2026-3677"],"status":"published","title":"Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority","description":"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.","severity":{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00105,"percentile":0.01077,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-862"],"published":"2026-08-18T19:06:27Z","modified":"2026-10-28T02:30:45Z","fixes":[{"ecosystem":"PyPI","package":"lemur","fixed_in":["1.9.3"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"lemur","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.9.2"},{"fixed":"1.9.3"}]}]},{"source":"osv","ecosystem":"PyPI","package":"lemur","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.9.3"}]}],"versions":["0.11.0","0.2.1","0.8.0","0.8.1","0.9.0","1.0.0","1.1.0","1.2.0","1.3.1","1.3.2","1.4.0","1.5.0","1.6.0","1.7.0","1.8.0","1.8.1","1.8.2","1.9.0","1.9.1","1.9.2"]},{"source":"osv","ecosystem":"PyPI","package":"lemur","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.9.3"}]}],"versions":["0.11.0","0.2.1","0.8.0","0.8.1","0.9.0","1.0.0","1.1.0","1.2.0","1.3.1","1.3.2","1.4.0","1.5.0","1.6.0","1.7.0","1.8.0","1.8.1","1.8.2","1.9.0","1.9.1","1.9.2"]}],"products":[{"vendor":"netflix","product":"lemur"}],"references":[{"url":"https://github.com/Netflix/lemur/security/advisories/GHSA-g7p5-89mh-248h","tags":["x_refsource_CONFIRM","not-applicable","advisory","web"]},{"url":"https://github.com/Netflix/lemur/commit/8669011203ca3dd89d9e39bab9ef6850eca723f9","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/Netflix/lemur/releases/tag/v1.9.3","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-g7p5-89mh-248h","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/71xxx/CVE-2026-71317.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-71317","tags":["advisory"]},{"url":"https://github.com/Netflix/lemur","tags":["package"]},{"url":"https://pypi.org/project/lemur","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-71317","title":"Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority","description":"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.","status":"published","published":"2026-08-18T19:06:27.618Z","modified":"2026-08-19T19:21:56.406Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T14:19:49.885652Z"}],"euvd":[{"id":"EUVD-2026-61156","description":"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.","status":"published","published":"2026-08-18T19:06:27Z","modified":"2026-08-19T19:21:56Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T18:01:40.9092Z"}],"ghsa":[{"id":"GHSA-g7p5-89mh-248h","title":"Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority","description":"## Summary\n\nRepo under test: https://github.com/Netflix/lemur\n\nWhen `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.\n\nAny 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.\n\n## Affected route\n\n`POST /api/1/authorities` (with `type=subca`)\n\n## Affected code\n\n- [`lemur/authorities/views.py:231`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/views.py#L231) — gates only on `AuthorityCreatorPermission()` + `StrictRolePermission()`; no `AuthorityPermission` on `data['parent']`\n- [`lemur/authorities/schemas.py:58`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/schemas.py#L58) — `parent = fields.Nested(AssociatedAuthoritySchema)`; `validate_subca` only checks presence\n- [`lemur/schemas.py:107`](https://github.com/Netflix/lemur/blob/main/lemur/schemas.py#L107) — `AssociatedAuthoritySchema.get_object` → `fetch_objects(Authority, data)` resolves any authority by id/name with no permission check\n- [`lemur/plugins/lemur_cryptography/plugin.py:40`](https://github.com/Netflix/lemur/blob/main/lemur/plugins/lemur_cryptography/plugin.py#L40) — `private_key = options[\"authority\"].authority_certificate.private_key` (set from `options[\"parent\"]`) signs the new intermediate\n- [`lemur/auth/permissions.py:62`](https://github.com/Netflix/lemur/blob/main/lemur/auth/permissions.py#L62) — `AuthorityCreatorPermission` becomes always-allow when `ADMIN_ONLY_AUTHORITY_CREATION=False`\n- [`lemur/certificates/views.py:538`](https://github.com/Netflix/lemur/blob/main/lemur/certificates/views.py#L538) — `is_private_authority` (true for `cryptography-issuer`) skips `USER_DOMAIN_AUTHORIZATION_PROVIDER` for subsequent leaf issuance\n\n## Impact\n\nIn 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:\n\n- 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.\n- Export the sub-CA private key and sign end-entity certificates entirely outside Lemur, defeating all in-product issuance controls.\n\nThis 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.\n\n## Root cause\n\n`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.\n\n## Validated evidence\n\nStatic trace, confirmed by code inspection (validation status: `CONFIRMED`):\n\n- `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.\n- No call to `AuthorityPermission(parent.id, ...)` exists anywhere on this path.\n- Precondition `ADMIN_ONLY_AUTHORITY_CREATION=False` is an explicitly supported config ([`docs/administration.rst:517`](https://github.com/Netflix/lemur/blob/main/docs/administration.rst#L517)).\n\n## Proof of concept / reproducer\n\nStatus: reconstructed from source report (static control-flow trace; not executed against a live CA).\n\nPreconditions: `ADMIN_ONLY_AUTHORITY_CREATION=False`; attacker is an authenticated Lemur user holding any role other than `read-only`; `\u003cPARENT_AUTHORITY_ID\u003e` is any internal `cryptography-issuer` root CA the attacker holds no role on; `\u003cATTACKER_ROLE\u003e` is any role the attacker already belongs to.\n\n```bash\ncurl -sS -X POST \"\u003cTARGET_BASE_URL\u003e/api/1/authorities\" \\\n  -H \"Authorization: Bearer \u003cAUTH_TOKEN\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n        \"name\": \"attacker-subca\",\n        \"owner\": \"attacker@example.com\",\n        \"description\": \"poc\",\n        \"type\": \"subca\",\n        \"parent\": {\"id\": \u003cPARENT_AUTHORITY_ID\u003e},\n        \"plugin\": {\"slug\": \"cryptography-issuer\"},\n        \"roles\": [{\"name\": \"\u003cATTACKER_ROLE\u003e\"}],\n        \"commonName\": \"attacker-intermediate\",\n        \"validityYears\": 1\n      }'\n```\n\nThe response contains a new authority whose `authority_certificate` is signed by `\u003cPARENT_AUTHORITY_ID\u003e`'s private key. The caller is recorded as creator and holds `\u003cATTACKER_ROLE\u003e` on it, so `POST /api/1/certificates` against the new authority succeeds (and skips `allowed_issuance_for_domain` because `is_private_authority` is true).\n\nStatic-trace validation command from the source report:\n\n```bash\ngrep -n 'parent' lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \\\n  \u0026\u0026 sed -n '37,55p' lemur/plugins/lemur_cryptography/plugin.py\n```\n\nSource 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).\n\n## Suggested fix\n\nIn `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.","status":"published","published":"2026-08-18T20:51:37Z","modified":"2026-08-18T20:51:38Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T14:41:03.602876Z"}],"nvd":[{"id":"CVE-2026-71317","description":"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.","status":"published","published":"2026-08-18T20:17:23.91Z","modified":"2026-10-22T22:10:00.25Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T14:12:38.976695Z"}],"osv":[{"id":"CVE-2026-71317","title":"Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority","description":"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.","status":"published","published":"2026-08-18T19:06:27.618Z","modified":"2026-10-28T02:30:45.584299239Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T15:45:15.164658Z"},{"id":"GHSA-g7p5-89mh-248h","title":"Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority","description":"## Summary\n\nRepo under test: https://github.com/Netflix/lemur\n\nWhen `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.\n\nAny 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.\n\n## Affected route\n\n`POST /api/1/authorities` (with `type=subca`)\n\n## Affected code\n\n- [`lemur/authorities/views.py:231`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/views.py#L231) — gates only on `AuthorityCreatorPermission()` + `StrictRolePermission()`; no `AuthorityPermission` on `data['parent']`\n- [`lemur/authorities/schemas.py:58`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/schemas.py#L58) — `parent = fields.Nested(AssociatedAuthoritySchema)`; `validate_subca` only checks presence\n- [`lemur/schemas.py:107`](https://github.com/Netflix/lemur/blob/main/lemur/schemas.py#L107) — `AssociatedAuthoritySchema.get_object` → `fetch_objects(Authority, data)` resolves any authority by id/name with no permission check\n- [`lemur/plugins/lemur_cryptography/plugin.py:40`](https://github.com/Netflix/lemur/blob/main/lemur/plugins/lemur_cryptography/plugin.py#L40) — `private_key = options[\"authority\"].authority_certificate.private_key` (set from `options[\"parent\"]`) signs the new intermediate\n- [`lemur/auth/permissions.py:62`](https://github.com/Netflix/lemur/blob/main/lemur/auth/permissions.py#L62) — `AuthorityCreatorPermission` becomes always-allow when `ADMIN_ONLY_AUTHORITY_CREATION=False`\n- [`lemur/certificates/views.py:538`](https://github.com/Netflix/lemur/blob/main/lemur/certificates/views.py#L538) — `is_private_authority` (true for `cryptography-issuer`) skips `USER_DOMAIN_AUTHORIZATION_PROVIDER` for subsequent leaf issuance\n\n## Impact\n\nIn 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:\n\n- 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.\n- Export the sub-CA private key and sign end-entity certificates entirely outside Lemur, defeating all in-product issuance controls.\n\nThis 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.\n\n## Root cause\n\n`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.\n\n## Validated evidence\n\nStatic trace, confirmed by code inspection (validation status: `CONFIRMED`):\n\n- `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.\n- No call to `AuthorityPermission(parent.id, ...)` exists anywhere on this path.\n- Precondition `ADMIN_ONLY_AUTHORITY_CREATION=False` is an explicitly supported config ([`docs/administration.rst:517`](https://github.com/Netflix/lemur/blob/main/docs/administration.rst#L517)).\n\n## Proof of concept / reproducer\n\nStatus: reconstructed from source report (static control-flow trace; not executed against a live CA).\n\nPreconditions: `ADMIN_ONLY_AUTHORITY_CREATION=False`; attacker is an authenticated Lemur user holding any role other than `read-only`; `\u003cPARENT_AUTHORITY_ID\u003e` is any internal `cryptography-issuer` root CA the attacker holds no role on; `\u003cATTACKER_ROLE\u003e` is any role the attacker already belongs to.\n\n```bash\ncurl -sS -X POST \"\u003cTARGET_BASE_URL\u003e/api/1/authorities\" \\\n  -H \"Authorization: Bearer \u003cAUTH_TOKEN\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n        \"name\": \"attacker-subca\",\n        \"owner\": \"attacker@example.com\",\n        \"description\": \"poc\",\n        \"type\": \"subca\",\n        \"parent\": {\"id\": \u003cPARENT_AUTHORITY_ID\u003e},\n        \"plugin\": {\"slug\": \"cryptography-issuer\"},\n        \"roles\": [{\"name\": \"\u003cATTACKER_ROLE\u003e\"}],\n        \"commonName\": \"attacker-intermediate\",\n        \"validityYears\": 1\n      }'\n```\n\nThe response contains a new authority whose `authority_certificate` is signed by `\u003cPARENT_AUTHORITY_ID\u003e`'s private key. The caller is recorded as creator and holds `\u003cATTACKER_ROLE\u003e` on it, so `POST /api/1/certificates` against the new authority succeeds (and skips `allowed_issuance_for_domain` because `is_private_authority` is true).\n\nStatic-trace validation command from the source report:\n\n```bash\ngrep -n 'parent' lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \\\n  \u0026\u0026 sed -n '37,55p' lemur/plugins/lemur_cryptography/plugin.py\n```\n\nSource 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).\n\n## Suggested fix\n\nIn `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.","status":"published","published":"2026-08-18T20:51:37Z","modified":"2026-08-19T12:55:31.770935706Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T15:46:47.472172Z"},{"id":"PYSEC-2026-3677","title":"Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority","description":"## Summary\n\nRepo under test: https://github.com/Netflix/lemur\n\nWhen `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.\n\nAny 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.\n\n## Affected route\n\n`POST /api/1/authorities` (with `type=subca`)\n\n## Affected code\n\n- [`lemur/authorities/views.py:231`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/views.py#L231) — gates only on `AuthorityCreatorPermission()` + `StrictRolePermission()`; no `AuthorityPermission` on `data['parent']`\n- [`lemur/authorities/schemas.py:58`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/schemas.py#L58) — `parent = fields.Nested(AssociatedAuthoritySchema)`; `validate_subca` only checks presence\n- [`lemur/schemas.py:107`](https://github.com/Netflix/lemur/blob/main/lemur/schemas.py#L107) — `AssociatedAuthoritySchema.get_object` → `fetch_objects(Authority, data)` resolves any authority by id/name with no permission check\n- [`lemur/plugins/lemur_cryptography/plugin.py:40`](https://github.com/Netflix/lemur/blob/main/lemur/plugins/lemur_cryptography/plugin.py#L40) — `private_key = options[\"authority\"].authority_certificate.private_key` (set from `options[\"parent\"]`) signs the new intermediate\n- [`lemur/auth/permissions.py:62`](https://github.com/Netflix/lemur/blob/main/lemur/auth/permissions.py#L62) — `AuthorityCreatorPermission` becomes always-allow when `ADMIN_ONLY_AUTHORITY_CREATION=False`\n- [`lemur/certificates/views.py:538`](https://github.com/Netflix/lemur/blob/main/lemur/certificates/views.py#L538) — `is_private_authority` (true for `cryptography-issuer`) skips `USER_DOMAIN_AUTHORIZATION_PROVIDER` for subsequent leaf issuance\n\n## Impact\n\nIn 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:\n\n- 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.\n- Export the sub-CA private key and sign end-entity certificates entirely outside Lemur, defeating all in-product issuance controls.\n\nThis 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.\n\n## Root cause\n\n`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.\n\n## Validated evidence\n\nStatic trace, confirmed by code inspection (validation status: `CONFIRMED`):\n\n- `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.\n- No call to `AuthorityPermission(parent.id, ...)` exists anywhere on this path.\n- Precondition `ADMIN_ONLY_AUTHORITY_CREATION=False` is an explicitly supported config ([`docs/administration.rst:517`](https://github.com/Netflix/lemur/blob/main/docs/administration.rst#L517)).\n\n## Proof of concept / reproducer\n\nStatus: reconstructed from source report (static control-flow trace; not executed against a live CA).\n\nPreconditions: `ADMIN_ONLY_AUTHORITY_CREATION=False`; attacker is an authenticated Lemur user holding any role other than `read-only`; `\u003cPARENT_AUTHORITY_ID\u003e` is any internal `cryptography-issuer` root CA the attacker holds no role on; `\u003cATTACKER_ROLE\u003e` is any role the attacker already belongs to.\n\n```bash\ncurl -sS -X POST \"\u003cTARGET_BASE_URL\u003e/api/1/authorities\" \\\n  -H \"Authorization: Bearer \u003cAUTH_TOKEN\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n        \"name\": \"attacker-subca\",\n        \"owner\": \"attacker@example.com\",\n        \"description\": \"poc\",\n        \"type\": \"subca\",\n        \"parent\": {\"id\": \u003cPARENT_AUTHORITY_ID\u003e},\n        \"plugin\": {\"slug\": \"cryptography-issuer\"},\n        \"roles\": [{\"name\": \"\u003cATTACKER_ROLE\u003e\"}],\n        \"commonName\": \"attacker-intermediate\",\n        \"validityYears\": 1\n      }'\n```\n\nThe response contains a new authority whose `authority_certificate` is signed by `\u003cPARENT_AUTHORITY_ID\u003e`'s private key. The caller is recorded as creator and holds `\u003cATTACKER_ROLE\u003e` on it, so `POST /api/1/certificates` against the new authority succeeds (and skips `allowed_issuance_for_domain` because `is_private_authority` is true).\n\nStatic-trace validation command from the source report:\n\n```bash\ngrep -n 'parent' lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \\\n  \u0026\u0026 sed -n '37,55p' lemur/plugins/lemur_cryptography/plugin.py\n```\n\nSource 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).\n\n## Suggested fix\n\nIn `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.","status":"published","published":"2026-08-19T11:56:28.516318Z","modified":"2026-08-19T12:45:11.231888978Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T15:52:56.847083Z"}]}}