ghsa

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

In 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 15, and older unsupported versions the `doAsUserId` URL parameter may get leaked when creating linked content using the WYSIWYG editor and while impersonating a user. This may allow remote authenticated users to impersonate a user after accessing the linked content.

The IFrame widget in Liferay Portal 7.2.0 through 7.4.3.26, and older unsupported versions, and Liferay DXP 7.4 before update 27, 7.3 before update 6, 7.2 before fix pack 19, and older unsupported versions does not check the URL of the IFrame, which allows remote authenticated users to cause a denial-of-service (DoS) via a self referencing IFrame.

### Impact You can create, delete etc. tags without having the permission to do so. This vulnerability allows an attacker to perform broken access control and add tags to admin panel and add dumy data. One can do this as intruder and add text parameters with random numbers and this will effect integrity and availability. ### Patches Available in version 1.3.3. ### Workarounds Apply this pull request manually: https://github.com/pimcore/admin-ui-classic-bundle/pull/412 ### References -