ghsa

Multiple cross-site scripting (XSS) vulnerabilities in the Notifications widget in Liferay Portal 7.4.3.102 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5 and 2023.Q3.1 through 2023.Q3.10 allow remote attackers to inject arbitrary web script or HTML via a crafted payload injected into (1) a user’s “First Name” text field, (2) a user’s “Middle Name” text field, (3) a user’s “Last Name” text field, (4) the “Other Reason” text field when flagging content, or (5) the name of the flagged content.

Cross-Site Scripting in vaahcms v.2.3.1 allows a remote attacker to execute arbitrary code via upload method in the storeAvatar() method of UserBase.php

Cross-site scripting (XSS) vulnerability in the Commerce Product Comparison Table widget in Liferay Portal 7.4.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, and 7.4 GA through update 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a Commerce Product's Name text field.

### Impact A memory safety vulnerability was present in the Fuel Virtual Machine (FuelVM), where memory reads could bypass expected access controls. Specifically, when a smart contract performed a `mload` (or other opcodes which access memory) on memory that had been deallocated using `ret`, it was still able to access the old memory contents. This occurred because the memory region was not zeroed out or otherwise marked as invalid. As a result, smart contracts could potentially read sensitive data left over from other contracts if the same memory was reallocated, violating isolation guarantees between contracts and enabling unintended data leakage. All users running affected versions of FuelVM that relied on strict memory isolation between smart contracts were impacted. ### Patches The vulnerability was patched by modifying the FuelVM to ensure that memory deallocated with `ret` was zeroed out or made inaccessible. The fix was included in FuelVM version `v0.60.1` and back-ported t...

File upload leading to remote code execution (RCE) in the “melis-cms-slider” module of Melis Technology's Melis Platform. This vulnerability allows an attacker to upload a malicious file via a POST request to '/melis/MelisCmsSlider/MelisCmsSliderDetails/saveDetailsForm' using the 'mcsdetail_img' parameter.

SQL injection vulnerability based on the melis-cms module of the Melis platform from Melis Technology. This vulnerability allows an attacker to retrieve, create, update, and delete databases through the 'idPage' parameter in the '/melis/MelisCms/PageEdition/getTinyTemplates' endpoint.

Vulnerability in the melis-core module of Melis Technology's Melis Platform, which, if exploited, allows an unauthenticated attacker to create an administrator account via a request to '/melis/MelisCore/ToolUser/addNewUser'.

Multiple stored cross-site scripting (XSS) vulnerabilities in Liferay Portal 7.4.3.15 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, and 7.4 update 15 through update 92 allow remote attackers to inject arbitrary web script or HTML via crafted payload injected into a Terms and Condition's Name text field to (1) Payment Terms, or (2) the Delivery Term on the view order page.

Cross-site scripting (XSS) vulnerability in the Commerce Search Result widget in Liferay Portal 7.4.0 through 7.4.3.111, and Liferay DXP 2023.Q4 before patch 6, 2023.Q3 before patch 9, and 7.4 GA through update 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a Commerce Product's Name text field.

### Summary `Deno.FsFile.prototype.utime` and `Deno.FsFile.prototype.utimeSync` are not limited by the permission model check `--deny-write=./`. It's possible to change to change the access (`atime`) and modification (`mtime`) times on the file stream resource even when the file is opened with `read` only permission (and `write`: `false`) and file write operations are not allowed (the script is executed with `--deny-write=./`). Similar APIs like `Deno.utime` and `Deno.utimeSync` require `allow-write` permission, however, when a file is opened, even with read only flags and deny-write permission, it's still possible to change the access (`atime`) and modification (`mtime`) times, and thus bypass the permission model. ### PoC Setup: ``` deno --version deno 2.4.2 (stable, release, x86_64-unknown-linux-gnu) v8 13.7.152.14-rusty typescript 5.8.3 touch test.txt ``` ```js // touch test.txt // https://docs.deno.com/api/deno/~/Deno.FsFile.prototype.utime // deno run --allow-read=./ --den...