Express ressource injection
A vulnerability has been identified in the Express response.links function, allowing for arbitrary resource injection in the Link header when unsanitized data is used.
The issue arises from improper sanitization in Link header values, which can allow a combination of characters like ,, ;, and <> to preload malicious resources.
This vulnerability is especially relevant for dynamic parameters.
Possible ReDoS vulnerability in HTTP Token authentication in Action Controller
There is a possible ReDoS vulnerability in Action Controller's HTTP Token authentication. This vulnerability has been assigned the CVE identifier CVE-2024-47887.
Impact
------
For applications using HTTP Token authentication via authenticate_or_request_with_http_token or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.
Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.
Releases
--------
The fixed releases are available at the normal locations.
Workarounds
-----------
Users on Ruby 3.2 are unaffected by this issue.
Credits
-------
Thanks to scyoon for reporting
Possible ReDoS vulnerability in query parameter filtering in Action Dispatch
There is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2024-41128.
Impact
------
Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.
Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.
Releases
--------
The fixed releases are available at the normal locations.
Workarounds
-----------
Users on Ruby 3.2 are unaffected by this issue.
Credits
-------
Thanks to scyoon for the report and patches!
Gradio has an XSS on every Gradio server via upload of HTML files, JS files, or SVG files
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability involves Cross-Site Scripting (XSS) on any Gradio server that allows file uploads. Authenticated users can upload files such as HTML, JavaScript, or SVG files containing malicious scripts. When other users download or view these files, the scripts will execute in their browser, allowing attackers to perform unauthorized actions or steal sensitive information from their sessions. This impacts any Gradio server that allows file uploads, particularly those using components that process or display user-uploaded files.
Patches
Yes, please upgrade to gradio>=5 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can restrict the types of files that can be uploaded to the Gradio server by limiting uploads to non-executable file types such as images or text. Additionally, developers can implement server-side validation to sanitize uploaded files, ensuring that HTML, JavaScript, and SVG files are properly handled or rejected before being stored or displayed to users.
Gradio has several components with post-process steps allow arbitrary file leaks
Impact
What kind of vulnerability is it? Who is impacted?
This is a data validation vulnerability affecting several Gradio components, which allows arbitrary file leaks through the post-processing step. Attackers can exploit these components by crafting requests that bypass expected input constraints. This issue could lead to sensitive files being exposed to unauthorized users, especially when combined with other vulnerabilities, such as issue TOB-GRADIO-15. The components most at risk are those that return or handle file data.
Vulnerable Components:
1. String to FileData: DownloadButton, Audio, ImageEditor, Video, Model3D, File, UploadButton.
2. Complex data to FileData: Chatbot, MultimodalTextbox.
3. Direct file read in preprocess: Code.
4. Dictionary converted to FileData: ParamViewer, Dataset.
Exploit Scenarios:
1. A developer creates a Dropdown list that passes values to a DownloadButton. An attacker bypasses the allowed inputs, sends an arbitrary file path (like /etc/passwd), and downloads sensitive files.
2. An attacker crafts a malicious payload in a ParamViewer component, leaking sensitive files from a server through the arbitrary file leak.
Patches
Yes, the issue has been resolved in gradio>5.0. Upgrading to the latest version will mitigate this vulnerability.
Gradio vulnerable to SSRF in the path parameter of /queue/join
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability relates to Server-Side Request Forgery (SSRF) in the /queue/join endpoint. Gradio’s async_save_url_to_cache function allows attackers to force the Gradio server to send HTTP requests to user-controlled URLs. This could enable attackers to target internal servers or services within a local network and possibly exfiltrate data or cause unwanted internal requests. Additionally, the content from these URLs is stored locally, making it easier for attackers to upload potentially malicious files to the server. This impacts users deploying Gradio servers that use components like the Video component which involve URL fetching.
Patches
Yes, please upgrade to gradio>=5 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can disable or heavily restrict URL-based inputs in their Gradio applications to trusted domains only. Additionally, implementing stricter URL validation (such as allowinglist-based validation) and ensuring that local or internal network addresses cannot be requested via the /queue/join endpoint can help mitigate the risk of SSRF attacks.
Gradio has a one-level read path traversal in `/custom_component`
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability involves a one-level read path traversal in the /custom_component endpoint. Attackers can exploit this flaw to access and leak source code from custom Gradio components by manipulating the file path in the request. Although the traversal is limited to a single directory level, it could expose proprietary or sensitive code that developers intended to keep private. This impacts users who have developed custom Gradio components and are hosting them on publicly accessible servers.
Patches
Yes, please upgrade to gradio>=4.44 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, developers can sanitize the file paths and ensure that components are not stored in publicly accessible directories.
Gradio's CORS origin validation accepts the null origin
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability relates to CORS origin validation accepting a null origin. When a Gradio server is deployed locally, the localhost_aliases variable includes "null" as a valid origin. This allows attackers to make unauthorized requests from sandboxed iframes or other sources with a null origin, potentially leading to data theft, such as user authentication tokens or uploaded files. This impacts users running Gradio locally, especially those using basic authentication.
Patches
Yes, please upgrade to gradio>=5.0 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can manually modify the localhost_aliases list in their local Gradio deployment to exclude "null" as a valid origin. By removing this value, the Gradio server will no longer accept requests from sandboxed iframes or sources with a null origin, mitigating the potential for exploitation.
OWASP A01OWASP A05LLM06 · Sensitive Info DisclosureOWASP LLM
Get guardrail →Gradio's `is_in_or_equal` function may be bypassed
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability relates to the bypass of directory traversal checks within the is_in_or_equal function. This function, intended to check if a file resides within a given directory, can be bypassed with certain payloads that manipulate file paths using .. (parent directory) sequences. Attackers could potentially access restricted files if they are able to exploit this flaw, although the difficulty is high. This primarily impacts users relying on Gradio’s blocklist or directory access validation, particularly when handling file uploads.
Patches
Yes, please upgrade to gradio>=5.0 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can manually sanitize and normalize file paths in their Gradio deployment before passing them to the is_in_or_equal function. Ensuring that all file paths are properly resolved and absolute can help mitigate the bypass vulnerabilities caused by the improper handling of .. sequences or malformed paths.
Django allows enumeration of user e-mail addresses
An issue was discovered in Django v5.1.1, v5.0.9, and v4.2.16. The django.contrib.auth.forms.PasswordResetForm class, when used in a view implementing password reset flows, allows remote attackers to enumerate user e-mail addresses by sending password reset requests and observing the outcome (only when e-mail sending is consistently failing).
Django urlize() XSS
django.utils.html.urlize() did not escape certain HTML characters, leading to XSS.
vLLM Denial of Service via the best_of parameter
A vulnerability was found in the ilab model serve component, where improper handling of the best_of parameter in the vllm JSON web API can lead to a Denial of Service (DoS). The API used for LLM-based sentence or chat completion accepts a best_of parameter to return the best completion from several options. When this parameter is set to a large value, the API does not handle timeouts or resource exhaustion properly, allowing an attacker to cause a DoS by consuming excessive system resources. This leads to the API becoming unresponsive, preventing legitimate users from accessing the service.
Django memory consumption vulnerability
An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The floatformat template filter is subject to significant memory consumption when given a string representation of a number in scientific notation with a large exponent.
Django vulnerable to user enumeration attack
An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. The django.contrib.auth.backends.ModelBackend.authenticate() method allows remote attackers to enumerate users via a timing attack involving login requests for users with an unusable password.
Open redirect in gradio
An open redirect vulnerability exists in the gradio-app/gradio, affecting the latest version. The vulnerability allows an attacker to redirect users to arbitrary websites, which can be exploited for phishing attacks, Cross-site Scripting (XSS), Server-Side Request Forgery (SSRF), amongst others. This issue is due to improper validation of user-supplied input in the handling of URLs. Attackers can exploit this vulnerability by crafting a malicious URL that, when processed by the application, redirects the user to an attacker-controlled web page.
Server-Side Request Forgery in langchain-community.retrievers.web_research.WebResearchRetriever
A Server-Side Request Forgery (SSRF) vulnerability exists in the Web Research Retriever component in langchain-community (langchain-community.retrievers.web_research.WebResearchRetriever). The vulnerability arises because the Web Research Retriever does not restrict requests to remote internet addresses, allowing it to reach local addresses. This flaw enables attackers to execute port scans, access local services, and in some scenarios, read instance metadata from cloud environments. The vulnerability is particularly concerning as it can be exploited to abuse the Web Explorer server as a proxy for web attacks on third parties and interact with servers in the local network, including reading their response data. This could potentially lead to arbitrary code execution, depending on the nature of the local services. The vulnerability is limited to GET requests, as POST requests are not possible, but the impact on confidentiality, integrity, and availability is significant due to the potential for stolen credentials and state-changing interactions with internal APIs.
The patched code:
Requires users to opt-in
Suggests using a proxy to prevent requests to local addresses
Denial of service in langchain-community
Denial of service in SitemapLoader Document Loader in the langchain-community package, affecting versions below 0.2.5. The parse_sitemap method, responsible for parsing sitemaps and extracting URLs, lacks a mechanism to prevent infinite recursion when a sitemap URL refers to the current sitemap itself. This oversight allows for the possibility of an infinite loop, leading to a crash by exceeding the maximum recursion depth in Python. This vulnerability can be exploited to occupy server socket/port resources and crash the Python process, impacting the availability of services relying on this functionality.
Missing security headers in Action Pack on non-HTML responses
Permissions-Policy is Only Served on HTML Content-Type
The application configurable Permissions-Policy is only served on responses
with an HTML related Content-Type.
This has been assigned the CVE identifier CVE-2024-28103.
Versions Affected: >= 6.1.0
Not affected: < 6.1.0
Fixed Versions: 6.1.7.8, 7.0.8.4, and 7.1.3.4
Impact
------
Responses with a non-HTML Content-Type are not serving the configured Permissions-Policy. There are certain non-HTML Content-Types that would benefit from having the Permissions-Policy enforced.
Releases
--------
The fixed releases are available at the normal locations.
Workarounds
-----------
N/A
Patches
-------
To aid users who aren't able to upgrade immediately we have provided patches for
the supported release series in accordance with our
maintenance policy
regarding security issues. They are in git-am format and consist of a
single changeset.
6-1-include-permissions-policy-header-on-non-html.patch - Patch for 6.1 series
7-0-include-permissions-policy-header-on-non-html.patch - Patch for 7.0 series
7-1-include-permissions-policy-header-on-non-html.patch - Patch for 7.1 series
Credits
-------
Thank you shinkbr for reporting this!
Gradio applications running locally vulnerable to 3rd party websites accessing routes and uploading files
Impact
This CVE covers the ability of 3rd party websites to access routes and upload files to users running Gradio applications locally. For example, the malicious owners of www.dontvisitme.com could put a script on their website that uploads a large file to http://localhost:7860/upload and anyone who visits their website and has a Gradio app will now have that large file uploaded on their computer
Patches
Yes, the problem has been patched in Gradio version 4.19.2 or higher. We have no knowledge of this exploit being used against users of Gradio applications, but we encourage all users to upgrade to Gradio 4.19.2 or higher.
Fixed in: https://github.com/gradio-app/gradio/commit/84802ee6a4806c25287344dce581f9548a99834a
CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-1727
Gradio's Component Server does not properly consider` _is_server_fn` for functions
Component Server in Gradio before 4.13 does not properly consider _is_server_fn for functions.