| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Werkzeug is a comprehensive WSGI web application library. 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. This vulnerability is fixed in 3.0.3.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2024-34069
Upstream-patches:
https://github.com/pallets/werkzeug/commit/71b69dfb7df3d912e66bab87fbb1f21f83504967
https://github.com/pallets/werkzeug/commit/890b6b62634fa61224222aee31081c61b054ff01
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Werkzeug is a comprehensive WSGI web application library. Browsers may allow
"nameless" cookies that look like `=value` instead of `key=value`. A vulnerable
browser may allow a compromised application on an adjacent subdomain to exploit
this to set a cookie like `=__Host-test=bad` for another subdomain. Werkzeug
prior to 2.2.3 will parse the cookie `=__Host-test=bad` as __Host-test=bad`.
If a Werkzeug application is running next to a vulnerable or malicious subdomain
which sets such a cookie using a vulnerable browser, the Werkzeug application
will see the bad cookie value but the valid cookie key. The issue is fixed in
Werkzeug 2.2.3.
Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Werkzeug is a comprehensive WSGI web application library. Prior to
version 2.2.3, Werkzeug's multipart form data parser will parse an
unlimited number of parts, including file parts. Parts can be a
small amount of bytes, but each requires CPU time to parse and may
use more memory as Python data. If a request can be made to an
endpoint that accesses `request.data`, `request.form`, `request.files`,
or `request.get_data(parse_form_data=False)`, it can cause unexpectedly
high resource usage. 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. Unlimited file parts
can use up memory and file handles. If many concurrent requests are
sent continuously, this can exhaust or kill all available workers.
Version 2.2.3 contains a patch for this issue.
Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
|
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
|
