https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 03:24:50 +0000 https://vulnerability.circl.lu/vuln/cve-2025-59420 <p><strong>Affected:</strong> authlib</p> <p>Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.4, Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (crit), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, bork or cnf) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation. This issue has been patched in version 1.6.4.</p> <p><strong>Affected:</strong> authlib</p> <p>Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.4, Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (crit), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, bork or cnf) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation. This issue has been patched in version 1.6.4.</p> https://vulnerability.circl.lu/vuln/cve-2025-59420 https://vulnerability.circl.lu/vuln/ghsa-9ggr-2464-2j32 <p><strong>Affected:</strong> PyPI: authlib</p> <p>## Summary Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.</p> <p>## Affected Component and Versions - Library: Authlib (JWS verification) - API: `authlib.jose.JsonWebSignature.deserialize_compact(...)` - Version tested: 1.6.3 - Configuration: Default; no allowlist or special handling for `crit`</p> <p>## Details RFC 7515 (JWS) §4.1.11 defines `crit` as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`.</p> <p>Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with `crit: [&#34;cnf&#34;]` and a `cnf` object, or `crit: [&#34;bork&#34;]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names.</p> <p>Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token,…</p> <p><strong>Affected:</strong> PyPI: authlib</p> <p>## Summary Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.</p> <p>## Affected Component and Versions - Library: Authlib (JWS verification) - API: `authlib.jose.JsonWebSignature.deserialize_compact(...)` - Version tested: 1.6.3 - Configuration: Default; no allowlist or special handling for `crit`</p> <p>## Details RFC 7515 (JWS) §4.1.11 defines `crit` as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`.</p> <p>Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with `crit: [&#34;cnf&#34;]` and a `cnf` object, or `crit: [&#34;bork&#34;]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names.</p> <p>Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token,…</p> https://vulnerability.circl.lu/vuln/ghsa-9ggr-2464-2j32 https://vulnerability.circl.lu/vuln/pysec-2026-1200 <p><strong>Affected:</strong> PyPI: authlib</p> <p>## Summary Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.</p> <p>## Affected Component and Versions - Library: Authlib (JWS verification) - API: `authlib.jose.JsonWebSignature.deserialize_compact(...)` - Version tested: 1.6.3 - Configuration: Default; no allowlist or special handling for `crit`</p> <p>## Details RFC 7515 (JWS) §4.1.11 defines `crit` as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`.</p> <p>Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with `crit: [&#34;cnf&#34;]` and a `cnf` object, or `crit: [&#34;bork&#34;]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names.</p> <p>Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token,…</p> <p><strong>Affected:</strong> PyPI: authlib</p> <p>## Summary Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.</p> <p>## Affected Component and Versions - Library: Authlib (JWS verification) - API: `authlib.jose.JsonWebSignature.deserialize_compact(...)` - Version tested: 1.6.3 - Configuration: Default; no allowlist or special handling for `crit`</p> <p>## Details RFC 7515 (JWS) §4.1.11 defines `crit` as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`.</p> <p>Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with `crit: [&#34;cnf&#34;]` and a `cnf` object, or `crit: [&#34;bork&#34;]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names.</p> <p>Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token,…</p> https://vulnerability.circl.lu/vuln/pysec-2026-1200