ghsa

In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Specifically, an application is vulnerable if Reactor Netty HTTP Server built-in integration with Micrometer is enabled.

In Spring Framework versions 6.0.0 - 6.0.13, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Specifically, an application is vulnerable when all of the following are true: * the application uses Spring MVC or Spring WebFlux * io.micrometer:micrometer-core is on the classpath * an ObservationRegistry is configured in the application to record observations Typically, Spring Boot applications need the org.springframework.boot:spring-boot-actuator dependency to meet all conditions.

Apache NiFi 0.7.0 through 1.23.2 include the JoltTransformJSON Processor, which provides an advanced configuration user interface that is vulnerable to DOM-based cross-site scripting. If an authenticated user, who is authorized to configure a JoltTransformJSON Processor, visits a crafted URL, then arbitrary JavaScript code can be executed within the session context of the authenticated user. Upgrading to Apache NiFi 1.24.0 or 2.0.0-M1 is the recommended mitigation.

### Summary A Server-Side Request Forgery (SSRF) Vulnerability is present in applications utilizing the `google-translate-api-browser` package and exposing the `translateOptions` to the end user. An attacker can set a malicious `tld`, causing the application to return unsafe URLs pointing towards local resources. ### Details The `translateOptions.tld` field is not properly sanitized before being placed in the Google translate URL. This can allow an attacker with control over the `translateOptions` to set the `tld` to a payload such as `@127.0.0.1`. This causes the full URL to become `https://[email protected]/...`, where `translate.google.` is the username used to connect to localhost. ### PoC Imagine a server running the following code (closely mimicking the code present in the package's README): ```javascript const express = require('express'); const { generateRequestUrl, normaliseResponse } = require('google-translate-api-browser'); const https = require('https'); const...

Detailed Checkout totals information may be received by Checkout ID

Back-office users can access information about Customer and Customer User menus, bypassing ACL security restrictions due to insufficient security checks.

Back-office users can access information from any call event, bypassing ACL security restrictions due to insufficient security checks.

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