ghsa

OroPlatform is a package that assist system and user calendar management. Back-office users can access information from any system calendar event, bypassing ACL security restrictions due to insufficient security checks.

### Impact Path Traversal is possible in `Oro\Bundle\GaufretteBundle\FileManager::getTemporaryFileName`. With this method, an attacker can pass the path to a non-existent file, which will allow writing the content to a new file that will be available during script execution. The file will be deleted immediately after the script ends. ### Workarounds Apply patch ```patch --- a/vendor/oro/platform/src/Oro/Bundle/GaufretteBundle/FileManager.php +++ b/vendor/oro/platform/src/Oro/Bundle/GaufretteBundle/FileManager.php @@ -614,6 +614,10 @@ */ public function getTemporaryFileName(string $suggestedFileName = null): string { + if ($suggestedFileName) { + $suggestedFileName = basename($suggestedFileName); + } + $tmpDir = ini_get('upload_tmp_dir'); if (!$tmpDir || !is_dir($tmpDir) || !is_writable($tmpDir)) { $tmpDir = sys_get_temp_dir(); ``` Or decorate `Oro\Bundle\GaufretteBundle\FileManager::getTemporaryFileName` in yo...

### Summary A vulnerability was fond in Knative Serving that could allow an attacker to crash the Knative Serving autoscaler resulting in a denial of service. The attacker would need to have compromised one pod in the Knative Serving deployment, and with that position they could launch the attack against the autoscaler. When the autoscaler scrapes the metrics of pods, it sends a request to the `/metrics` endpoint of each pod and reads the response. The attacker would need to detect the request from the autoscaler to the `/metrics` endpoint of the pod they had compromised and send a malicious response back to the autoscaler. At this point, the autoscaler would crash. The root cause of the vulnerability was a memory exhaustion issue in the autoscaler that the attacker could trigger with the malicious reponse. The vulnerability would allow a privilege escalation by the attacker from controlling one point to having negative impact on the entire Knative Serving deployment. ### Impact All...

### Impact `AdminBundle\Security\PimcoreUserTwoFactorCondition` introduced in v11 disable the two factor authentication for all non-admin security firewalls. An authenticated user can access the system without having to provide the 2 factor credentials. ### Patches Apply patch https://patch-diff.githubusercontent.com/raw/pimcore/admin-ui-classic-bundle/pull/345.patch ### Workarounds Upgrade to version 1.2.2 or apply the [patch](https://patch-diff.githubusercontent.com/raw/pimcore/admin-ui-classic-bundle/pull/345.patch) manually.

### Summary Improper validation make it possible for an attacker to modify the HTTP request (e.g. to insert a new header) or even create a new HTTP request if the attacker controls the HTTP version. ### Details The vulnerability only occurs if the attacker can control the HTTP version of the request (including its type). For example if an unvalidated JSON value is used as a version and the attacker is then able to pass an array as the `version` parameter. Furthermore, the vulnerability only occurs when the `Connection` header is passed to the `headers` parameter. At this point, the library will use the parsed value to create the request. If a list is passed, then it bypasses validation and it is possible to perform CRLF injection. ### PoC The POC below shows an example of providing an unvalidated array as a version: https://gist.github.com/jnovikov/184afb593d9c2114d77f508e0ccd508e ### Impact CRLF injection leading to Request Smuggling. ### Workaround If these specific conditions a...

### Summary Improper validation makes it possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. ### Details The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. Previous releases performed no validation on the provided value. If an attacker controls the HTTP method it will be used as is and can lead to HTTP request smuggling. ### PoC A minimal example can be found here: https://gist.github.com/jnovikov/7f411ae9fe6a9a7804cf162a3bdbb44b ### Impact If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling). ### Workaround If unable to upgrade and using user-provided values for the request method, perform manual validation of the user value (e.g. by restricting it to a few known values like GET, POST etc.).

### Summary llhttp 8.1.1 is vulnerable to two request smuggling vulnerabilities. Details have not been disclosed yet, so refer to llhttp for future information. The issue is resolved by using llhttp 9+ (which is included in aiohttp 3.8.6+).

In Math/BinaryField.php in phpseclib before 3.0.34, excessively large degrees in binary fields can lead to a denial of service.

### Impact The `Validator.isValidSafeHTML` method can result in false negatives where it reports some input as safe (i.e., returns true), but really isn't, and using that same input as-is can in certain circumstances result in XSS vulnerabilities. Because this method cannot be fixed, it is being deprecated and will be removed in one years time from when this advisory is published. Full details may be found in [ESAPI Security Bulletin #12](https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/ESAPI-security-bulletin12.pdf). Note that all versions of ESAPI, that have this method (which dates back to at least the ESAPI 1.3 release more than 15 years ago) have this issue and it will continue to exist until we remove these two methods in a future ESAPI release. ### Patches There is no patch. We do not believe that it is possible to patch this pretentiously named method other then perhaps renaming it to something like Validator.mightThisBeValidSafeHTML to dissuade developer...

### Summary The `runTailscalePing` method of the `TailscalePing` class injects the `hostname` parameter inside a shell command, leading to a command injection and the possibility to run arbitrary commands on the server. ### Details When adding a new monitor on Uptime Kuma, we can select the "Tailscale Ping" type. Then we can add a hostname and insert a command injection payload into it. The front-end application requires that the field follow a specific pattern, this validation only happens on the front-end and can be removed by removing the attribute `pattern` on the `input` element. https://github.com/louislam/uptime-kuma/blob/dc4242019331e65a79ac16deef97510144e01b12/server/monitor-types/tailscale-ping.js#L40-L46 We can finally add the new monitor and observe that our command is being executed. **NOTE:** When using Uptime Kuma inside a container, the "TailScale Ping" type is not visible. We can fake this information by intercepting WebSocket messages and set the `isContainer` o...