ghsa

node-red-dashboard contains a cross-site scripting vulnerability. This issue affects some unknown processing of the file `components/ui-component/ui-component-ctrl.js` of the component ui_text Format Handler. The attack may be initiated remotely. The issue is patched in version 3.2.0.

If Apache Tomcat 8.5.0 to 8.5.52, 9.0.0-M1 to 9.0.67, 10.0.0-M1 to 10.0.26 or 10.1.0-M1 to 10.1.0 was configured to ignore invalid HTTP headers via setting rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did not reject a request containing an invalid Content-Length header making a request smuggling attack possible if Tomcat was located behind a reverse proxy that also failed to reject the request with the invalid header.

### Impact The package muhammara before 2.6.0; all versions of package hummus are vulnerable to Denial of Service (DoS) when supplied with a maliciously crafted PDF file to be appended to another. ### Patches It has been patched in 2.6.0 for muhammara and not at all for hummus ### Workarounds Do not process files from untrusted sources ### References PR: https://github.com/julianhille/MuhammaraJS/pull/194 Issue: https://github.com/julianhille/MuhammaraJS/issues/191 Issue in hummus: https://github.com/galkahana/HummusJS/issues/293 ### Outline differences to https://nvd.nist.gov/vuln/detail/CVE-2022-25892 The difference is one is in [src/deps/PDFWriter/PDFParser.cpp](https://github.com/julianhille/MuhammaraJS/commit/1890fb555eaf171db79b73fdc3ea543bbd63c002#diff-09ac2c64aeab42b14b2ae7b11a5648314286986f8c8444a5b3739ba7203b1e9b) and the other is [PDFDocumentHandler.cpp](https://github.com/julianhille/MuhammaraJS/pull/194/files#diff-38d338ea4c047fd7dd9a05b5ffe7c964f0fa7e79aff4c307ccee75...

### Impact The package muhammara before 2.6.1, from 3.0.0 and before 3.1.1; all versions of package hummus are vulnerable to Denial of Service (DoS) when supplied with a maliciously crafted PDF file to be parsed. ### Patches It has been patched in 3.1.1 and has been backported to 2.6.1 There is no patch for hummus ### Workarounds Do not process files from untrusted sources or update. ### References https://nvd.nist.gov/vuln/detail/CVE-2022-25892 https://github.com/galkahana/HummusJS/issues/463 https://github.com/julianhille/MuhammaraJS/issues/214 https://github.com/julianhille/MuhammaraJS/commit/1890fb555eaf171db79b73fdc3ea543bbd63c002 https://github.com/julianhille/MuhammaraJS/commit/90b278d09f16062d93a4160ef0a54d449d739c51 https://security.snyk.io/vuln/SNYK-JS-HUMMUS-3091138 https://security.snyk.io/vuln/SNYK-JS-MUHAMMARA-3060320

# Missing JWT signature check (`GHSL-2022-078`) The [`StatelessTokenService`](https://github.com/datahub-project/datahub/blob/aa146db611e3a4ca3aa17bb740783f789d4444d3/metadata-service/auth-impl/src/main/java/com/datahub/authentication/token/StatelessTokenService.java#L30) of the DataHub metadata service (GMS) does not verify the signature of JWT tokens. This allows an attacker to connect to DataHub instances as any user if Metadata Service authentication is enabled. This vulnerability occurs because the `StatelessTokenService` of the Metadata service uses the [`parse`](https://github.com/datahub-project/datahub/blob/aa146db611e3a4ca3aa17bb740783f789d4444d3/metadata-service/auth-impl/src/main/java/com/datahub/authentication/token/StatelessTokenService.java#L134) method of `io.jsonwebtoken.JwtParser`, which does not perform a verification of the cryptographic token signature. This means that JWTs are accepted regardless of the used algorithm. #### Impact This issue may lead to an auth...

ProcessWire v3.0.200 was discovered to contain a Cross-Site Request Forgery (CSRF).

ProcessWire v3.0.200 was discovered to contain multiple cross-site scripting (XSS) vulnerabilities via the Search Users and Search Pages function. These vulnerabilities allow attackers to execute arbitrary web scripts or HTML via injection of a crafted payload.

This issue affects the function file of the file helpers/Upload.php of the component File Upload Management. The manipulation leads to unrestricted upload. The attack may be initiated remotely.

### Impact Attackers can create long chains of CAs that would lead to OctoRPKI exceeding its max iterations parameter that would cause the program to crash and not finish the validation and thus a denial of service. ### Patches This issue is fixed in v1.4.4 ### Workarounds None.

Prior to version 0.4.2, `conduit-hyper` did not check any limit on a request's length before calling [`hyper::body::to_bytes`](https://docs.rs/hyper/latest/hyper/body/fn.to_bytes.html). An attacker could send a malicious request with an abnormally large `Content-Length`, which could lead to a panic if memory allocation failed for that request. In version 0.4.2, `conduit-hyper` sets an internal limit of 128 MiB per request, otherwise returning status 400 ("Bad Request"). This crate is part of the implementation of Rust's [crates.io](https://crates.io/), but that service is not affected due to its existing cloud infrastructure, which already drops such malicious requests. Even with the new limit in place, `conduit-hyper` is not recommended for production use, nor to directly serve the public Internet. The vulnerability was discovered by Ori Hollander from the JFrog Security Research team.