ghsa

mat2 (aka metadata anonymisation toolkit) before 0.13.0 allows ../ directory traversal during the ZIP archive cleaning process. This primarily affects mat2 web instances, in which clients could obtain sensitive information via a crafted archive.

In the login API, an IP address will by default be blocked when the user tries to login incorrectly more than 5 times. However, a bypass to this mechanism is possible by abusing a X-Forwarded-For header to bypass IP detection and perform a password brute-force. A patch for this issue is available on the `1.2-dev` branch of the Microweber GitHub repository.

### Impact A large response received by the viaduct WSClient can cause a DoS from memory exhaustion. The entire body of the response is being read into memory which could allow an attacker to send a request that returns a response with a large body. The consequence of the exhaustion is that the process which invokes a WSClient will be in a denial of service. It will be affected If users which are authenticated to the edge side and connect from the edge side to `cloudhub` through WebSocket protocol. ### Patches This bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue. ### Workarounds At the time of writing, no workaround exists. ### References NA ### Credits Thanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the [kubeedge security policy](https://github.com/kubeedge/kubeedge/security/policy) during a security audit sponsored by CNCF and facilitated by OSTIF. ...

### Impact The Cloud Stream server and the Edge Stream server reads the entire message into memory without imposing a limit on the size of this message. An attacker can exploit this by sending a large message to exhaust memory and cause a DoS. The Cloud Stream server and the Edge Stream server are under DoS attack in this case. The consequence of the exhaustion is that the CloudCore and EdgeCore will be in a denial of service. Only an authenticated user can cause this issue. It will be affected only when users enable cloudStream module in the config file cloudcore.yaml and enable edgeStream module in the config file edgecore.yaml as below. cloudcore.yaml: ``` modules: ... cloudStream: enable: true ``` edgecore.yaml: ``` modules: ... edgeStream: enable: true ``` ### Patches This bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue. ### Workarounds Disable cloudStream module in the config file cloudcore.yaml an...

### Impact The CloudCore Router does not impose a limit on the size of responses to requests made by the REST handler. An attacker could use this weakness to make a request that will return an HTTP response with a large body and cause DoS of CloudCore. In the HTTP Handler API, the rest handler makes a request to a pre-specified handle. The handle will return an HTTP response that is then read into memory. The consequence of the exhaustion is that CloudCore will be in a denial of service. Only an authenticated user of the cloud can make an attack. It will be affected only when users enable `router` module in the config file `cloudcore.yaml` as below. ``` modules: ... router: enable: true ``` ### Patches This bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue. ### Workarounds Disable the router module in the config file `cloudcore.yaml`. ### References NA ### Credits Thanks David Korczynski and Adam Korczynski of A...

### Impact EdgeCore may be susceptible to a DoS attack on CloudHub if an attacker was to send a well-crafted HTTP request to `/edge.crt`. If an attacker can send a well-crafted HTTP request to CloudHub, and that request has a very large body, that request could crash the HTTP service through a memory exhaustion vector. The request body is being read into memory, and a body that was larger than the available memory could lead to a successful attack. Because the request would have to make it through authorization, only authorized users could perform this attack. The consequence of the exhaustion is that CloudHub will be in denial of service. It will be affected only when users enable the CloudHub module in the file `cloudcore.yaml` as below: ``` modules: ... cloudHub: enable: true ``` ### Patches This bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue. ### Workarounds Disable the CloudHub module in the config file `c...

### Impact Several endpoints including `/devicemodels`, `/rules`, `/ruleendpoints`, `/offlinemigration` in the Cloud Admissioncontroller may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it. Only an authenticated user can cause this issue. It will be affected when users deploy a Cloud Admissioncontroller. The consequence of the exhaustion is that the Cloud Admissioncontroller will be in denial of service. ### Patches This bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue. ### Workarounds At the time of writing, no workaround exists. ### References NA ### Credits Thanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the [kubeedge security policy](https://github.com/kubeedge/kubeedge/security/policy) during a security audit sponsored by CNCF and facilitated by OSTIF. ### For more information If you have any questions ...

### Impact The ServiceBus server on the edge side may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it. It is possible for the node to be exhausted of memory. The consequence of the exhaustion is that other services on the node, e.g. other containers, will be unable to allocate memory and thus causing a denial of service. Malicious Apps which by accident pulled by users on the host and have the access to send HTTP requests to localhost may make an attack. It will be affected only when users enable the `ServiceBus` module in the config file `edgecore.yaml` as below: ``` modules: ... serviceBus: enable: true ``` ### Patches This bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue. ### Workarounds Disable the ServiceBus module in the config file `edgecore.yaml`. ### References NA ### Credits Thanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosin...

spring-boot versions prior to version `v2.2.11.RELEASE` was vulnerable to temporary directory hijacking. This vulnerability impacted the `org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir` method. The vulnerable method is used to create a work directory for embedded web servers such as Tomcat and Jetty. The directory contains configuration files, JSP/class files, etc. If a local attacker got the permission to write in this directory, they could completely take over the application (ie. local privilege escalation). #### Impact Location This vulnerability impacted the following source location: ```java /** * Return the absolute temp dir for given web server. * @param prefix server name * @return the temp dir for given server. */ protected final File createTempDir(String prefix) { try { File tempDir = File.createTempFile(prefix + ".", "." + getPort()); tempDir.delete(); tempDir.mkdir(); tempDir.deleteOnExit(); return temp...

Prior to Microweber v1.2.20, due to improper neutralization of input, an attacker can steal tokens to perform cross-site request forgery, fetch contents from same-site and redirect a user.