<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T20:39:40.893145+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-71322</id>
    <title>CVE-2026-71322 — Lemur: Missing authorization check on POST /certificates/&lt;id&gt;/export for plugins with requires_key = False</title>
    <updated>2026-10-01T20:39:40.927837+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Netflix lemur</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-71322"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/pysec-2026-3673</id>
    <title>PYSEC-2026-3673 — Lemur: Missing authorization check on POST /certificates/&lt;id&gt;/export for plugins with requires_key = False</title>
    <updated>2026-10-01T20:39:40.927952+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: lemur</p>
<p>## Summary
 
The `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.
 
## Root Cause
 
`lemur/certificates/views.py:1573`:
 
```python
if plugin.requires_key:
    if not cert.private_key:
        return (..., 400)
    else:
        if g.current_user != cert.user:
            owner_role = role_service.get_by_name(cert.owner)
            permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
            if not permission.can():
                return (..., 403)
 
log_service.create(g.current_user, "key_view", certificate=cert)   # always logged
extension, passphrase, data = plugin.export(
    cert.body, cert.chain, cert.private_key, options
)
```
 
The 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…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/pysec-2026-3673"/>
  </entry>
</feed>
