<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 13:32:12 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-27962 — Authlib JWS JWK Header Injection: Signature Verification Bypass</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-27962</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; authlib, Red Hat Quay 3.10, Red Hat Quay 3.14, Red Hat Quay 3.15, Red Hat Quay 3.16, Red Hat Quay 3.18, Red Hat Lightspeed Core, Red Hat Ansible Automation Platform 2, Red Hat OpenShift AI (RHOAI), Red Hat Satellite 6&lt;/p&gt;
&lt;p&gt;Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.9, a JWK Header Injection vulnerability in authlib&amp;#39;s JWS implementation allows an unauthenticated attacker to forge arbitrary JWT tokens that pass signature verification. When key=None is passed to any JWS deserialization function, the library extracts and uses the cryptographic key embedded in the attacker-controlled JWT jwk header field. An attacker can sign a token with their own private key, embed the matching public key in the header, and have the server accept the forged token as cryptographically valid — bypassing authentication and authorization entirely. This issue has been patched in version 1.6.9.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; authlib, Red Hat Quay 3.10, Red Hat Quay 3.14, Red Hat Quay 3.15, Red Hat Quay 3.16, Red Hat Quay 3.18, Red Hat Lightspeed Core, Red Hat Ansible Automation Platform 2, Red Hat OpenShift AI (RHOAI), Red Hat Satellite 6&lt;/p&gt;
&lt;p&gt;Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.9, a JWK Header Injection vulnerability in authlib&amp;#39;s JWS implementation allows an unauthenticated attacker to forge arbitrary JWT tokens that pass signature verification. When key=None is passed to any JWS deserialization function, the library extracts and uses the cryptographic key embedded in the attacker-controlled JWT jwk header field. An attacker can sign a token with their own private key, embed the matching public key in the header, and have the server accept the forged token as cryptographically valid — bypassing authentication and authorization entirely. This issue has been patched in version 1.6.9.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-27962</guid>
    </item>
    <item>
      <title>GHSA-wvwj-cvrp-7pv5 — Authlib JWS JWK Header Injection: Signature Verification Bypass</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-wvwj-cvrp-7pv5</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: authlib&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A JWK Header Injection vulnerability in `authlib`&amp;#39;s JWS implementation allows an unauthenticated
attacker to forge arbitrary JWT tokens that pass signature verification. When `key=None` is passed
to any JWS deserialization function, the library extracts and uses the cryptographic key embedded
in the attacker-controlled JWT `jwk` header field. An attacker can sign a token with their own
private key, embed the matching public key in the header, and have the server accept the forged
token as cryptographically valid — bypassing authentication and authorization entirely.&lt;/p&gt;
&lt;p&gt;This behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;**Vulnerable file:** `authlib/jose/rfc7515/jws.py`  
**Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()`  
**Lines:** 272–273&lt;/p&gt;
&lt;p&gt;```python
elif key is None and &amp;#34;jwk&amp;#34; in header:
    key = header[&amp;#34;jwk&amp;#34;]   # ← attacker-controlled key used for verification
```&lt;/p&gt;
&lt;p&gt;When `key=None` is passed to `jws.deserialize_compact()`, `jws.deserialize_json()`, or
`jws.deserialize()`, the library checks the JWT header for a `jwk` field. If present, it extracts
that value — which is fully attacker-controlled — and uses it as the verification key.&lt;/p&gt;
&lt;p&gt;**RFC 7515 violations:**&lt;/p&gt;
&lt;p&gt;- **§4.1.3** explicitly states the `jwk` header parameter is **&amp;#34;NOT RECOMMENDED&amp;#34;** because keys
  embedded by the token submitter cannot be trusted as a verification anchor.
- **§5.2 (Validation Algorithm)** sp…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: authlib&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A JWK Header Injection vulnerability in `authlib`&amp;#39;s JWS implementation allows an unauthenticated
attacker to forge arbitrary JWT tokens that pass signature verification. When `key=None` is passed
to any JWS deserialization function, the library extracts and uses the cryptographic key embedded
in the attacker-controlled JWT `jwk` header field. An attacker can sign a token with their own
private key, embed the matching public key in the header, and have the server accept the forged
token as cryptographically valid — bypassing authentication and authorization entirely.&lt;/p&gt;
&lt;p&gt;This behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;**Vulnerable file:** `authlib/jose/rfc7515/jws.py`  
**Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()`  
**Lines:** 272–273&lt;/p&gt;
&lt;p&gt;```python
elif key is None and &amp;#34;jwk&amp;#34; in header:
    key = header[&amp;#34;jwk&amp;#34;]   # ← attacker-controlled key used for verification
```&lt;/p&gt;
&lt;p&gt;When `key=None` is passed to `jws.deserialize_compact()`, `jws.deserialize_json()`, or
`jws.deserialize()`, the library checks the JWT header for a `jwk` field. If present, it extracts
that value — which is fully attacker-controlled — and uses it as the verification key.&lt;/p&gt;
&lt;p&gt;**RFC 7515 violations:**&lt;/p&gt;
&lt;p&gt;- **§4.1.3** explicitly states the `jwk` header parameter is **&amp;#34;NOT RECOMMENDED&amp;#34;** because keys
  embedded by the token submitter cannot be trusted as a verification anchor.
- **§5.2 (Validation Algorithm)** sp…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-wvwj-cvrp-7pv5</guid>
    </item>
    <item>
      <title>PYSEC-2026-287 — Authlib JWS JWK Header Injection: Signature Verification Bypass</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-287</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: authlib&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A JWK Header Injection vulnerability in `authlib`&amp;#39;s JWS implementation allows an unauthenticated
attacker to forge arbitrary JWT tokens that pass signature verification. When `key=None` is passed
to any JWS deserialization function, the library extracts and uses the cryptographic key embedded
 in the attacker-controlled JWT `jwk` header field. An attacker can sign a token with their own
private key, embed the matching public key in the header, and have the server accept the forged
token as cryptographically valid — bypassing authentication and authorization entirely.&lt;/p&gt;
&lt;p&gt;This behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;**Vulnerable file:** `authlib/jose/rfc7515/jws.py`  
**Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()`  
**Lines:** 272–273&lt;/p&gt;
&lt;p&gt;```python
elif key is None and &amp;#34;jwk&amp;#34; in header:
    key = header[&amp;#34;jwk&amp;#34;]   # ← attacker-controlled key used for verification
 ```&lt;/p&gt;
&lt;p&gt;When `key=None` is passed to `jws.deserialize_compact()`, `jws.deserialize_json()`, or
`jws.deserialize()`, the library checks the JWT header for a `jwk` field. If present, it extracts
that value — which is fully attacker-controlled — and uses it as the verification key.&lt;/p&gt;
&lt;p&gt;**RFC 7515 violations:**&lt;/p&gt;
&lt;p&gt;- **§4.1.3** explicitly states the `jwk` header parameter is **&amp;#34;NOT RECOMMENDED&amp;#34;** because keys
  embedded by the token submitter cannot be trusted as a verification anchor.
- **§5.2 (Validation Algorithm)**…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: authlib&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A JWK Header Injection vulnerability in `authlib`&amp;#39;s JWS implementation allows an unauthenticated
attacker to forge arbitrary JWT tokens that pass signature verification. When `key=None` is passed
to any JWS deserialization function, the library extracts and uses the cryptographic key embedded
 in the attacker-controlled JWT `jwk` header field. An attacker can sign a token with their own
private key, embed the matching public key in the header, and have the server accept the forged
token as cryptographically valid — bypassing authentication and authorization entirely.&lt;/p&gt;
&lt;p&gt;This behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;**Vulnerable file:** `authlib/jose/rfc7515/jws.py`  
**Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()`  
**Lines:** 272–273&lt;/p&gt;
&lt;p&gt;```python
elif key is None and &amp;#34;jwk&amp;#34; in header:
    key = header[&amp;#34;jwk&amp;#34;]   # ← attacker-controlled key used for verification
 ```&lt;/p&gt;
&lt;p&gt;When `key=None` is passed to `jws.deserialize_compact()`, `jws.deserialize_json()`, or
`jws.deserialize()`, the library checks the JWT header for a `jwk` field. If present, it extracts
that value — which is fully attacker-controlled — and uses it as the verification key.&lt;/p&gt;
&lt;p&gt;**RFC 7515 violations:**&lt;/p&gt;
&lt;p&gt;- **§4.1.3** explicitly states the `jwk` header parameter is **&amp;#34;NOT RECOMMENDED&amp;#34;** because keys
  embedded by the token submitter cannot be trusted as a verification anchor.
- **§5.2 (Validation Algorithm)**…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-287</guid>
    </item>
  </channel>
</rss>
