Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update security vulnerabilities [security] #7095

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented May 23, 2024

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
Authlib ==0.14.3 -> ==1.3.1 age adoption passing confidence
Flask-Cors ~=3.0.6 -> ~=4.0.2 age adoption passing confidence
Werkzeug (changelog) ==2.2.3 -> ==3.0.6 age adoption passing confidence
next (source) 14.1.0 -> 14.2.10 age adoption passing confidence
pydantic (changelog) ==1.10.7 -> ==1.10.13 age adoption passing confidence
requests (source, changelog) ==2.31.0 -> ==2.32.2 age adoption passing confidence
urllib3 (changelog) ==1.26.16 -> ==1.26.19 age adoption passing confidence

GitHub Vulnerability Alerts

CVE-2024-37568

lepture Authlib before 1.3.1 has algorithm confusion with asymmetric public keys. Unless an algorithm is specified in a jwt.decode call, HMAC verification is allowed with any asymmetric public key. (This is similar to CVE-2022-29217 and CVE-2024-33663.)

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

A vulnerability in corydolphin/flask-cors version 4.0.1 allows the Access-Control-Allow-Private-Network CORS header to be set to true by default, without any configuration option. This behavior can expose private network resources to unauthorized external access, leading to significant security risks such as data breaches, unauthorized access to sensitive information, and potential network intrusions.

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

The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer's machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer's application that will trigger the debugger.

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

Impact

By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, stale-while-revalidate header which some upstream CDNs may cache as well.

To be potentially affected all of the following must apply:

  • Next.js between 13.5.1 and 14.2.9
  • Using pages router
  • Using non-dynamic server-side rendered routes e.g. pages/dashboard.tsx not pages/blog/[slug].tsx

The below configurations are unaffected:

  • Deployments using only app router
  • Deployments on Vercel are not affected

Patches

This vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.

Workarounds

There are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.

Credits

  • Allam Rachid (zhero_)
  • Henry Chen

CVE-2024-47831

Impact

The image optimization feature of Next.js contained a vulnerability which allowed for a potential Denial of Service (DoS) condition which could lead to excessive CPU consumption.

Not affected:

  • The next.config.js file is configured with images.unoptimized set to true or images.loader set to a non-default value.
  • The Next.js application is hosted on Vercel.

Patches

This issue was fully patched in Next.js 14.2.7. We recommend that users upgrade to at least this version.

Workarounds

Ensure that the next.config.js file has either images.unoptimized, images.loader or images.loaderFile assigned.

Credits

Brandon Dahler (brandondahler), AWS
Dimitrios Vlastaras

CVE-2024-3772

Regular expression denial of service in Pydantic < 2.4.0, < 1.10.13 allows remote attackers to cause denial of service via a crafted email string.

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

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

lepture/authlib (Authlib)

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

Breaking changes

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.

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 https://github.com/lepture/authlib/issues/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)

v4.0.2

Compare Source

What's Changed

New Contributors

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

v4.0.1

Compare Source

Security

v4.0.0

Compare Source

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

vercel/next.js (next)

v14.2.10

Compare Source

v14.2.9

Compare Source

v14.2.8

Compare Source

v14.2.7

Compare Source

v14.2.6

Compare Source

v14.2.5

Compare Source

v14.2.4

Compare Source

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

Core Changes
  • fix: ensure route handlers properly track dynamic access (#​66446)
  • fix NextRequest proxy in edge runtime (#​66551)
  • Fix next/dynamic with babel and src dir (#​65177)
  • Use vercel deployment url for metadataBase fallbacks (#​65089)
  • fix(next/image): detect react@19 for fetchPriority prop (#​65235)
  • Fix loading navigation with metadata and prefetch (#​66447)
  • prevent duplicate RSC fetch when action redirects (#​66620)
  • ensure router cache updates reference the latest cache values (#​66681)
  • Prevent append of trailing slash in cases where path ends with a file extension (#​66636)
  • Fix inconsistency with 404 getStaticProps cache-control (#​66674)
  • Use addDependency to track metadata route file changes (#​66714)
  • Add timeout/retry handling for fetch cache (#​66652)
  • fix: app-router prefetch crash when an invalid URL is passed to Link (#​66755)
Credits

Huge thanks to @​ztanner, @​ijjk, @​wbinnssmith, @​huozhi, and @​lubieowoce for helping!

v14.2.3

Compare Source

v14.2.2

Compare Source

v14.2.1

Compare Source

v14.2.0

Compare Source

v14.1.4

Compare Source

v14.1.3

Compare Source

v14.1.2

Compare Source

v14.1.1

Compare Source

Note: this is a backport release for critical bug fixes -- this does not include all pending features/changes on canary

Core Changes
Credits

Huge thanks to @​huozhi, @​shuding, @​Ethan-Arrowood, @​styfle, @​ijjk, @​ztanner, @​balazsorban44, @​kdy1, and @​williamli for helping!

pydantic/pydantic (pydantic)

v1.10.13

Compare Source

v1.10.12

Compare Source

  • Fixes the maxlen property being dropped on deque validation. Happened only if the deque item has been typed. Changes the _validate_sequence_like func, #​6581 by @​maciekglowka

v1.10.11

Compare Source

  • Importing create_model in tools.py through relative path instead of absolute path - so that it doesn't import V2 code when copied over to V2 branch, #​6361 by @​SharathHuddar

v1.10.10

Compare Source

v1.10.9

Compare Source

v1.10.8

Compare Source

psf/requests (requests)

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.

Copy link
Contributor

Deployment Summary

Copy link

codecov bot commented May 23, 2024

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.

@renovate renovate bot force-pushed the renovate/security-vulnerabilities branch 16 times, most recently from f570059 to 70b1637 Compare May 31, 2024 17:00
@renovate renovate bot force-pushed the renovate/security-vulnerabilities branch 10 times, most recently from ff5887d to 17ef04f Compare June 7, 2024 22:40
@renovate renovate bot force-pushed the renovate/security-vulnerabilities branch 9 times, most recently from 1e0417c to 547c999 Compare October 21, 2024 19:15
@renovate renovate bot force-pushed the renovate/security-vulnerabilities branch 11 times, most recently from 22b6fda to 29d1632 Compare October 31, 2024 02:36
@renovate renovate bot force-pushed the renovate/security-vulnerabilities branch 8 times, most recently from c288950 to c8a0375 Compare November 5, 2024 20:13
@renovate renovate bot force-pushed the renovate/security-vulnerabilities branch from c8a0375 to 5d72c12 Compare November 5, 2024 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant