ghsa

### Summary In ```model_dict = torch.load(full_path, map_location=torch.device(device), weights_only=True)``` in monai/bundle/scripts.py , ```weights_only=True``` is loaded securely. However, insecure loading methods still exist elsewhere in the project, such as when loading checkpoints. This is a common practice when users want to reduce training time and costs by loading pre-trained models downloaded from platforms like huggingface. Loading a checkpoint containing malicious content can trigger a deserialization vulnerability, leading to code execution. The following proof-of-concept demonstrates the issues that arise when loading insecure checkpoints. ``` import os import tempfile import json import torch from pathlib import Path class MaliciousPayload: def __reduce__(self): return (os.system, ('touch /tmp/hacker2.txt',)) def test_checkpoint_loader_attack(): temp_dir = Path(tempfile.mkdtemp()) checkpoint_file = temp_dir / "m...

### Summary The extractall function ```zip_file.extractall(output_dir)``` is used directly to process compressed files. It is used in many places in the project. When the Zip file containing malicious content is decompressed, it will overwrite the system files. In addition, the project allows the download of the zip content through the link, which increases the scope of exploitation of this vulnerability. When reproducing locally, follow the process below to create a malicious zip file and simulate the process of remotely downloading the zip file. ``` root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# mkdir -p test_bundle root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# echo "malicious content" > test_bundle/malicious.txt root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm# cd test_bundle root@autodl-container-a53c499c18-c5ca272d:~/autodl-tmp/mmm/test_bundle# zip -r ../malicious.zip . ../../../../../../etc/passwd adding: malicious.txt (stored 0%) addi...

### Impact TinyEnv did not properly strip inline comments inside .env values. This could lead to unexpected behavior or misconfiguration, where variables contain unintended characters (including # or comment text). Applications depending on strict environment values may expose logic errors, insecure defaults, or failed authentication. ### Patches Fixed in v1.0.11. Users should upgrade to the latest patched version. ### Workarounds As a temporary workaround, avoid using inline comments in .env files, or sanitize loaded values manually.

### Impact TinyEnv did not require the `.env` file to exist when loading environment variables. This could lead to **unexpected behavior** where the application silently ignores missing configuration, potentially causing insecure defaults or deployment misconfigurations. Affected versions: - **1.0.1 → 1.0.2** - **1.0.9 → 1.0.10** ### Patches The issue has been fixed in **version 1.0.11**. All users should upgrade to `1.0.11` or later. ### Workarounds As a workaround, users can manually verify the existence of the `.env` file before initializing TinyEnv, for example: ```php if (!file_exists(__DIR__ . '/.env')) { throw new RuntimeException('.env file is missing!'); }

### Summary Files starting with the same name with the public directory were served bypassing the `server.fs` settings. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using --host or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - uses [the public directory feature](https://vite.dev/guide/assets.html#the-public-directory) (enabled by default) - a symlink exists in the public directory ### Details The [servePublicMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L79) function is in charge of serving public files from the server. It returns the [viteServePublicMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L106) function which runs the needed tests and serves the page. The viteSer...

### Summary Any HTML files on the machine were served regardless of the `server.fs` settings. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using --host or [server.host config option](https://vitejs.dev/config/server-options.html#server-host)) - `appType: 'spa'` (default) or `appType: 'mpa'` is used This vulnerability also affects the preview server. The preview server allowed HTML files not under the output directory to be served. ### Details The [serveStaticMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L123) function is in charge of serving static files from the server. It returns the [viteServeStaticMiddleware](https://github.com/vitejs/vite/blob/9719497adec4ad5ead21cafa19a324bb1d480194/packages/vite/src/node/server/middlewares/static.ts#L136) function which runs the needed tests and serves the page. The...

### Summary In Maho 25.7.0, an authenticated staff user with access to the `Dashboard` and `Catalog\Manage Products` permissions can create a custom option on a listing with a file input field. By allowing file uploads with a `.php` extension, the user can use the filed to upload malicious PHP files, gaining remote code execution ### Details An user with the `Dashboard` and `Catalog\Manage Products` permissions can abuse the product custom options feature to bypass the application’s file upload restrictions. When creating a product custom option of type file upload, the user is allowed to define their own extension whitelist. This bypasses the application’s normal enforced whitelist and permits disallowed extensions, including `.php`. The file uploaded by the custom option is then written to a predictable location: ``` /public/media/custom_options/<first char of filename>/<second char of filename>/<md5 of file contents>.php ``` Because this path is directly accessible under the app...

### Overview A security review of the Cattown identified multiple weaknesses that could potentially impact its stability and security. ### Affected Versions - All versions below 1.0.2 ### Description of Vulnerabilities 1. CWE-1333: Inefficient Regular Expression Complexity The package used regular expressions with inefficient, potentially exponential worst-case complexity. This can cause excessive CPU usage due to excessive backtracking on crafted inputs, potentially leading to denial of service. 2. CWE-400: Uncontrolled Resource Consumption (Resource Exhaustion) The package was vulnerable to resource exhaustion, where processing malicious inputs could cause high CPU or memory usage, potentially leading to denial of service. ### Impact - Trigger excessive CPU consumption leading to denial of service - Cause resource exhaustion affecting service availability - Bypass protection mechanisms causing unexpected or insecure behavior ### Resolution These vulnerabilities have been fixed in...

### Summary Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application. ### Details During a security evaluation of the webapp, every http request in addition to the session cookie `session` there included `nonce`. The value is not checked and validated by the backend, removing `nonce` allows the requests to be processed correctly. This may seem harmless, but if chained to other vulnerabilities it can become a critical vulnerabi...

### Impact OctoPrint versions up until and including 1.11.2 contain a vulnerability that allows an **authenticated** attacker to upload a file under a specially crafted filename that will allow arbitrary command execution if said filename becomes included in a command defined in a system event handler and said event gets triggered. If no event handlers executing system commands with uploaded filenames as parameters have been configured, this vulnerability does not have an impact. ### Patches The vulnerability will be patched in version 1.11.3. ### Workaround Until the patch has been applied, OctoPrint administrators who have event handlers configured that include any kind of filename based placeholders (i.e. `{__filename}`, `{__filepath}`, `{filename}`, `{path}`, etc -- refer to [the events documentation](https://docs.octoprint.org/en/master/events/index.html#placeholders) for a full list) should disable those by setting their `enabled` property to `False` or unchecking the "Enab...