Ahpaleus

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5 **Description** This issue involves insecure communication between the FRP client and server when Gradio's `share=True` option is used. HTTPS is not enforced on the connection, allowing attackers to intercept and read files uploaded to the Gradio server, as well as modify responses or data sent between the client and server. This impacts users who are sharing Gradio demos publicly over the internet using `share=True` without proper encryption, exposing sensitive data to potential eavesdroppers. **Recommendations** To address this issue, upgrade to `gradio>=5`. As a temporary workaround, avoid using `share=True` in production environments and instead host Gradio applications on servers with HTTPS enabled to ensure secure communication.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5 **Description** This issue 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. **Recommendations** Upgrade to gradio>=5 to address this issue. As a temporary workaround, 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. 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.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 4.44 **Description** This issue is related to CORS origin validation, where the Gradio server fails to validate the request origin when a cookie is present. This allows an attacker’s website to make unauthorized requests to a local Gradio server. Potentially, attackers can upload files, steal authentication tokens, and access user data if the victim visits a malicious website while logged into Gradio. This impacts users who have deployed Gradio locally and use basic authentication. **Recommendations** To address this issue, users are advised to upgrade to gradio>=4.44. As a temporary workaround, users can manually enforce stricter CORS origin validation by modifying the CustomCORSMiddleware class in their local Gradio server code, specifically bypassing the condition that skips CORS validation for requests containing cookies to prevent potential exploitation.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5.0 **Description** This issue relates to the bypass of directory traversal checks within the `is in or equal` function. The 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. **Recommendations** To address this issue, upgrade to `gradio>=5.0`. As a temporary 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 to mitigate the bypass vulnerabilities caused by the improper handling of `..` sequences or malformed paths.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5.0 **Description** This issue 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, allowing attackers to make unauthorized requests from sandboxed iframes or other sources with a null origin. This could lead to data theft, such as user authentication tokens or uploaded files, especially impacting users running Gradio locally who use basic authentication. **Recommendations** To address this issue, upgrade to `gradio>=5.0`. As a temporary workaround, manually modify the `localhost aliases` list in the local Gradio deployment to exclude "null" as a valid origin, mitigating the potential for exploitation.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 4.44 **Description** This issue 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. **Recommendations** To address this issue, upgrade to gradio>=4.44. As a temporary workaround, developers can sanitize the file paths and ensure that components are not stored in publicly accessible directories.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5 **Description** This issue 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. 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. **Recommendations** To address this issue, upgrade to `gradio>=5`. As a temporary workaround, consider disabling or heavily restricting URL-based inputs in Gradio applications to trusted domains only. Additionally, implementing stricter URL validation (such as allowlist-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.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 4.44 **Description** This issue involves data exposure due to the `enable monitoring` flag not properly disabling monitoring when set to False. Even when monitoring is supposedly disabled, an attacker or unauthorized user can still access the monitoring dashboard by directly requesting the "/monitoring" endpoint. This means that sensitive application analytics may still be exposed, particularly in environments where monitoring is expected to be disabled. Users who set `enable monitoring=False` to prevent unauthorized access to monitoring data are impacted. **Recommendations** To address this issue, upgrade to gradio>=4.44. As a temporary workaround, consider restricting access to the "/monitoring" endpoint until the issue is resolved. There are no known workarounds for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5.0 **Description** This issue is related to a lack of integrity check on the downloaded FRP client, which could potentially allow attackers to introduce malicious code. If an attacker gains access to the remote URL from which the FRP client is downloaded, they could modify the binary without detection, as the Gradio server does not verify the file's checksum or signature. Any users utilizing the Gradio server's sharing mechanism that downloads the FRP client could be affected by this issue, especially those relying on the executable binary for secure data tunneling. **Recommendations** To resolve the issue, upgrade to `gradio>=5.0`, which includes a fix to verify the integrity of the downloaded binary. As a temporary workaround, users can manually validate the integrity of the downloaded FRP client by implementing checksum or signature verification in their own environment to ensure the binary hasn't been tampered with.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5.0 **Description** This issue 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 could lead to sensitive files being exposed to unauthorized users, especially when combined with other vulnerabilities. The components most at risk are those that return or handle file data, including String to FileData, Complex data to FileData, Direct file read in preprocess, and Dictionary converted to FileData components. Exploit scenarios include bypassing allowed inputs to download sensitive files or crafting malicious payloads to leak sensitive files from a server. **Recommendations** For Gradio versions prior to 5.0, upgrade to the latest version to mitigate this vulnerability. There are no known workarounds for this vulnerability. As a temporary workaround, consider restricting access to vulnerable components, such as DownloadButton, Audio, ImageEditor, Video, Model3D, File, UploadButton, Chatbot, MultimodalTextbox, Code, ParamViewer, and Dataset, until a patch is available. Avoid using these components to handle or return file data until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 4.44 **Description** This issue involves a timing attack in the way Gradio compares hashes for the `analytics dashboard` function. Since the comparison is not done in constant time, an attacker could exploit this by measuring the response time of different requests to infer the correct hash byte-by-byte. This can lead to unauthorized access to the analytics dashboard, especially if the attacker can repeatedly query the system with different keys. **Recommendations** To mitigate this issue, upgrade to Gradio version 4.44 or later. As a temporary workaround, developers can manually patch the `analytics dashboard` dashboard to use a constant-time comparison function for comparing sensitive values, such as hashes. Alternatively, access to the analytics dashboard can be disabled to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Gradio versions prior to 5 **Description** This issue involves a race condition in the `update root in config` function, allowing an attacker to modify the `root` URL used by the Gradio frontend to communicate with the backend. By exploiting this flaw, an attacker can redirect user traffic to a malicious server, potentially intercepting sensitive data such as authentication credentials or uploaded files. This impacts all users who connect to a Gradio server, especially those exposed to the internet. **Recommendations** To address this issue, upgrade to `gradio>=5`. There are no known workarounds for this issue. As a temporary workaround, consider restricting access to the `update root in config` function until a patch is applied.

**Name of the Vulnerable Software and Affected Versions** Tornado versions prior to 6.4.1 **Description** The `curl httpclient.CurlAsyncHTTPClient` class fails to reject carriage return (r) and line feed ( ) characters in request headers. This allows attackers to inject CRLF sequences into header values, enabling the injection of arbitrary headers or the construction of entirely new HTTP requests. This issue occurs because the client does not validate header names and values, passing them verbatim to libcurl and pycurl, which also lack validation for the `HTTPHEADER` option. This behavior may facilitate the exploitation of server-side request forgery (SSRF) vulnerabilities. **Recommendations** Update Tornado to version 6.4.1 or later. As a temporary workaround, restrict the use of the `curl httpclient.CurlAsyncHTTPClient` class when handling untrusted header data.

**Name of the Vulnerable Software and Affected Versions** caddy-security plugin for Caddy version 1.1.20 **Description** The issue allows reflected Cross-site Scripting (XSS) via a GET request to a URL that contains an XSS payload and begins with either a "/admin" or "/settings/mfa/delete/" substring. This can be exploited by sending a malicious GET request to the vulnerable URL. **Recommendations** For version 1.1.20, consider disabling access to the "/admin" and "/settings/mfa/delete/" API endpoints until a patch is available. Restrict the use of the caddy-security plugin to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** silverstripe-advancedreports versions 1.0 through 2.0 **Description** The issue allows for Cross-Site Scripting (XSS) due to the possibility of injecting and storing malicious JavaScript code. This affects the "report preview" when an SVG document is provided in the `Description` parameter, specifically at the "admin/advanced-reports/DataObjectReport/EditForm/field/DataObjectReport/item" endpoint. **Recommendations** For versions 1.0 through 2.0, consider disabling the report preview feature in the admin/advanced-reports/DataObjectReport/EditForm/field/DataObjectReport/item endpoint until a patch is available. Restrict access to the Description parameter to minimize the risk of exploitation. Avoid using the `Description` parameter in the affected endpoint until the issue is resolved.