Vulnerability-Lookup

GHSA-G7P5-89MH-248H

Vulnerability from github – Published: 2026-08-18 20:51 – Updated: 2026-08-18 20:51

Summary

Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority

Details

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

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:

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.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.9.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T20:51:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## 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 \u2192 mint \u2192 cryptography-issuer.create_authority`, which loads `options[\"parent\"].authority_certificate.private_key` and signs a brand-new intermediate CA on the caller\u0027s behalf.\n\nAny authenticated non-read-only user can therefore mint a sub-CA chained to any internal root whose private key Lemur holds \u2014 including roots they hold no role on \u2014 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) \u2014 gates only on `AuthorityCreatorPermission()` + `StrictRolePermission()`; no `AuthorityPermission` on `data[\u0027parent\u0027]`\n- [`lemur/authorities/schemas.py:58`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/schemas.py#L58) \u2014 `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) \u2014 `AssociatedAuthoritySchema.get_object` \u2192 `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) \u2014 `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) \u2014 `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) \u2014 `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 \u2014 with zero permission on a given internal root CA \u2014 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\u0027s 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 \u2192 service.create \u2192 mint \u2192 plugin.create_authority \u2192 issue_certificate`, where the parent authority\u0027s 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 \u0027{\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      }\u0027\n```\n\nThe response contains a new authority whose `authority_certificate` is signed by `\u003cPARENT_AUTHORITY_ID\u003e`\u0027s 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 \u0027parent\u0027 lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \\\n  \u0026\u0026 sed -n \u002737,55p\u0027 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(\u0027parent\u0027)` 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.",
  "id": "GHSA-g7p5-89mh-248h",
  "modified": "2026-08-18T20:51:38Z",
  "published": "2026-08-18T20:51:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-g7p5-89mh-248h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/commit/8669011203ca3dd89d9e39bab9ef6850eca723f9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Netflix/lemur"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority"
}

CVE-2026-71317 (GCVE-0-2026-71317)

Vulnerability from cvelistv5 – Published: 2026-08-18 19:06 – Updated: 2026-08-19 19:21

Title

Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority

Summary

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

6.5 (Medium)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-19 15:17 UTC

CWE

CWE-862 - Missing Authorization

Assigner

GitHub_M mitre root

References

3 references

URL	Tags
https://github.com/Netflix/lemur/security/advisor…	x_refsource_CONFIRM
https://github.com/Netflix/lemur/commit/866901120…	x_refsource_MISC
https://github.com/Netflix/lemur/releases/tag/v1.9.3	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
Netflix	lemur	Affected: < 1.9.3

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-71317",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-19T15:17:29.453382Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-19T19:21:56.406Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "not-applicable"
            ],
            "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-g7p5-89mh-248h"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "lemur",
          "vendor": "Netflix",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.9.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-862",
              "description": "CWE-862: Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-18T19:06:27.618Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Netflix/lemur/security/advisories/GHSA-g7p5-89mh-248h",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-g7p5-89mh-248h"
        },
        {
          "name": "https://github.com/Netflix/lemur/commit/8669011203ca3dd89d9e39bab9ef6850eca723f9",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Netflix/lemur/commit/8669011203ca3dd89d9e39bab9ef6850eca723f9"
        },
        {
          "name": "https://github.com/Netflix/lemur/releases/tag/v1.9.3",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
        }
      ],
      "source": {
        "advisory": "GHSA-g7p5-89mh-248h",
        "discovery": "UNKNOWN"
      },
      "title": "Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-71317",
    "datePublished": "2026-08-18T19:06:27.618Z",
    "dateReserved": "2026-08-05T18:14:42.064Z",
    "dateUpdated": "2026-08-19T19:21:56.406Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

PYSEC-2026-3677

Vulnerability from pysec - Published: 2026-08-19 11:56 - Updated: 2026-08-19 12:16

Details

Summary

Repo under test: https://github.com/Netflix/lemur

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

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.

Root cause

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).

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
      }'

Static-trace validation command from the source report:

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

Suggested fix

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

Impacted products

Name	purl
lemur	pkg:pypi/lemur

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur",
        "purl": "pkg:pypi/lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "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"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71317",
    "GHSA-g7p5-89mh-248h"
  ],
  "details": "## 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 \u2192 mint \u2192 cryptography-issuer.create_authority`, which loads `options[\"parent\"].authority_certificate.private_key` and signs a brand-new intermediate CA on the caller\u0027s behalf.\n\nAny authenticated non-read-only user can therefore mint a sub-CA chained to any internal root whose private key Lemur holds \u2014 including roots they hold no role on \u2014 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) \u2014 gates only on `AuthorityCreatorPermission()` + `StrictRolePermission()`; no `AuthorityPermission` on `data[\u0027parent\u0027]`\n- [`lemur/authorities/schemas.py:58`](https://github.com/Netflix/lemur/blob/main/lemur/authorities/schemas.py#L58) \u2014 `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) \u2014 `AssociatedAuthoritySchema.get_object` \u2192 `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) \u2014 `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) \u2014 `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) \u2014 `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 \u2014 with zero permission on a given internal root CA \u2014 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\u0027s 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 \u2192 service.create \u2192 mint \u2192 plugin.create_authority \u2192 issue_certificate`, where the parent authority\u0027s 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 \u0027{\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      }\u0027\n```\n\nThe response contains a new authority whose `authority_certificate` is signed by `\u003cPARENT_AUTHORITY_ID\u003e`\u0027s 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 \u0027parent\u0027 lemur/authorities/schemas.py lemur/authorities/views.py lemur/authorities/service.py \\\n  \u0026\u0026 sed -n \u002737,55p\u0027 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(\u0027parent\u0027)` 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.",
  "id": "PYSEC-2026-3677",
  "modified": "2026-08-19T12:16:27.512565Z",
  "published": "2026-08-19T11:56:28.516318Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-g7p5-89mh-248h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/commit/8669011203ca3dd89d9e39bab9ef6850eca723f9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Netflix/lemur"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/lemur"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-g7p5-89mh-248h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71317"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-G7P5-89MH-248H

Summary

Affected route

Affected code

Impact

Root cause

Validated evidence

Proof of concept / reproducer

Suggested fix

CVE-2026-71317 (GCVE-0-2026-71317)

PYSEC-2026-3677

Summary

Affected route

Affected code

Impact

Root cause

Validated evidence

Proof of concept / reproducer

Suggested fix

Tags

Sightings

Nomenclature