https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 11:51:31 +0000 https://cve.radiocsirt.org/vuln/cve-2026-55165 <p><strong>Affected:</strong> Netflix lemur</p> <p>Lemur manages TLS certificate creation. Prior to 1.9.2, the JWT verifier in lemur/auth/service.py:130-137 used fetch_token_header to read header_data[&#34;alg&#34;] from an unverified token and passed that attacker-controlled value to decode_with_multiple_secrets. PyJWT 2.x rejects alg=none with the configured key, so the flaw is a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration. The unpinned algorithm can become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token chooses the recorded value. A separate disclosure of LEMUR_TOKEN_SECRET would also permit forged HS256 tokens, although that disclosure is an independent prerequisite. The fix introduces the server-controlled LEMUR_TOKEN_ALGORITHMS allowlist and defaults it to HS256. This issue is fixed in version 1.9.2.</p> <p><strong>Affected:</strong> Netflix lemur</p> <p>Lemur manages TLS certificate creation. Prior to 1.9.2, the JWT verifier in lemur/auth/service.py:130-137 used fetch_token_header to read header_data[&#34;alg&#34;] from an unverified token and passed that attacker-controlled value to decode_with_multiple_secrets. PyJWT 2.x rejects alg=none with the configured key, so the flaw is a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration. The unpinned algorithm can become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token chooses the recorded value. A separate disclosure of LEMUR_TOKEN_SECRET would also permit forged HS256 tokens, although that disclosure is an independent prerequisite. The fix introduces the server-controlled LEMUR_TOKEN_ALGORITHMS allowlist and defaults it to HS256. This issue is fixed in version 1.9.2.</p> https://cve.radiocsirt.org/vuln/cve-2026-55165 https://cve.radiocsirt.org/vuln/ghsa-r9gp-7f88-9r54 <p><strong>Affected:</strong> PyPI: lemur</p> <p>&lt;!-- obsidian --&gt;&lt;h1 data-heading=&#34;Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure&#34;&gt;Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure&lt;/h1&gt; &lt;h2 data-heading=&#34;Vulnerability Summary&#34;&gt;Vulnerability Summary&lt;/h2&gt;</p> <p>Field | Value -- | -- Title | Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure Component | lemur/lemur/auth/service.py:130-137 CWE | CWE-347 (Improper Verification of Cryptographic Signature) Attack Prerequisite | Defense-in-depth gap on its own — no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur __version__ = &#34;1.9.0&#34;. Same code present in every prior release that has the auth/service.py:130 block.</p> <p>&lt;h2 data-heading=&#34;Executive Summary&#34;&gt;Executive Summary&lt;/h2&gt; &lt;p&gt;The Lemur JWT verifier reads the &lt;code&gt;alg&lt;/code&gt; header field from the &lt;em&gt;unverified&lt;/em&gt; token and passes it straight into &lt;code&gt;pyjwt.decode(..., algorithms=[header[&#39;alg&#39;]])&lt;/code&gt;. This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x&#39;s default config rejects &lt;code&gt;alg=none&lt;/code&gt;, so this is n…</p> <p><strong>Affected:</strong> PyPI: lemur</p> <p>&lt;!-- obsidian --&gt;&lt;h1 data-heading=&#34;Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure&#34;&gt;Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure&lt;/h1&gt; &lt;h2 data-heading=&#34;Vulnerability Summary&#34;&gt;Vulnerability Summary&lt;/h2&gt;</p> <p>Field | Value -- | -- Title | Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure Component | lemur/lemur/auth/service.py:130-137 CWE | CWE-347 (Improper Verification of Cryptographic Signature) Attack Prerequisite | Defense-in-depth gap on its own — no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur __version__ = &#34;1.9.0&#34;. Same code present in every prior release that has the auth/service.py:130 block.</p> <p>&lt;h2 data-heading=&#34;Executive Summary&#34;&gt;Executive Summary&lt;/h2&gt; &lt;p&gt;The Lemur JWT verifier reads the &lt;code&gt;alg&lt;/code&gt; header field from the &lt;em&gt;unverified&lt;/em&gt; token and passes it straight into &lt;code&gt;pyjwt.decode(..., algorithms=[header[&#39;alg&#39;]])&lt;/code&gt;. This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x&#39;s default config rejects &lt;code&gt;alg=none&lt;/code&gt;, so this is n…</p> https://cve.radiocsirt.org/vuln/ghsa-r9gp-7f88-9r54