ghsa

### Impact A maliciously crafted archive may allow an attacker to create a symlink outside the extraction target directory. ### Patches Please use version 4.0.0 or later `github.com/codeclysm/extract/v4`. Any previous version is affected by the bug. ### Workarounds No knows workarounds. ### Backward compatibility notes about upgrading to `/v4` from `/v3` If you're not using the `extract.Extractor.FS` interface, you will not face any breaking changes and upgrading should be as simple as changing the import to `/v4`. This should be the case for most of the userbase. If you're using the `Extractor.FS` interface, then upgrading to `/v4` will require to implement the new methods that have been added: ```go type FS interface { Link(string, string) error MkdirAll(string, os.FileMode) error OpenFile(name string, flag int, perm os.FileMode) (*os.File, error) Symlink(string, string) error // The following methods have been added in the /v4 interface: Remove(path s...

DOMpurify was vulnerable to nesting-based mXSS fixed by [0ef5e537](https://github.com/cure53/DOMPurify/tree/0ef5e537a514f904b6aa1d7ad9e749e365d7185f) (2.x) and [merge 943](https://github.com/cure53/DOMPurify/pull/943) Backporter should be aware of GHSA-mmhx-hmjr-r674 (CVE-2024-45801) when cherry-picking POC is avaible under [test](https://github.com/cure53/DOMPurify/blob/0ef5e537a514f904b6aa1d7ad9e749e365d7185f/test/test-suite.js#L2098)

Affected versions are vulnerable to XML signature bypass attacks. An attacker can carry out signature bypass if you have access to certain IDP-signed messages. The underlying mechanism exploits differential behavior between XML parsers. Users of https://ssoready.com, the public hosted instance of SSOReady, are unaffected. We advise folks who self-host SSOReady to upgrade to 7f92a06 or later. Do so by updating your SSOReady Docker images from `sha-...` to `sha-7f92a06`. The documentation for self-hosting SSOReady is available [here](https://ssoready.com/docs/self-hosting/self-hosting-sso-ready). Vulnerability was discovered by @ahacker1-securesaml. It's likely the precise mechanism of attack affects other SAML implementations, so the reporter and I (@ucarion) have agreed to not disclose it in detail publicly at this time.

A path traversal vulnerability exists in the ParisNeo/lollms repository, specifically in the `lollms_file_system.py` file. The functions `add_rag_database`, `toggle_mount_rag_database`, and `vectorize_folder` do not implement security measures such as `sanitize_path_from_endpoint` or `sanitize_path`. This allows an attacker to perform vectorize operations on `.sqlite` files in any directory on the victim's computer, potentially installing multiple packages and causing a crash.

Snipe-IT before 7.0.10 allows remote code execution (associated with cookie serialization) when an attacker knows the APP_KEY. This is exacerbated by .env files, available from the product's repository, that have default APP_KEY values.

Versions of the package jsonpath-plus before 10.0.0 are vulnerable to Remote Code Execution (RCE) due to improper input sanitization. An attacker can execute aribitrary code on the system by exploiting the unsafe default usage of vm in Node. **Note:** The unsafe behavior is still available after applying the fix but it is not turned on by default.

### Impact **What kind of vulnerability is it? Who is impacted?** This vulnerability is a **data validation issue** in the Gradio `Dropdown` component's pre-processing step. Even if the `allow_custom_value` parameter is set to `False`, attackers can bypass this restriction by sending custom requests with arbitrary values, effectively breaking the developer’s intended input constraints. While this alone is not a severe vulnerability, it can lead to more critical security issues, particularly when paired with other vulnerabilities like file downloads from the user's machine. ### Patches Yes, this issue is addressed in `gradio>=5.0`. Please upgrade to the latest version to resolve the problem. ### Workarounds **Is there a way for users to fix or remediate the vulnerability without upgrading?** To mitigate the issue without upgrading, developers can add manual validation in their prediction function to check the received values against the allowed dropdown values before processing th...

### 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 ...

### Impact **What kind of vulnerability is it? Who is impacted?** This vulnerability involves **insecure communication** between the FRP (Fast Reverse Proxy) 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. ### 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 avoid using `share=True` in production environments and instead host their Gradio applications on servers with HTTPS enabled to ensure secure communication.

### Impact **What kind of vulnerability is it? Who is impacted?** This vulnerability 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. This could lead to the interception of 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, where malicious actors could exploit this race condition. ### Patches Yes, please upgrade to `gradio>=5` to address this issue.