ghsa

### Impact A vulnerability has been identified when granting a `create` or `*` **global role** for a resource type of "namespaces"; no matter the API group, the subject will receive `*` permissions for core namespaces. This can lead to someone being capable of accessing, creating, updating, or deleting a namespace in the project. This includes reading or updating a namespace in the project so that it is available in other projects in which the user has the "manage-namespaces" permission or updating another namespace in which the user has normal "update" permissions to be moved into the project. The expected behavior is to not be able to create, update, or delete a namespace in the project or move another namespace into the project since the user doesn't have any permissions on namespaces in the core API group. Moving a namespace to another project could lead to leakage of secrets, in case the targeted project has secrets. And also can lead to the namespace being able to abuse the res...

### Impact The attachment file of an existing record can be replaced if the user has `"read"` permission on one of the parent (collection or bucket). And if the `"read"` permission is given to `"system.Everyone"` on one of the parent, then the attachment can be replaced on a record using an anonymous request. Note that if the parent has no explicit read permission, then the records attachments are safe. ### Patches - Patch released in kinto-attachment 6.4.0 - https://github.com/Kinto/kinto-attachment/commit/f4a31484f5925cbc02b59ebd37554538ab826ca1 ### Workarounds None if the read permission has to remain granted. Updating to 6.4.0 or applying the patch individually (if updating is not feasible) is strongly recommended. ### References - https://bugzilla.mozilla.org/show_bug.cgi?id=1879034

An issue in NPM IP Package v.1.1.8 and before allows an attacker to execute arbitrary code and obtain sensitive information via the `isPublic()` function. This can lead to potential Server-Side Request Forgery (SSRF) attacks. The core issue is the function's failure to accurately distinguish between public and private IP addresses.

# Summary .be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges. # Details If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the .be/.Local folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges. # PoC As a standard, non-admin user: 1. Monitor the user's TEMP folder for changes using ReadDirectoryChangesW 1. On FILE_ACTION_ADDED, check if the folder name is .be 1. Create a folder in .be named after the bundle + .Local (e.g. MyInstaller.exe.Local) 1. Put the malicious COMCTL32.DLL in the .Local folder following the naming used for the real DLL (e.g. MyInstaller.exe.Local/x86_microsoft.windows.common-controls_.../COMCTL32.dll) 1. Do hacker things when the engine escalates and the malicious DLL is loaded Proper naming f...

# Summary .be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges. # Details If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the .be/.Local folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges. # PoC As a standard, non-admin user: 1. Monitor the user's TEMP folder for changes using ReadDirectoryChangesW 1. On FILE_ACTION_ADDED, check if the folder name is .be 1. Create a folder in .be named after the bundle + .Local (e.g. MyInstaller.exe.Local) 1. Put the malicious COMCTL32.DLL in the .Local folder following the naming used for the real DLL (e.g. MyInstaller.exe.Local/x86_microsoft.windows.common-controls_.../COMCTL32.dll) 1. Do hacker things when the engine escalates and the malicious DLL is loaded Proper naming f...

### Summary .be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges. ### Details If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the **.be/<bundle>.Local** folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges. ### PoC As a standard, non-admin user: 1. Monitor the user's TEMP folder for changes using ReadDirectoryChangesW 2. On FILE_ACTION_ADDED, check if the folder name is .be 3. Create a folder in .be named after the bundle + .Local (e.g. MyInstaller.exe.Local) 4. Put the malicious COMCTL32.DLL in the .Local folder following the naming used for the real DLL (e.g. MyInstaller.exe.Local/x86_microsoft.windows.common-controls_.../COMCTL32.dll) 5. Do hacker things when the engine escalates and the malicious DLL is loaded Proper...

### Impact Any user could get a token that has been requested by another user/agent ### Patches The vulnerability is fixed in version 8.0.37. ### Workarounds None ### References

xxl-job <= 2.4.0 has a Server-Side Request Forgery (SSRF) vulnerability, which causes low-privileged users to control executor to RCE.

### Impact Several files within the local working directory are included during the invocation of Composer and in the context of the executing user. As such, under certain conditions arbitrary code execution may lead to local privilege escalation, provide lateral user movement or malicious code execution when Composer is invoked within a directory with tampered files. All Composer CLI commands are affected, including composer.phar's self-update. The following are of high risk: - Composer being run with sudo. - Pipelines which may execute Composer on untrusted projects. - Shared environments with developers who run Composer individually on the same project. ### Patches 2.7.0, 2.2.23 ### Workarounds - It is advised that the patched versions are applied at the earliest convenience. Where not possible, the following should be addressed: - Remove all sudo composer privileges for all users to mitigate root privilege escalation. - Avoid running Composer within an untrusted direct...

Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 18, and older unsupported versions returns with different responses depending on whether a site does not exist or if the user does not have permission to access the site, which allows remote attackers to discover the existence of sites by enumerating URLs. This vulnerability occurs if locale.prepend.friendly.url.style=2 and if a custom 404 page is used.