chore(deps): update security vulnerabilities [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
Authlib	==0.14.3 -> ==1.6.5
Flask-Cors	~=3.0.6 -> ~=6.0.0
Werkzeug (changelog)	==2.2.3 -> ==3.0.6
next (source)	14.2.26 -> 14.2.32
requests (source, changelog)	==2.31.0 -> ==2.32.4
urllib3 (changelog)	==1.26.16 -> ==2.5.0

GitHub Vulnerability Alerts

CVE-2025-59420

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.

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

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.

Observed behavior with Authlib 1.6.3:

• When a compact JWS contains a protected header with crit: ["cnf"] and a cnf object, or crit: ["bork"] 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.

Impact in heterogeneous fleets:

• A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split‑brain acceptance bypasses intended security policies and can enable replay or privilege escalation if crit carries binding or policy information.

Proof of Concept (PoC)

This repository provides a multi‑runtime PoC demonstrating the issue across Python (Authlib), Node (jose v5), and Java (Nimbus).

Prerequisites

• Python 3.8+
• Node.js 18+
• Java 11+ with Maven

Setup

Enter the directory authlib-crit-bypass-poc & run following commands.

make setup
make tokens

Tokens minted

• tokens/unknown_crit.jwt with protected header:
  { "alg": "HS256", "crit": ["bork"], "bork": "x" }
• tokens/cnf_header.jwt with protected header:
  { "alg": "HS256", "crit": ["cnf"], "cnf": {"jkt": "thumb-42"} }

Reproduction

Run the cross‑runtime demo:

make  demo

Expected output for each token (strict verifiers reject; Authlib accepts):

For tokens/unknown_crit.jwt:

Strict(Nimbus): REJECTED (unknown critical header: bork)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

For tokens/cnf_header.jwt:

Strict(Nimbus): REJECTED (unknown critical header: cnf)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

Environment notes:

• Authlib version used: 1.6.3 (from PyPI)
• Node jose version: ^5
• Nimbus JOSE+JWT version: 9.37.x
• HS256 secret is 32 bytes to satisfy strict verifiers: 0123456789abcdef0123456789abcdef

Impact

• Class: Violation of JWS crit “must‑understand” semantics; specification non‑compliance leading to authentication/authorization policy bypass.
• Who is impacted: Any service that relies on crit to carry mandatory security semantics (e.g., token binding via cnf) or operates in a heterogeneous fleet with strict verifiers elsewhere.
• Consequences: Split‑brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored.

References

• RFC 7515: JSON Web Signature (JWS), §4.1.11 crit
• RFC 7800: Proof‑of‑Possession Key Semantics for JWTs (cnf)

CVE-2025-61920

Summary
Authlib’s JOSE implementation accepts unbounded JWS/JWT header and signature segments. A remote attacker can craft a token whose base64url‑encoded header or signature spans hundreds of megabytes. During verification, Authlib decodes and parses the full input before it is rejected, driving CPU and memory consumption to hostile levels and enabling denial of service.

Impact

• Attack vector: unauthenticated network attacker submits a malicious JWS/JWT.

• Effect: base64 decode + JSON/crypto processing of huge buffers pegs CPU and allocates large amounts of RAM; a single request can exhaust service capacity.

• Observed behaviour: on a test host, the legacy code verified a 500 MB header, consuming ~4 GB RSS and ~9 s CPU before failing.

• Severity: High. CVSS v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5).

Affected Versions
Authlib ≤ 1.6.3 (and earlier) when verifying JWS/JWT tokens. Later snapshots with 256 KB header/signature limits are not affected.

Proof of concept

Local demo (do not run against third-party systems):
Download jws_segment_dos_demo.py the PoC in direcotry authlib/
Run following Command

python3 jws_segment_dos_demo.py --variant both --sizes "500MB" --fork-per-case

Environment: Python 3.13.6, Authlib 1.6.4, Linux x86_64, CPUs=8
Sample output: Refined

The compilation script prints separate “[ATTACKER]” (token construction) and “[SERVER]” (Authlib verification) RSS deltas so defenders can distinguish client-side preparation from server-side amplification. Regression tests authlib/tests/dos/test_jose_dos.py further capture the issue; the saved original_util.py/original_jws.py reproductions still accept the malicious payload.

Remediation

• Apply the upstream patch that introduces decoded size limits:

• MAX_HEADER_SEGMENT_BYTES = 256 KB

• MAX_SIGNATURE_SEGMENT_BYTES = 256 KB

• Enforce Limits in authlib/jose/util.extract_segment and _extract_signature.

• Deploy the patched release immediately.

• For additional defence in depth, reject JWS/JWT inputs above a few kilobytes at the proxy or WAF layer, and rate-limit verification endpoints.

Workarounds (temporary)

• Enforce input size limits before handing tokens to Authlib.

• Use application-level throttling to reduce amplification risk.

Resources

• Demo script: jws_segment_dos_demo.py

• Tests: authlib/tests/dos/test_jose_dos.py

• OWASP JWT Cheat Sheet (DoS guidance)

CVE-2025-62706

Summary

Authlib’s JWE zip=DEF path performs unbounded DEFLATE decompression. A very small ciphertext can expand into tens or hundreds of megabytes on decrypt, allowing an attacker who can supply decryptable tokens to exhaust memory and CPU and cause denial of service.

Details

• Affected component: Authlib JOSE, JWE zip=DEF (DEFLATE) support.
• In authlib/authlib/jose/rfc7518/jwe_zips.py, DeflateZipAlgorithm.decompress calls zlib.decompress(s, -zlib.MAX_WBITS) without a maximum output limit. This permits unbounded expansion of compressed payloads.
• In the JWE decode flow (authlib/authlib/jose/rfc7516/jwe.py), when the protected header contains "zip": "DEF", the library routes the decrypted ciphertext into the decompress method and assigns the fully decompressed bytes to the plaintext field before returning it. No streaming limit or quota is applied.
• Because DEFLATE achieves extremely high ratios on highly repetitive input, an attacker can craft a tiny zip=DEF ciphertext that inflates to a very large plaintext during decrypt, spiking RSS and CPU. Repeated requests can starve the process or host.

Code references (from this repository version):

• authlib/authlib/jose/rfc7518/jwe_zips.py – DeflateZipAlgorithm.decompress uses unbounded zlib.decompress.
• authlib/authlib/jose/rfc7516/jwe.py – JWE decode path applies zip_.decompress(msg) when zip=DEF is present in the header.

Contrast: The joserfc project guards zip=DEF decompression with a fixed maximum (256 KB) and raises ExceededSizeError if output would exceed this limit, preventing the bomb. Authlib lacks such a guard in this codebase snapshot.

PoC

Environment: Python 3.10+ inside a venv; Authlib installed editable from this repository so source changes are visible. The PoC script demonstrates both a benign and a compressible-bomb payload and prints wall/CPU time, RSS, and size ratios.

1. Create venv and install Authlib (editable):
   Set current directory to /authlib
   Download jwe_deflate_dos_demo.py in /authlib

python3 -m venv .venv
.venv/bin/pip install --upgrade pip
.venv/bin/pip install -e .

2. Run the PoC (included in this repo):

.venv/bin/python /authlib/jwe_deflate_dos_demo.py --size 50 --max-rss-mb 2048

Sample output (abridged):

LOCAL TEST ONLY – do not send to third-party systems.
Runtime: Python 3.13.6 / Authlib 1.6.4 / zip=DEF via A256GCM
[CASE] normal    plaintext=13B  ciphertext=117B decompressed=13B  wall_s=0.000 cpu_s=0.000 peak_rss_mb=31.0  ratio=0.1
[CASE] malicious plaintext=50MB ciphertext=~4KB decompressed=50MB wall_s=~2.3  cpu_s=~2.2  peak_rss_mb=800+  ratio=12500+

The second case shows the decompression spike: a few KB of ciphertext forces allocation and processing of ~50 MB during decrypt. Repeated requests can quickly exhaust available memory and CPU.

Reproduction notes:

• Algorithm: alg=dir, enc=A256GCM, header includes { "zip": "DEF" }.
• The PoC uses a 32‑byte local symmetric key and a highly compressible payload ("A" * N).
• Increase --size to stress memory; the --max-rss-mb flag helps avoid destabilizing the host during testing.

Impact

• Effect: Denial of service (memory/CPU exhaustion) during JWE decrypt of zip=DEF tokens.
• Who is impacted: Any service that uses Authlib to decrypt JWE tokens with zip=DEF and where an attacker can submit tokens that will be successfully decrypted (e.g., shared dir key, token reflection, or compromised/abused issuers).
• Confidentiality/Integrity: No direct C/I impact; availability impact is high.

Severity (CVSS v3.1)

Base vector (typical shared‑secret scenario where the attacker must produce a decryptable token):

• CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H → 6.5 (MEDIUM)

Rationale:

• Network‑reachable (AV:N), low complexity (AC:L), no user interaction (UI:N), scope unchanged (S:U).
• Attacker must hold or gain ability to mint a decryptable token for the target (PR:L) — common with alg=dir and shared keys across services.
• No confidentiality or integrity loss (C:N/I:N); availability is severely impacted (A:H) due to decompression expansion.
  If arbitrary unprivileged parties can submit JWEs that will be decrypted (PR:N), the base vector becomes:
• CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H → 7.5 (HIGH)

Mitigations / Workarounds

• Reject or strip zip=DEF for inbound JWEs at the application boundary until a fix is available.
• Fork and add a bounded decompression guard (e.g., zlib.decompress(..., max_length) via decompressobj().decompress(data, MAX_SIZE)), returning an error when output exceeds a safe limit.
• Enforce strict maximum token sizes and fail fast on oversized inputs; combine with rate limiting.

Remediation Guidance (for maintainers)

• Mirror joserfc’s approach: add a conservative maximum output size (e.g., 256 KB by default) and raise a specific error when exceeded; document a controlled way to raise this ceiling for trusted environments.
• Consider streaming decode with chunked limits to avoid large single allocations.

References

• Authlib source: authlib/authlib/jose/rfc7518/jwe_zips.py, authlib/authlib/jose/rfc7516/jwe.py

CVE-2024-1681

corydolphin/flask-cors is vulnerable to log injection when the log level is set to debug. An attacker can inject fake log entries into the log file by sending a specially crafted GET request containing a CRLF sequence in the request path. This vulnerability allows attackers to corrupt log files, potentially covering tracks of other attacks, confusing log post-processing tools, and forging log entries. The issue is due to improper output neutralization for logs.

CVE-2024-6844

A vulnerability in corydolphin/flask-cors version 5.0.1 allows for inconsistent CORS matching due to the handling of the '+' character in URL paths. The request.path is passed through the unquote_plus function, which converts the '+' character to a space ' '. This behavior leads to incorrect path normalization, causing potential mismatches in CORS configuration. As a result, endpoints may not be matched correctly to their CORS settings, leading to unexpected CORS policy application. This can cause unauthorized cross-origin access or block valid requests, creating security vulnerabilities and usability issues.

CVE-2024-6866

corydolphin/flask-cors version 5.0.1 contains a vulnerability where the request path matching is case-insensitive due to the use of the try_match function, which is originally intended for matching hosts. This results in a mismatch because paths in URLs are case-sensitive, but the regex matching treats them as case-insensitive. This misconfiguration can lead to significant security vulnerabilities, allowing unauthorized origins to access paths meant to be restricted, resulting in data exposure and potential data leaks.

CVE-2024-6839

corydolphin/flask-cors version 5.0.1 contains an improper regex path matching vulnerability. The plugin prioritizes longer regex patterns over more specific ones when matching paths, which can lead to less restrictive CORS policies being applied to sensitive endpoints. This mismatch in regex pattern priority allows unauthorized cross-origin access to sensitive data or functionality, potentially exposing confidential information and increasing the risk of unauthorized actions by malicious actors.

CVE-2023-46136

Werkzeug multipart data parser needs to find a boundary that may be between consecutive chunks. That's why parsing is based on looking for newline characters. Unfortunately, code looking for partial boundary in the buffer is written inefficiently, so if we upload a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer.

This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.

CVE-2024-49767

Applications using Werkzeug to parse multipart/form-data requests are vulnerable to resource exhaustion. A specially crafted form body can bypass the Request.max_form_memory_size setting.

The Request.max_content_length setting, as well as resource limits provided by deployment software and platforms, are also available to limit the resources used during a request. This vulnerability does not affect those settings. All three types of limits should be considered and set appropriately when deploying an application.

CVE-2024-49766

On Python < 3.11 on Windows, os.path.isabs() does not catch UNC paths like //server/share. Werkzeug's safe_join() relies on this check, and so can produce a path that is not safe, potentially allowing unintended access to data. Applications using Python >= 3.11, or not using Windows, are not vulnerable.

CVE-2025-48068

Summary

A low-severity vulnerability in Next.js has been fixed in version 15.2.2. This issue may have allowed limited source code exposure when the dev server was running with the App Router enabled. The vulnerability only affects local development environments and requires the user to visit a malicious webpage while npm run dev is active.

Because the mitigation is potentially a breaking change for some development setups, to opt-in to the fix, you must configure allowedDevOrigins in your next config after upgrading to a patched version. Learn more.

Learn more: https://vercel.com/changelog/cve-2025-48068

Credit

Thanks to sapphi-red and Radman Siddiki for responsibly disclosing this issue.

CVE-2025-57752

A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as Cookie or Authorization), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug.

All users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.

More details at Vercel Changelog

CVE-2025-57822

A vulnerability in Next.js Middleware has been fixed in v14.2.32 and v15.4.7. The issue occurred when request headers were directly passed into NextResponse.next(). In self-hosted applications, this could allow Server-Side Request Forgery (SSRF) if certain sensitive headers from the incoming request were reflected back into the response.

All users implementing custom middleware logic in self-hosted environments are strongly encouraged to upgrade and verify correct usage of the next() function.

More details at Vercel Changelog

CVE-2025-55173

A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. The issue allowed attacker-controlled external image sources to trigger file downloads with arbitrary content and filenames under specific configurations. This behavior could be abused for phishing or malicious file delivery.

All users relying on images.domains or images.remotePatterns are encouraged to upgrade and verify that external image sources are strictly validated.

More details at Vercel Changelog

CVE-2024-35195

When making requests through a Requests Session, if the first request is made with verify=False to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of verify. This behavior will continue for the lifecycle of the connection in the connection pool.

Remediation

Any of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation.

• Upgrade to requests>=2.32.0.
• For requests<2.32.0, avoid setting verify=False for the first request to a host while using a Requests Session.
• For requests<2.32.0, call close() on Session objects to clear existing connections if verify=False is used.

Related Links

• https://github.com/psf/requests/pull/6655

CVE-2024-47081

Impact

Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs.

Workarounds

For older versions of Requests, use of the .netrc file can be disabled with trust_env=False on your Requests Session (docs).

References

https://github.com/psf/requests/pull/6965
https://seclists.org/fulldisclosure/2025/Jun/2

CVE-2023-43804

urllib3 doesn't treat the Cookie HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a Cookie header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.

Users must handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the Cookie header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.

Affected usages

We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:

• Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)
• Using the Cookie header on requests, which is mostly typical for impersonating a browser.
• Not disabling HTTP redirects
• Either not using HTTPS or for the origin server to redirect to a malicious origin.

Remediation

• Upgrading to at least urllib3 v1.26.17 or v2.0.6
• Disabling HTTP redirects using redirects=False when sending requests.
• Not using the Cookie header.

CVE-2023-45803

urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 303 "See Other" after the request had its method changed from one that could accept a request body (like POST) to GET as is required by HTTP RFCs. Although the behavior of removing the request body is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers.

From RFC 9110 Section 9.3.1:

A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.

Affected usages

Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable.

Both of the following conditions must be true to be affected by this vulnerability:

• If you're using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON)
• The origin service is compromised and starts redirecting using 303 to a malicious peer or the redirected-to service becomes compromised.

Remediation

You can remediate this vulnerability with any of the following steps:

• Upgrade to a patched version of urllib3 (v1.26.18 or v2.0.7)
• Disable redirects for services that you aren't expecting to respond with redirects with redirects=False.
• Disable automatic redirects with redirects=False and handle 303 redirects manually by stripping the HTTP request body.

CVE-2024-37891

When using urllib3's proxy support with ProxyManager, the Proxy-Authorization header is only sent to the configured proxy, as expected.

However, when sending HTTP requests without using urllib3's proxy support, it's possible to accidentally configure the Proxy-Authorization header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the Proxy-Authorization HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.

Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the Proxy-Authorization header during cross-origin redirects to avoid the small chance that users are doing this on accident.

Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the Proxy-Authorization header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach.

Affected usages

We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:

• Setting the Proxy-Authorization header without using urllib3's built-in proxy support.
• Not disabling HTTP redirects.
• Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.

Remediation

• Using the Proxy-Authorization header with urllib3's ProxyManager.
• Disabling HTTP redirects using redirects=False when sending requests.
• Not using the Proxy-Authorization header.

CVE-2025-50181

urllib3 handles redirects and retries using the same mechanism, which is controlled by the Retry object. The most common way to disable redirects is at the request level, as follows:

resp = urllib3.request("GET", "https://httpbin.org/redirect/1", redirect=False)
print(resp.status)

# 302

However, it is also possible to disable redirects, for all requests, by instantiating a PoolManager and specifying retries in a way that disable redirects:

import urllib3

http = urllib3.PoolManager(retries=0)  # should raise MaxRetryError on redirect
http = urllib3.PoolManager(retries=urllib3.Retry(redirect=0))  # equivalent to the above
http = urllib3.PoolManager(retries=False)  # should return the first response

resp = http.request("GET", "https://httpbin.org/redirect/1")

However, the retries parameter is currently ignored, which means all the above examples don't disable redirects.

Affected usages

Passing retries on PoolManager instantiation to disable redirects or restrict their number.

By default, requests and botocore users are not affected.

Impact

Redirects are often used to exploit SSRF vulnerabilities. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable.

Remediation

You can remediate this vulnerability with the following steps:

• Upgrade to a patched version of urllib3. If your organization would benefit from the continued support of urllib3 1.x, please contact [email protected] to discuss sponsorship or contribution opportunities.
• Disable redirects at the request() level instead of the PoolManager() level.

---

Release Notes

authlib/authlib (Authlib)

v1.6.5

Compare Source

What's Changed

• Add a request param to RFC7591 generate_client_info and generate_client_secret methods by @​azmeuk in #​825
• feat: support list params in prepare_grant_uri by @​lisongmin in #​827
• chore(deps): bump SonarSource/sonarqube-scan-action from 5 to 6 in /.github/workflows by @​dependabot[bot] in #​828
• fix(jose): add max size for JWE zip=DEF decompression by @​lepture in #​830

New Contributors

• @​lisongmin made their first contribution in #​827
• @​dependabot[bot] made their first contribution in #​828

Full Changelog: authlib/authlib@v1.6.4...v1.6.5

v1.6.4

Compare Source

What's Changed

• fix(jose): prevent public/unprotected header overwriting protected header by @​lepture in #​809
• Fix InsecureTransportError raising by @​azmeuk in #​810
• Add conventional-commits pre-commit hook by @​azmeuk in #​811
• Fix response_mode=form_post with Starlette client by @​azmeuk in #​812
• Specify README.md as project long description by @​EpicWink in #​817
• Migrate tests to pytest paradigm by @​azmeuk in #​813
• jose/jws: Reject unprotected ‘crit’ and enforce type; add tests by @​AL-Cybision in #​823
• Use explicit *.test urls in unit tests by @​azmeuk in #​824

New Contributors

• @​EpicWink made their first contribution in #​817
• @​AL-Cybision made their first contribution in #​823

Full Changelog: authlib/authlib@v1.6.3...v1.6.4

v1.6.3: Version 1.6.3

Compare Source

What's Changed

• Add diff-cover check in GHA by @​azmeuk in #​803
• Run GHA unit tests with uv by @​azmeuk in #​805
• Move from pre-commit to prek by @​azmeuk in #​804
• Sign OIDC id_token according to id_token_signed_response_alg client metadata by @​azmeuk in #​802

Full Changelog: authlib/authlib@v1.6.2...v1.6.3

v1.6.2: Version 1.6.2

Compare Source

What's Changed

• Allow insecure transport for 127.0.0.1 for debugging by @​geigerzaehler in #​788
• Raise a MissingCodeError when code parameter is missing by @​lepture in #​786
• Temporarily restore OAuth2Request body parameter by @​azmeuk in #​791
• Raise MissingCodeException when code parameter is missing by @​lepture in #​794
• Fix id_token generation with EdDSA alg by @​azmeuk in #​800

Full Changelog: authlib/authlib@v1.6.1...v1.6.2

v1.6.1: Version 1.6.1

Compare Source

• Filter key set with additional "alg" and "use" parameters.

v1.6.0: Version 1.6.0

Compare Source

• Fix issue when RFC9207 is enabled and the authorization endpoint response is not a redirection. pull request #​733
• Fix missing state parameter in authorization error responses. issue #​525
• Support for acr and amr claims in id_token. issue #​734
• Support for the none JWS algorithm.
• Fix response_types strict order during dynamic client registration. issue #​760
• Implement RFC9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR). issue #​723
• OIDC UserInfo endpoint support. issue #​459

v1.5.2: Version 1.5.2

Compare Source

Released on Apr 1, 2025

• Forbid fragments in redirect_uris. #​714
• Fix invalid characters in error_description. #​720
• Add claims_cls parameter for client's parse_id_token method. #​725

v1.5.1: Version 1.5.1

Compare Source

Released on Feb 28, 2025

• Fix RFC9207 iss parameter. #​715

v1.5.0: Version 1.5.0

Compare Source

• Fix token introspection auth method for clients. #​662
• Optional typ claim in JWT tokens. #​696
• JWT validation leeway. #​689
• Implement server-side RFC9207. #​700 #​701
• generate_id_token can take a kid parameter. #​702
• More detailed InvalidClientError. #​706
• OpenID Connect Dynamic Client Registration implementation. #​707

v1.4.1: Version 1.4.1

Compare Source

• Improve garbage collection on OAuth clients. #​698
• Fix client parameters for httpx. #​694

v1.4.0: Version 1.4.0

Compare Source

Bugfixes

• Fix id_token decoding when kid is null. #​659
• Support for Python 3.13. #​682
• Force login if the prompt parameter value is login. #​637
• Support for httpx 0.28. #​695

Breaking changes

• Stop support for Python 3.8. #​682

v1.3.2: Version 1.3.2

Compare Source

• Prevent ever-growing session size for OAuth clients.
• Revert quote client id and secret.
• unquote basic auth header for authorization server.

v1.3.1: Version 1.3.1

Compare Source

Prevent OctKey to import ssh and PEM strings.

v1.3.0: Version 1.3.0

Compare Source

Bug fixes

• Restore AuthorizationServer.create_authorization_response behavior, via #​558 by @​TurnrDev
• Include leeway in validate_iat() for JWT, via #​565 by @​dhallam
• Fix encode_client_secret_basic, via #​594 by @​Prilkop
• Use single key in JWK if JWS does not specify kid, via #​596 by @​dklimpel
• Fix error when RFC9068 JWS has no scope field, via #​598 by @​tanguilp
• Get werkzeug version using importlib, via #​591 by @​Sparrow0hawk

Breaking changes

• RFC9068 implementation, via #​586 by @​azmeuk.

v1.2.1: Version 1.2.1

Compare Source

• Apply headers in ClientSecretJWT.sign method, via #​552
• Allow falsy but non-None grant uri params, via #​544
• Fixed authorize_redirect for Starlette v0.26.0, via #​533
• Removed has_client_secret method and documentation, via #​513
• Removed request_invalid and token_revoked remaining occurences
  and documentation. #​514
• Fixed RFC7591 grant_types and response_types default values, via #​509
• Add support for python 3.12, via #​590

v1.2.0: Version 1.2.0

Compare Source

• Not passing request.body to ResourceProtector, #​485.
• Use flask.g instead of _app_ctx_stack, #​482.
• Add headers parameter back to ClientSecretJWT, #​457.
• Always passing realm parameter in OAuth 1 clients, #​339.
• Implemented RFC7592 Dynamic Client Registration Management Protocol, #​505`
• Add default_timeout for requests OAuth2Session and AssertionSession.
• Deprecate jwk.loads and jwk.dumps

v1.1.0: Version 1.1.0

Compare Source

This release contains breaking changes and security fixes.

• Allow to pass claims_options to Framework OpenID Connect clients, via #​446 by @​Galaxy102
• Fix .stream with context for HTTPX OAuth clients, via #​465 by @​bjoernmeier
• Fix Starlette OAuth client for cache store, via #​478 by @​haggen

Breaking changes:

• Raise InvalidGrantError for invalid code, redirect_uri and no user errors in OAuth 2.0 server.
• The default authlib.jose.jwt would only work with JSON Web Signature algorithms, if you would like to use JWT with JWE algorithms, please pass the algorithms parameter:

jwt = JsonWebToken(['A128KW', 'A128GCM', 'DEF'])

Security fixes for JOSE module

• CVE-2022-39175
• CVE-2022-39174

v1.0.1: Version 1.0.1

Compare Source

• Fix authenticate_none method, via #​438.
• Allow to pass in alternative signing algorithm to RFC7523 authentication methods via #​447.
• Fix missing_token for Flask OAuth client, via #​448.
• Allow openid in any place of the scope, via #​449.
• Security fix for validating essential value on blank value in JWT, via #​445.

v1.0.0: Version 1.0.0

Compare Source

We have dropped support for Python 2 in this release. We have removed
built-in SQLAlchemy integration.

OAuth Client Changes:

The whole framework client integrations have been restructured, if you are
using the client properly, e.g. oauth.register(...), it would work as
before.

OAuth Provider Changes:

In Flask OAuth 2.0 provider, we have removed the deprecated
OAUTH2_JWT_XXX configuration, instead, developers should define
.get_jwt_config on OpenID extensions and grant types.

SQLAlchemy integrations has been removed from Authlib. Developers
should define the database by themselves.

JOSE Changes

• JWS has been renamed to JsonWebSignature
• JWE has been renamed to JsonWebEncryption
• JWK has been renamed to JsonWebKey
• JWT has been renamed to JsonWebToken

The "Key" model has been re-designed, checkout the JSON Web Key for updates.

Added ES256K algorithm for JWS and JWT.

Breaking Changes: find how to solve the deprecate issues via https://git.io/JkY4f

v0.15.6

Compare Source

v0.15.5: Version 0.15.5

Compare Source

• Make Authlib compatible with latest httpx
• Make Authlib compatible with latest werkzeug
• Allow customize RFC7523 alg value

v0.15.4: Version 0.15.4

Compare Source

Security fix when JWT claims is None.

For example, JWT payload has iss=None:

{
  "iss": None,
  ...
}

But we need to decode it with claims:

claims_options = {
  'iss': {'essential': True, 'values': ['required']}
}
jwt.decode(token, key, claims_options=claims_options)

It didn't raise an error before this fix.

v0.15.3: Version 0.15.3

Compare Source

Fixed .authorize_access_token for OAuth 1.0 services, via lepture#308

v0.15.2: Version 0.15.2

Compare Source

Fixed httpx authentication bug via #​283

v0.15.1: Version 0.15.1

Compare Source

Backward compitable fix for using JWKs in JWT, via #​280.

v0.15: Version 0.15

Compare Source

This is the last release before v1.0. In this release, we added more RFCs
implementations and did some refactors for JOSE:

• RFC8037: CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)
• RFC7638: JSON Web Key (JWK) Thumbprint

We also fixed bugs for integrations:

• Fixed support for HTTPX>=0.14.3
• Added OAuth clients of HTTPX back via #​270
• Fixed parallel token refreshes for HTTPX async OAuth 2 client
• Raise OAuthError when callback contains errors via #​275

Breaking Change:

1. The parameter algorithms in JsonWebSignature and JsonWebEncryption
   are changed. Usually you don't have to care about it since you won't use it directly.
2. Whole JSON Web Key is refactored, please check JSON Web Key (JWK)

corydolphin/flask-cors (Flask-Cors)

v6.0.0

Compare Source

Breaking

Path specificity ordering has changed to improve specificity. This may break users who expected the previous incorrect ordering.

• [CVE-2024-6839] Sort Paths by Regex Specificity by @​adrianosela in #​391
• [CVE-2024-6844] Replace use of (urllib) unquote_plus with unquote by @​adrianosela in #​389

What's Changed

• [CVE-2024-6866] Case Sensitive Request Path Matching by @​adrianosela in #​390

Full Changelog: corydolphin/flask-cors@5.0.1...6.0.0

v5.0.1

Compare Source

What's Changed

This primarily changes packaging to use uv and a new release pipeline, along with some small documentation improvements

• [Docs] Fix links to documentation by @​coren-frankel in #​369
• Fix minor typos by @​kkirsche in #​371
• Migrate packaging and environment management to use uv by @​corydolphin in #​377
• Fix release pipeline by @​corydolphin in #​378
• Always use trusted publishing by @​corydolphin in #​379
• Workaround license publishing issue by @​corydolphin in #​380
• Fix packaging: missing source files by @​corydolphin in #​381

New Contributors

• @​coren-frankel made their first contribution in #​369
• @​kkirsche made their first contribution in #​371

Full Changelog: corydolphin/flask-cors@5.0.0...5.0.01

v5.0.0

Compare Source

What's Changed

• Breaking: Change default to disable private network access by @​corydolphin in #​368
  This effectively resolves GHSA-hxwh-jpp2-84pm https://osv.dev/vulnerability/PYSEC-2024-71

Full Changelog: corydolphin/flask-cors@4.0.2...5.0.0

v4.0.2

Compare Source

What's Changed

• Bump requests from 2.31.0 to 2.32.0 in /docs by @​dependabot in #​358
• Backwards Compatible Fix for CVE-2024-6221 by @​adrianosela in #​363
• Add unit tests for Private-Network by @​corydolphin in #​367

New Contributors

• @​dependabot made their first contribution in #​358
• @​adrianosela made their first contribution in #​363

Full Changelog: corydolphin/flask-cors@4.0.1...4.0.2

v4.0.1

Compare Source

Security

• Address CVE-2024-1681 which is a log injection vulnerability when the log level is set to debug by [@​aneshujevic](htt

---

Configuration

📅 Schedule: Branch creation - "" in timezone UTC, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Deployment Summary

• backend_url: https://pr-7095-backend.rdev.single-cell.czi.technology
• frontend_url: https://pr-7095-frontend.rdev.single-cell.czi.technology
• delete_db_task_definition_arn: arn:aws:ecs:us-west-2:***:task-definition/dp-rdev-pr-7095-deletion:1
• migrate_db_task_definition_arn: arn:aws:ecs:us-west-2:***:task-definition/dp-rdev-pr-7095-migration:1

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.50%. Comparing base (55b225f) to head (f4a8841).
Report is 1 commits behind head on main.

❗ Current head f4a8841 differs from pull request most recent head 0264ac1

Please upload reports for the commit 0264ac1 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7095      +/-   ##
==========================================
- Coverage   92.75%   92.50%   -0.26%     
==========================================
  Files         192      185       -7     
  Lines       16113    15735     -378     
==========================================
- Hits        14946    14555     -391     
- Misses       1167     1180      +13     

Flag	Coverage Δ
unittests	92.50% <ø> (-0.26%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.