<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 06:39:34 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-71417 — Lemur: Any user can revoke arbitrary certificates at the CA by uploading a duplicate record and revoking it</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-71417</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Netflix lemur&lt;/p&gt;
&lt;p&gt;Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/certificates/upload allowed a non-read-only user to create a duplicate row using another certificate body, authority_id, serial, or external_id without requiring permission on the underlying authority. PUT /api/1/certificates//revoke authorized the caller against only the selected Lemur row, so the creator of the duplicate bypassed CertificatePermission. The duplicate had no cert.endpoints, which also bypassed the safeguard that prevents revocation of deployed certificates. Issuer plugins then revoked the real CA-side certificate using certificate.body or external_id under the stored authority credentials. An attacker could therefore revoke arbitrary managed certificates and cause fleet-wide TLS denial of service. The fix rejects duplicate authority_id and serial identities, requires authority access on upload, and checks every matching row during revocation. This issue is fixed in version 1.9.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Netflix lemur&lt;/p&gt;
&lt;p&gt;Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/certificates/upload allowed a non-read-only user to create a duplicate row using another certificate body, authority_id, serial, or external_id without requiring permission on the underlying authority. PUT /api/1/certificates//revoke authorized the caller against only the selected Lemur row, so the creator of the duplicate bypassed CertificatePermission. The duplicate had no cert.endpoints, which also bypassed the safeguard that prevents revocation of deployed certificates. Issuer plugins then revoked the real CA-side certificate using certificate.body or external_id under the stored authority credentials. An attacker could therefore revoke arbitrary managed certificates and cause fleet-wide TLS denial of service. The fix rejects duplicate authority_id and serial identities, requires authority access on upload, and checks every matching row during revocation. This issue is fixed in version 1.9.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-71417</guid>
    </item>
    <item>
      <title>GHSA-pxmc-2ffp-8j67 — Lemur: Any user can revoke arbitrary certificates at the CA by uploading a duplicate record and revoking it</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pxmc-2ffp-8j67</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: lemur&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Repo under test: https://github.com/Netflix/lemur&lt;/p&gt;
&lt;p&gt;`PUT /api/1/certificates/&amp;lt;id&amp;gt;/revoke` authorizes the caller against the *Lemur database row* (creator == current user, or `CertificatePermission` over the row&amp;#39;s roles) rather than the underlying CA-side certificate identity. Separately, `POST /api/1/certificates/upload` lets any user passing `StrictRolePermission` create a new `Certificate` row while freely supplying `body`, `authority` (resolved by id/name with no `AuthorityPermission` check) and `external_id`; there is no uniqueness constraint on `body`, `serial`, or `external_id`.&lt;/p&gt;
&lt;p&gt;An attacker can therefore read a target certificate&amp;#39;s public `body`, `authority.id`, and `external_id` via `GET /certificates/&amp;lt;id&amp;gt;`, upload a duplicate row, and revoke that duplicate. The creator-bypass skips `CertificatePermission`, the empty-endpoints check passes because the duplicate has none, and `service.revoke()` then revokes at the CA using the attacker-supplied `body` (ACME) or `external_id` (DigiCert/Entrust/Google CA/CFSSL) under the authority&amp;#39;s stored CA credentials — revoking the real production certificate.&lt;/p&gt;
&lt;p&gt;## Affected route&lt;/p&gt;
&lt;p&gt;`POST /api/1/certificates/upload` → `PUT /api/1/certificates/&amp;lt;dup_id&amp;gt;/revoke`&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;- [`lemur/certificates/views.py:651`](https://github.com/Netflix/lemur/blob/main/lemur/certificates/views.py#L651) — only `StrictRolePermission().can()` gates upload; no `AuthorityPermission` check
- [`lemur/certificates/schemas.py:391`](https://githu…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: lemur&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Repo under test: https://github.com/Netflix/lemur&lt;/p&gt;
&lt;p&gt;`PUT /api/1/certificates/&amp;lt;id&amp;gt;/revoke` authorizes the caller against the *Lemur database row* (creator == current user, or `CertificatePermission` over the row&amp;#39;s roles) rather than the underlying CA-side certificate identity. Separately, `POST /api/1/certificates/upload` lets any user passing `StrictRolePermission` create a new `Certificate` row while freely supplying `body`, `authority` (resolved by id/name with no `AuthorityPermission` check) and `external_id`; there is no uniqueness constraint on `body`, `serial`, or `external_id`.&lt;/p&gt;
&lt;p&gt;An attacker can therefore read a target certificate&amp;#39;s public `body`, `authority.id`, and `external_id` via `GET /certificates/&amp;lt;id&amp;gt;`, upload a duplicate row, and revoke that duplicate. The creator-bypass skips `CertificatePermission`, the empty-endpoints check passes because the duplicate has none, and `service.revoke()` then revokes at the CA using the attacker-supplied `body` (ACME) or `external_id` (DigiCert/Entrust/Google CA/CFSSL) under the authority&amp;#39;s stored CA credentials — revoking the real production certificate.&lt;/p&gt;
&lt;p&gt;## Affected route&lt;/p&gt;
&lt;p&gt;`POST /api/1/certificates/upload` → `PUT /api/1/certificates/&amp;lt;dup_id&amp;gt;/revoke`&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;- [`lemur/certificates/views.py:651`](https://github.com/Netflix/lemur/blob/main/lemur/certificates/views.py#L651) — only `StrictRolePermission().can()` gates upload; no `AuthorityPermission` check
- [`lemur/certificates/schemas.py:391`](https://githu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pxmc-2ffp-8j67</guid>
    </item>
  </channel>
</rss>
