{
  "affected": [
    {
      "affectedData": [
        {
          "product": "lemur",
          "vendor": "Netflix",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.9.3"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Lemur manages TLS certificate creation. Prior to 1.9.3, CertificateExport placed its CertificatePermission ownership check inside the plugin.requires_key branch for POST /api/1/certificates//export. A plugin declaring requires_key false bypassed that check, and the handler still passed cert.private_key as an argument and recorded a key_view audit event. The bundled JavaTruststoreExportPlugin ignored the key, so the immediate exposure was limited to public certificate material and misleading audit entries, but a future plugin could have consumed the supplied key. The fix passes no private key to plugins that do not require one and confines ownership checks and key_view logging to actual private-key exports. This issue is fixed in version 1.9.3."
    }
  ],
  "id": "CVE-2026-71322",
  "lastModified": "2026-09-08T21:02:26.047",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 4.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "LOW",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 1.4,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-71322",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-19T18:03:59.629156Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-18T20:17:24.073",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/Netflix/lemur/commit/5683bbea8b10cce07f9a8abf1e4a7d3b2031c585"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-4h97-p9wq-chqj"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-862"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T20:51:42Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n \nThe `CertificateExport` handler in `lemur/certificates/views.py` nests its entire ownership / `CertificatePermission` check inside an `if plugin.requires_key:` branch. When the selected export plugin advertises `requires_key = False`, the authorization check is skipped entirely and any authenticated user can invoke `plugin.export(cert.body, cert.chain, cert.private_key, options)` against a certificate they do not own. The handler additionally writes a `\"key_view\"` audit-log event for every call, regardless of whether the plugin actually accessed the private key, polluting the audit trail with false positives.\n \n## Root Cause\n \n`lemur/certificates/views.py:1573`:\n \n```python\nif plugin.requires_key:\n    if not cert.private_key:\n        return (..., 400)\n    else:\n        if g.current_user != cert.user:\n            owner_role = role_service.get_by_name(cert.owner)\n            permission = CertificatePermission(owner_role, [x.name for x in cert.roles])\n            if not permission.can():\n                return (..., 403)\n \nlog_service.create(g.current_user, \"key_view\", certificate=cert)   # always logged\nextension, passphrase, data = plugin.export(\n    cert.body, cert.chain, cert.private_key, options\n)\n```\n \nThe authorization gate is structurally inside the `if plugin.requires_key:` block. With `requires_key = False`, control falls straight through to `plugin.export(...)` with no ownership check. The `cert.private_key` is passed to the plugin regardless of the flag \u2014 the flag only describes what the plugin *advertises* it needs, not what it actually receives.\n \nThe only currently shipping `ExportPlugin` with `requires_key = False` is `JavaTruststoreExportPlugin` (`lemur/plugins/lemur_jks/plugin.py`), whose `export()` ignores the `key` argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:\n \n1. The structural defect is latent and silent - any future `requires_key = False` `ExportPlugin` that *does* read `cert.private_key` will inherit the bypass with no test or code-review signal.\n2. The unconditional `log_service.create(..., \"key_view\", ...)` call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.\n \n## Affected Endpoints\n \n| Method | Path | Source |\n|---|---|---|\n| POST | /api/1/certificates/`\u003cid\u003e`/export | lemur/certificates/views.py:1573 |\n \n## Impact\n \nIn the current codebase:\n \n- Any authenticated user can mint a Java truststore (`java-truststore-jks` plugin) containing any certificate\u0027s public body and chain, without owning the certificate or holding a role with permission over it.\n- The audit log records a `key_view` event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.\n \nLatent risk:\n \n- A future `ExportPlugin` author who sets `requires_key = False` because their plugin can *operate* without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this \u2014 the authorization invariant is held by a structurally distant `if`-branch in the view, not by the plugin itself.\n \n## Remediation\n \nLift the authorization check out of the `if plugin.requires_key:` block so it runs for every export call:\n \n```python\n# Authorization first, unconditionally.\nif g.current_user != cert.user:\n    owner_role = role_service.get_by_name(cert.owner)\n    permission = CertificatePermission(owner_role, [x.name for x in cert.roles])\n    if not permission.can():\n        return (dict(message=\"You are not authorized to export this certificate.\"), 403)\n \nif plugin.requires_key:\n    if not cert.private_key:\n        return (dict(message=\"Plugin requires a key but none is present.\"), 400)\n    log_service.create(g.current_user, \"key_view\", certificate=cert)   # only when key actually accessed\n \nextension, passphrase, data = plugin.export(\n    cert.body, cert.chain, cert.private_key, options\n)\n```\n \nThis makes the authorization gate independent of the plugin\u0027s `requires_key` flag and correctly scopes the `key_view` audit event to calls that actually involve key access.\n \n## Steps to Reproduce\n \n1. Set up Lemur with default configuration. Create an admin user `admin` and a non-admin user `eve` with the `read-only` role (or any role without certificate permissions).\n \n2. As `admin`, issue a certificate. Note its `id`.\n \n3. As `eve`, invoke export with the `java-truststore-jks` plugin:\n````\n   curl -X POST https://lemur.local/api/1/certificates/\u003ccert_id\u003e/export \\\n        -H \"Authorization: Bearer \u003ceve_jwt\u003e\" \\\n        -H \"Content-Type: application/json\" \\\n        -d \u0027{\n              \"plugin\": {\n                \"slug\": \"java-truststore-jks\",\n                \"plugin_options\": [\n                  {\"name\": \"passphrase\", \"value\": \"test\"}\n                ]\n              }\n            }\u0027\n````\n \n4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. `eve` had no permission over `admin`\u0027s certificate, yet successfully exported its public material.\n \n5. Inspect the audit log table or `lemur logs list`:\n````\n   psql lemur -c \"SELECT user_id, log_type, certificate_id, logged_at FROM logs\n                  WHERE certificate_id = \u003ccert_id\u003e ORDER BY logged_at DESC LIMIT 1;\"\n````\n   The log row shows `log_type = \u0027key_view\u0027` for `eve` against `admin`\u0027s certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.",
  "id": "GHSA-4h97-p9wq-chqj",
  "modified": "2026-08-18T20:51:42Z",
  "published": "2026-08-18T20:51:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-4h97-p9wq-chqj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/commit/5683bbea8b10cce07f9a8abf1e4a7d3b2031c585"
    },
    {
      "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:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur: Missing authorization check on POST /certificates/\u003cid\u003e/export for plugins with requires_key = False"
}

{
  "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-71322",
    "GHSA-4h97-p9wq-chqj"
  ],
  "details": "## Summary\n \nThe `CertificateExport` handler in `lemur/certificates/views.py` nests its entire ownership / `CertificatePermission` check inside an `if plugin.requires_key:` branch. When the selected export plugin advertises `requires_key = False`, the authorization check is skipped entirely and any authenticated user can invoke `plugin.export(cert.body, cert.chain, cert.private_key, options)` against a certificate they do not own. The handler additionally writes a `\"key_view\"` audit-log event for every call, regardless of whether the plugin actually accessed the private key, polluting the audit trail with false positives.\n \n## Root Cause\n \n`lemur/certificates/views.py:1573`:\n \n```python\nif plugin.requires_key:\n    if not cert.private_key:\n        return (..., 400)\n    else:\n        if g.current_user != cert.user:\n            owner_role = role_service.get_by_name(cert.owner)\n            permission = CertificatePermission(owner_role, [x.name for x in cert.roles])\n            if not permission.can():\n                return (..., 403)\n \nlog_service.create(g.current_user, \"key_view\", certificate=cert)   # always logged\nextension, passphrase, data = plugin.export(\n    cert.body, cert.chain, cert.private_key, options\n)\n```\n \nThe authorization gate is structurally inside the `if plugin.requires_key:` block. With `requires_key = False`, control falls straight through to `plugin.export(...)` with no ownership check. The `cert.private_key` is passed to the plugin regardless of the flag \u2014 the flag only describes what the plugin *advertises* it needs, not what it actually receives.\n \nThe only currently shipping `ExportPlugin` with `requires_key = False` is `JavaTruststoreExportPlugin` (`lemur/plugins/lemur_jks/plugin.py`), whose `export()` ignores the `key` argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:\n \n1. The structural defect is latent and silent - any future `requires_key = False` `ExportPlugin` that *does* read `cert.private_key` will inherit the bypass with no test or code-review signal.\n2. The unconditional `log_service.create(..., \"key_view\", ...)` call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.\n \n## Affected Endpoints\n \n| Method | Path | Source |\n|---|---|---|\n| POST | /api/1/certificates/`\u003cid\u003e`/export | lemur/certificates/views.py:1573 |\n \n## Impact\n \nIn the current codebase:\n \n- Any authenticated user can mint a Java truststore (`java-truststore-jks` plugin) containing any certificate\u0027s public body and chain, without owning the certificate or holding a role with permission over it.\n- The audit log records a `key_view` event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.\n \nLatent risk:\n \n- A future `ExportPlugin` author who sets `requires_key = False` because their plugin can *operate* without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this \u2014 the authorization invariant is held by a structurally distant `if`-branch in the view, not by the plugin itself.\n \n## Remediation\n \nLift the authorization check out of the `if plugin.requires_key:` block so it runs for every export call:\n \n```python\n# Authorization first, unconditionally.\nif g.current_user != cert.user:\n    owner_role = role_service.get_by_name(cert.owner)\n    permission = CertificatePermission(owner_role, [x.name for x in cert.roles])\n    if not permission.can():\n        return (dict(message=\"You are not authorized to export this certificate.\"), 403)\n \nif plugin.requires_key:\n    if not cert.private_key:\n        return (dict(message=\"Plugin requires a key but none is present.\"), 400)\n    log_service.create(g.current_user, \"key_view\", certificate=cert)   # only when key actually accessed\n \nextension, passphrase, data = plugin.export(\n    cert.body, cert.chain, cert.private_key, options\n)\n```\n \nThis makes the authorization gate independent of the plugin\u0027s `requires_key` flag and correctly scopes the `key_view` audit event to calls that actually involve key access.\n \n## Steps to Reproduce\n \n1. Set up Lemur with default configuration. Create an admin user `admin` and a non-admin user `eve` with the `read-only` role (or any role without certificate permissions).\n \n2. As `admin`, issue a certificate. Note its `id`.\n \n3. As `eve`, invoke export with the `java-truststore-jks` plugin:\n````\n   curl -X POST https://lemur.local/api/1/certificates/\u003ccert_id\u003e/export \\\n        -H \"Authorization: Bearer \u003ceve_jwt\u003e\" \\\n        -H \"Content-Type: application/json\" \\\n        -d \u0027{\n              \"plugin\": {\n                \"slug\": \"java-truststore-jks\",\n                \"plugin_options\": [\n                  {\"name\": \"passphrase\", \"value\": \"test\"}\n                ]\n              }\n            }\u0027\n````\n \n4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. `eve` had no permission over `admin`\u0027s certificate, yet successfully exported its public material.\n \n5. Inspect the audit log table or `lemur logs list`:\n````\n   psql lemur -c \"SELECT user_id, log_type, certificate_id, logged_at FROM logs\n                  WHERE certificate_id = \u003ccert_id\u003e ORDER BY logged_at DESC LIMIT 1;\"\n````\n   The log row shows `log_type = \u0027key_view\u0027` for `eve` against `admin`\u0027s certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.",
  "id": "PYSEC-2026-3673",
  "modified": "2026-08-19T12:16:27.253040Z",
  "published": "2026-08-19T11:56:28.566866Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-4h97-p9wq-chqj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/commit/5683bbea8b10cce07f9a8abf1e4a7d3b2031c585"
    },
    {
      "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-4h97-p9wq-chqj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71322"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur: Missing authorization check on POST /certificates/\u003cid\u003e/export for plugins with requires_key = False"
}