ghsa

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

An issue in the isSVG() function of Known v1.3.1 allows attackers to execute arbitrary code via a crafted SVG file. The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the `dev` branch of the idno/known repository.

Known v1.3.1 was discovered to allow attackers to perform an account takeover via a host header injection attack. The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the `dev` branch of the idno/known repository.

rpc.py through 0.6.0 allows Remote Code Execution because an unpickle occurs when the "serializer: pickle" HTTP header is sent. In other words, although JSON (not Pickle) is the default data format, an unauthenticated client can cause the data to be processed with unpickle. [Per the maintainer](https://github.com/abersheeran/rpc.py/issues/22), rpc.py is not designed for an API that is open to the outside world, and external requests cannot reach rpc.py in real world use. A [fix](https://github.com/abersheeran/rpc.py/commit/491e7a841ed9a754796d6ab047a9fb16e23bf8bd) exists on the `master` branch. As a workaround, use the following code to turn off pickle in older versions: ``` del SERIALIZER_NAMES[PickleSerializer.name] del SERIALIZER_TYPES[PickleSerializer.content_type]

### Impact If a consensus client sends a malformed consensus request to an orderer it may crash the orderer node. This fix checks for the malformed consensus request and returns an error to the consensus client. ### Patches Fixed in v2.2.7 and v2.4.5. ### Workarounds None, users must upgrade to v2.2.7 or v2.4.5. ### References https://github.com/hyperledger/fabric/releases/tag/v2.2.7 https://github.com/hyperledger/fabric/releases/tag/v2.4.5 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Hyperledger Fabric repository](https://github.com/hyperledger/fabric/issues) ### Credits Thank you to Haosheng Wang of OPPO ZIWU Security Lab for this disclosure.