Affected: Homebrew: fastmcp

## Description

### Summary

A JWK Header Injection vulnerability in `authlib`'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 behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**.

### Details

**Vulnerable file:** `authlib/jose/rfc7515/jws.py` **Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()` **Lines:** 272–273

```python elif key is None and "jwk" in header: key = header["jwk"] # ← attacker-controlled key used for verification ```

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.

**RFC 7515 violations:**

- **§4.1.3** explicitly states the `jwk` header parameter is **"NOT RECOMMENDED"** because keys embedded by the token submitter cannot be trusted as a verification anchor. - **§5.2 (Validation Algorithm)** sp…

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'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.

Affected: PyPI: authlib

## Description

### Summary

A JWK Header Injection vulnerability in `authlib`'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 behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**.

### Details

**Vulnerable file:** `authlib/jose/rfc7515/jws.py` **Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()` **Lines:** 272–273

```python elif key is None and "jwk" in header: key = header["jwk"] # ← attacker-controlled key used for verification ```

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.

**RFC 7515 violations:**

- **§4.1.3** explicitly states the `jwk` header parameter is **"NOT RECOMMENDED"** because keys embedded by the token submitter cannot be trusted as a verification anchor. - **§5.2 (Validation Algorithm)** sp…

Security update for python-Authlib

Affected: PyPI: authlib

## Description

### Summary

A JWK Header Injection vulnerability in `authlib`'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 behavior violates **RFC 7515 §4.1.3** and the validation algorithm defined in **RFC 7515 §5.2**.

### Details

**Vulnerable file:** `authlib/jose/rfc7515/jws.py` **Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()` **Lines:** 272–273

```python elif key is None and "jwk" in header: key = header["jwk"] # ← attacker-controlled key used for verification ```

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.

**RFC 7515 violations:**

- **§4.1.3** explicitly states the `jwk` header parameter is **"NOT RECOMMENDED"** because keys embedded by the token submitter cannot be trusted as a verification anchor. - **§5.2 (Validation Algorithm)**…

golang: net/url: Memory exhaustion in query parameter parsing in net/url axios: Axios: Server-Side Request Forgery and proxy bypass due to improper hostname normalization mirror-registry: quay: quay: Server-Side Request Forgery via log export functionality jsrsasign: jsrsasign: Denial of Service via infinite loop in bnModInverse function with crafted inputs jsrsasign: jsrsasign: Private key recovery via incomplete comparison checks biasing DSA nonces jsrsasign: jsrsasign: Cryptographic signature forgery via malicious DSA domain parameters jsrsasign: jsrsasign: Private Key Recovery via Missing Cryptographic Step in DSA Signing jsrsasign: jsrsasign: Signature verification bypass via negative exponent handling net/url: Incorrect parsing of IPv6 host literals in net/url crypto/x509: Incorrect enforcement of email constraints in crypto/x509 pyOpenSSL: DTLS cookie callback buffer overflow authlib: Authlib: Authentication bypass due to JWK Header Injection vulnerability authlib: Authlib: Signature verification bypass via malicious JWT allows unauthorized access immutable-js: Immutable.js: Arbitrary code execution via Prototype Pollution svgo: SVGO: Denial of Service via XML entity expansion pyasn1: pyasn1 Vulnerable to Denial of Service via Unbounded Recursion crypto/x509: crypto/tls: golang: Go: Denial of Service vulnerability in certificate chain building golang: internal/syscall/unix: Root.Chmod can follow symlinks out of the root github.com/jackc/pgproto3/v2: github.com/jackc/p…

Affected: Ubuntu:Pro:22.04:LTS: python-authlib, Ubuntu:Pro:24.04:LTS: python-authlib, Ubuntu:25.10: python-authlib, Ubuntu:Pro:26.04:LTS: python-authlib

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'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.