chore(deps): update security vulnerabilities [security] #7095
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
==0.14.3
->==1.3.1
~=3.0.6
->~=4.0.2
==2.2.3
->==3.0.6
14.1.0
->14.2.10
==1.10.7
->==1.10.13
==2.31.0
->==2.32.2
==1.26.16
->==1.26.19
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 theRequest.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'ssafe_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:
pages/dashboard.tsx
notpages/blog/[slug].tsx
The below configurations are unaffected:
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
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:
next.config.js
file is configured withimages.unoptimized
set totrue
orimages.loader
set to a non-default value.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 eitherimages.unoptimized
,images.loader
orimages.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 withverify=False
to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value ofverify
. 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.
requests>=2.32.0
.requests<2.32.0
, avoid settingverify=False
for the first request to a host while using a Requests Session.requests<2.32.0
, callclose()
onSession
objects to clear existing connections ifverify=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 aCookie
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:
Cookie
header on requests, which is mostly typical for impersonating a browser.Remediation
redirects=False
when sending requests.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
) toGET
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:
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:
Remediation
You can remediate this vulnerability with any of the following steps:
redirects=False
.redirects=False
and handle 303 redirects manually by stripping the HTTP request body.CVE-2024-37891
When using urllib3's proxy support with
ProxyManager
, theProxy-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 theProxy-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:
Proxy-Authorization
header without using urllib3's built-in proxy support.Remediation
Proxy-Authorization
header with urllib3'sProxyManager
.redirects=False
when sending requests.Proxy-Authorization
header.Release Notes
lepture/authlib (Authlib)
v1.3.1
: Version 1.3.1Compare Source
Prevent
OctKey
to import ssh and PEM strings.v1.3.0
: Version 1.3.0Compare Source
Bug fixes
Breaking changes
v1.2.1
: Version 1.2.1Compare Source
ClientSecretJWT.sign
method, via #552authorize_redirect
for Starlette v0.26.0, via #533has_client_secret
method and documentation, via #513request_invalid
andtoken_revoked
remaining occurencesand documentation. #514
grant_types
andresponse_types
default values, via #509v1.2.0
: Version 1.2.0Compare Source
request.body
toResourceProtector
, #485.flask.g
instead of_app_ctx_stack
, #482.headers
parameter back toClientSecretJWT
, #457.realm
parameter in OAuth 1 clients, #339.default_timeout
for requestsOAuth2Session
andAssertionSession
.jwk.loads
andjwk.dumps
v1.1.0
: Version 1.1.0Compare Source
This release contains breaking changes and security fixes.
claims_options
to Framework OpenID Connect clients, via #446 by @Galaxy102.stream
with context for HTTPX OAuth clients, via #465 by @bjoernmeierBreaking changes:
InvalidGrantError
for invalid code, redirect_uri and no user errors in OAuth 2.0 server.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:Security fixes for JOSE module
v1.0.1
: Version 1.0.1Compare Source
authenticate_none
method, via #438.missing_token
for Flask OAuth client, via #448.openid
in any place of the scope, via #449.v1.0.0
: Version 1.0.0Compare 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 asbefore.
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 toJsonWebSignature
JWE
has been renamed toJsonWebEncryption
JWK
has been renamed toJsonWebKey
JWT
has been renamed toJsonWebToken
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.5Compare Source
alg
valuev0.15.4
: Version 0.15.4Compare Source
Security fix when JWT claims is None.
For example, JWT payload has
iss=None
:But we need to decode it with claims:
It didn't raise an error before this fix.
v0.15.3
: Version 0.15.3Compare Source
Fixed
.authorize_access_token
for OAuth 1.0 services, via https://github.com/lepture/authlib/issues/308v0.15.2
: Version 0.15.2Compare Source
Fixed httpx authentication bug via #283
v0.15.1
: Version 0.15.1Compare Source
Backward compitable fix for using JWKs in JWT, via #280.
v0.15
: Version 0.15Compare Source
This is the last release before v1.0. In this release, we added more RFCs
implementations and did some refactors for JOSE:
We also fixed bugs for integrations:
Breaking Change:
algorithms
inJsonWebSignature
andJsonWebEncryption
are changed. Usually you don't have to care about it since you won't use it directly.
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
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
Core Changes
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
pydantic.validate_email
, #7673 by @hramezaniv1.10.12
Compare Source
maxlen
property being dropped ondeque
validation. Happened only if the deque item has been typed. Changes the_validate_sequence_like
func, #6581 by @maciekglowkav1.10.11
Compare Source
v1.10.10
Compare Source
Json
field support to settings management, #6250 by @hramezaniv1.10.9
Compare Source
v1.10.8
Compare Source
Literal
usage withtyping-extension==4.6.0
, #5826 by @hramezaniAnyClassMethod
for changes in python/typeshed#9771, #5505 by @ITProKylepsf/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
toa new public API,
get_connection_with_tls_context
. Existing customHTTPAdapters 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
v2.32.0
Compare Source
Security
verify=False
on the first request from aSession 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 improverequest 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)
(
chardet
orcharset_normalizer
) when repackaged or vendored.This enables
pip
and other projects to minimize their vendoringsurface area. The
Response.text()
andapparent_encoding
APIswill default to
utf-8
if neither library is present. (#6702)Bugfixes
calculated in the request content-length. (#6589)
/
(path separator) could leadurllib3 to unnecessarily reparse the request URI. (#6644)
Deprecations
Documentation
Packaging
The source files for the projects (formerly
requests
) is now locatedin
src/requests
in the Requests sdist. (#6506)using
hatchling
. This should not impact the average user, but extremely oldversions of packaging utilities may have issues with the new packaging format.
urllib3/urllib3 (urllib3)
v1.26.19
Compare Source
====================
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 viaRetry.remove_headers_on_redirect
.#​3405 <https://github.com/urllib3/urllib3/issues/3405>
__)v1.26.18
Compare Source
====================
v1.26.17
Compare Source
====================
Cookie
header to the list of headers to strip from requests when redirecting to a different host. As before, different headers can be set viaRetry.remove_headers_on_redirect
. (#​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.
This PR was generated by Mend Renovate. View the repository job log.