<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T23:00:13.401652+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-70666</id>
    <title>CVE-2026-70666 — Lemur: Server-Side Request Forgery via the ACME client following server-controlled URLs</title>
    <updated>2026-10-02T23:00:13.403301+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, an authority-role member could update acme_url through PUT /api/1/authorities/ without revalidation and direct setup_acme_client_no_retry to an attacker-controlled ACME server. ACME directory and order responses contain newNonce, newOrder, authorizations, and finalize URLs chosen by that server. The Lemur ClientV2 followed those URLs without requiring their host to match the configured directory host, allowing JWS-signed requests to internal services or cloud metadata endpoints. The issue required an ACME authority and a user authorized for that authority, but did not require global administrator privileges. The fix revalidates updates and introduces _PinnedClientNetwork to enforce a single allowed host for the complete ACME flow. This issue is fixed in version 1.9.3.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-70666"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-xpmj-wjcp-6pww</id>
    <title>GHSA-xpmj-wjcp-6pww — Lemur: Server-Side Request Forgery via the ACME client following server-controlled URLs</title>
    <updated>2026-10-02T23:00:13.403357+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: lemur</p>
<p>### Summary
The ACME client (used to issue certificates from Let's Encrypt / Google Public CA / private ACME CAs) connects to an `acme_url`, then issues requests to URLs that the **ACME server returns** in its directory/order/authorization/finalize responses - this is the classic ACME-client SSRF (RFC 8555 design). Lemur validates `acme_url` against an allowlist of public ACME directories, but **only at authority creation**. The authority UPDATE path (`PUT /authorities/&lt;id&gt;`) accepts a new `options` blob with an arbitrary `acme_url` and never re-validates. An attacker who is a member of an authority's role can repoint an existing ACME authority at a malicious ACME server they control, which returns internal URLs in its responses - coercing Lemur into making JWS-signed POST requests to internal services during the next certificate issuance.</p>
<p>### Detail
**Defect A - allowlist only at creation.**
`_validate_acme_url` (`lemur/plugins/lemur_acme/plugin.py:35-53`) restricts the host to `{acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org, dv.acme-v02.api.pki.goog}`. It runs **only inside `create_authority`** (lines 337, 481). The update path stores `options` verbatim:
```python
# lemur/authorities/views.py:417-424  (Authorities.put)
return service.update(
    authority_id,
    owner=data["owner"], description=data["description"],
    active=data["active"], roles=data["roles"],
    options=data.get("options")          # &lt;- acme_url lives here, NO re-validation
)
```…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-xpmj-wjcp-6pww"/>
  </entry>
</feed>
