fix(deps): update security vulnerabilities [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
Flask-Cors	~=3.0.6 -> ~=6.0.0
Werkzeug (changelog)	==2.2.3 -> ==3.0.6
gunicorn (changelog)	==22.0.0 -> ==23.0.0
gunicorn (changelog)	~=22.0.0 -> ~=23.0.0
next (source)	14.2.26 -> 14.2.30
requests (source, changelog)	==2.31.0 -> ==2.32.4
urllib3 (changelog)	==1.26.16 -> ==1.26.19

GitHub Vulnerability Alerts

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-2024-6827

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

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

---

Release Notes

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 https://github.com/corydolphin/flask-cors/pull/391
• [CVE-2024-6844] Replace use of (urllib) unquote_plus with unquote by @​adrianosela in https://github.com/corydolphin/flask-cors/pull/389

What's Changed

• [CVE-2024-6866] Case Sensitive Request Path Matching by @​adrianosela in https://github.com/corydolphin/flask-cors/pull/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 https://github.com/corydolphin/flask-cors/pull/369
• Fix minor typos by @​kkirsche in https://github.com/corydolphin/flask-cors/pull/371
• Migrate packaging and environment management to use uv by @​corydolphin in https://github.com/corydolphin/flask-cors/pull/377
• Fix release pipeline by @​corydolphin in https://github.com/corydolphin/flask-cors/pull/378
• Always use trusted publishing by @​corydolphin in https://github.com/corydolphin/flask-cors/pull/379
• Workaround license publishing issue by @​corydolphin in https://github.com/corydolphin/flask-cors/pull/380
• Fix packaging: missing source files by @​corydolphin in https://github.com/corydolphin/flask-cors/pull/381

New Contributors

• @​coren-frankel made their first contribution in https://github.com/corydolphin/flask-cors/pull/369
• @​kkirsche made their first contribution in https://github.com/corydolphin/flask-cors/pull/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 https://github.com/corydolphin/flask-cors/pull/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 https://github.com/corydolphin/flask-cors/pull/358
• Backwards Compatible Fix for CVE-2024-6221 by @​adrianosela in https://github.com/corydolphin/flask-cors/pull/363
• Add unit tests for Private-Network by @​corydolphin in https://github.com/corydolphin/flask-cors/pull/367

New Contributors

• @​dependabot made their first contribution in https://github.com/corydolphin/flask-cors/pull/358
• @​adrianosela made their first contribution in https://github.com/corydolphin/flask-cors/pull/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 in https://github.com/corydolphin/flask-cors/pull/351

v4.0.0

Compare Source

• Remove support for Python versions older than 3.8 by @​WAKayser in https://github.com/corydolphin/flask-cors/pull/330
• Add GHA tooling by @​corydolphin in https://github.com/corydolphin/flask-cors/pull/331

v3.0.10

Compare Source

Adds support for PPC64 and ARM64 builds for distribution. Thanks @​sreekanth370

v3.0.9

Compare Source

Security

• Escape path before evaluating resource rules (thanks to Colby Morgan). Prior to this, flask-cors incorrectly
  evaluated CORS resource matching before path expansion. E.g. "/api/../foo.txt" would incorrectly match resources for
  "/api/*" whereas the path actually expands simply to "/foo.txt"

v3.0.8

Compare Source

Fixes : DeprecationWarning: Using or importing the ABCs from 'collections' in Python 3.7.
Thank you @​juanmaneo and @​jdevera for the contribution.

v3.0.7

Compare Source

Updated logging.warn to logging.warning (#​234) Thanks Vaibhav

benoitc/gunicorn (gunicorn)

v23.0.0

Compare Source

Gunicorn 23.0.0 has been released. This version improve HTTP 1.1. support and which improve safety

You're invited to upgrade asap your own installation.

23.0.0 - 2024-08-10

• minor docs fixes (:pr:3217, :pr:3089, :pr:3167)
• worker_class parameter accepts a class (:pr:3079)
• fix deadlock if request terminated during chunked parsing (:pr:2688)
• permit receiving Transfer-Encodings: compress, deflate, gzip (:pr:3261)
• permit Transfer-Encoding headers specifying multiple encodings. note: no parameters, still (:pr:3261)
• sdist generation now explicitly excludes sphinx build folder (:pr:3257)
• decode bytes-typed status (as can be passed by gevent) as utf-8 instead of raising TypeError (:pr:2336)
• raise correct Exception when encounting invalid chunked requests (:pr:3258)
• the SCRIPT_NAME and PATH_INFO headers, when received from allowed forwarders, are no longer restricted for containing an underscore (:pr:3192)
• include IPv6 loopback address [::1] in default for :ref:forwarded-allow-ips and :ref:proxy-allow-ips (:pr:3192)

** NOTE **

• The SCRIPT_NAME change mitigates a regression that appeared first in the 22.0.0 release
• Review your :ref:forwarded-allow-ips setting if you are still not seeing the SCRIPT_NAME transmitted
• Review your :ref:forwarder-headers setting if you are missing headers after upgrading from a version prior to 22.0.0

** Breaking changes **

• refuse requests where the uri field is empty (:pr:3255)
• refuse requests with invalid CR/LR/NUL in heade field values (:pr:3253)
• remove temporary --tolerate-dangerous-framing switch from 22.0 (:pr:3260)
• If any of the breaking changes affect you, be aware that now refused requests can post a security problem, especially so in setups involving request pipe-lining and/or proxies.

Fix CVE-2024-1135

vercel/next.js (next)

v14.2.30

Compare Source

v14.2.29

Compare Source

v14.2.28

Compare Source

v14.2.27

Compare Source

[!NOTE]
This release is backporting bug fixes. It does not include all pending features/changes on canary.

Core Changes

• fix dynamic route interception not working when deployed with middleware (#​64923)

Credits

Huge thanks to @​ztanner for helping!

psf/requests (requests)

v2.32.4

Compare Source

Security

• CVE-2024-47081 Fixed an issue where a maliciously crafted URL and trusted
  environment will retrieve credentials for the wrong hostname/machine from a
  netrc file.

Improvements

• Numerous documentation improvements

Deprecations

• Added support for pypy 3.11 for Linux and macOS.
• Dropped support for pypy 3.9 following its end of support.

v2.32.3

Compare Source

Bugfixes

• Fixed bug breaking the ability to specify custom SSLContexts in sub-classes of
  HTTPAdapter. (#​6716)
• Fixed issue where Requests started failing to run on Python versions compiled
  without the ssl module. (#​6724)

v2.32.2

Compare Source

Deprecations

• To provide a more stable migration for custom HTTPAdapters impacted
  by the CVE changes in 2.32.0, we've renamed _get_connection to
  a new public API, get_connection_with_tls_context. Existing custom
  HTTPAdapters will need to migrate their code to use this new API.
  get_connection is considered deprecated in all versions of Requests>=2.32.0.

  A minimal (2-line) example has been provided in the linked PR to ease
  migration, but we strongly urge users to evaluate if their custom adapter
  is subject to the same issue described in CVE-2024-35195. (#​6710)

v2.32.1

Compare Source

Bugfixes

• Add missing test certs to the sdist distributed on PyPI.

v2.32.0

Compare Source

Security

• Fixed an issue where setting verify=False on the first request from a
  Session will cause subsequent requests to the same origin to also ignore
  cert verification, regardless of the value of verify.
  (GHSA-9wx4-h78v-vm56)

Improvements

• verify=True now reuses a global SSLContext which should improve
  request time variance between first and subsequent requests. It should
  also minimize certificate load time on Windows systems when using a Python
  version built with OpenSSL 3.x. (#​6667)
• Requests now supports optional use of character detection
  (chardet or charset_normalizer) when repackaged or vendored.
  This enables pip and other projects to minimize their vendoring
  surface area. The Response.text() and apparent_encoding APIs
  will default to utf-8 if neither library is present. (#​6702)

Bugfixes

• Fixed bug in length detection where emoji length was incorrectly
  calculated in the request content-length. (#​6589)
• Fixed deserialization bug in JSONDecodeError. (#​6629)
• Fixed bug where an extra leading / (path separator) could lead
  urllib3 to unnecessarily reparse the request URI. (#​6644)

Deprecations

• Requests has officially added support for CPython 3.12 (#​6503)
• Requests has officially added support for PyPy 3.9 and 3.10 (#​6641)
• Requests has officially dropped support for CPython 3.7 (#​6642)
• Requests has officially dropped support for PyPy 3.7 and 3.8 (#​6641)

Documentation

• Various typo fixes and doc improvements.

Packaging

• Requests has started adopting some modern packaging practices.
  The source files for the projects (formerly requests) is now located
  in src/requests in the Requests sdist. (#​6506)
• Starting in Requests 2.33.0, Requests will migrate to a PEP 517 build system
  using hatchling. This should not impact the average user, but extremely old
  versions of packaging utilities may have issues with the new packaging format.

urllib3/urllib3 (urllib3)

v1.26.19

Compare Source

====================

• Added the Proxy-Authorization header to the list of headers to strip from requests when redirecting to a different host. As before, different headers can be set via Retry.remove_headers_on_redirect.
• Fixed handling of OpenSSL 3.2.0 new error message for misconfiguring an HTTP proxy as HTTPS. (#&#8203;3405 <https://github.com/urllib3/urllib3/issues/3405>__)

v1.26.18

Compare Source

====================

• Made body stripped from HTTP requests changing the request method to GET after HTTP 303 "See Other" redirect responses.

v1.26.17

Compare Source

====================

• Added the Cookie header to the list of headers to strip from requests when redirecting to a different host. As before, different headers can be set via Retry.remove_headers_on_redirect. (#&#8203;3139 <https://github.com/urllib3/urllib3/pull/3139>_)

---

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.