Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-h8jm-2x53-xhp5: X.509 Email Address Variable Length Buffer Overflow

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.` character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

ghsa
#dos#buffer_overflow#auth#ssl
GHSA-crh6-fp67-6883: xmldom allows multiple root nodes in a DOM

### Impact xmldom parses XML that is not well-formed because it contains multiple top level elements, and adds all root nodes to the `childNodes` collection of the `Document`, without reporting any error or throwing. This breaks the assumption that there is only a single root node in the tree, which led to https://nvd.nist.gov/vuln/detail/CVE-2022-39299 and is a potential issue for dependents. ### Patches Update to `@xmldom/xmldom@~0.7.7`, `@xmldom/xmldom@~0.8.4` (dist-tag `latest`) or `@xmldom/xmldom@>=0.9.0-beta.4` (dist-tag `next`). ### Workarounds One of the following approaches might help, depending on your use case: - Instead of searching for elements in the whole DOM, only search in the `documentElement`. - Reject a document with a document that has more then 1 `childNode`. ### References - https://nvd.nist.gov/vuln/detail/CVE-2022-39299 - https://github.com/jindw/xmldom/issues/150 ### For more information If you have any questions or comments about this advisory: * Email us...

GHSA-32vj-v39g-jh23: spring-security-oauth2-client vulnerable to Privilege Escalation

Spring Security, versions 5.7 prior to 5.7.5, and 5.6 prior to 5.6.9, and older unsupported versions could be susceptible to a privilege escalation under certain conditions. A malicious user or attacker can modify a request initiated by the Client (via the browser) to the Authorization Server which can lead to a privilege escalation on the subsequent approval. This scenario can happen if the Authorization Server responds with an OAuth2 Access Token Response containing an empty scope list (per RFC 6749, Section 5.1) on the subsequent request to the token endpoint to obtain the access token.

GHSA-mmmh-wcxm-2wr4: Spring Security authorization rules can be bypassed via forward or include dispatcher types

Spring Security, versions 5.7 prior to 5.7.5 and 5.6 prior to 5.6.9 could be susceptible to authorization rules bypass via forward or include dispatcher types. Specifically, an application is vulnerable when all of the following are true: The application expects that Spring Security applies security to forward and include dispatcher types. The application uses the AuthorizationFilter either manually or via the authorizeHttpRequests() method. The application configures the FilterChainProxy to apply to forward and/or include requests (e.g. spring.security.filter.dispatcher-types = request, error, async, forward, include). The application may forward or include the request to a higher privilege-secured endpoint.The application configures Spring Security to apply to every dispatcher type via authorizeHttpRequests().shouldFilterAllDispatcherTypes(true)

GHSA-vrv9-3x3w-ffxw: node-red-dashboard vulnerable to Cross-site Scripting

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.

GHSA-p22x-g9px-3945: Apache Tomcat may reject request containing invalid Content-Length header

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.

GHSA-frp9-2v6r-gj97: muhammara and hummus vulnerable to null pointer dereference on bad response object

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

GHSA-9cv5-4wqv-9w94: muhammara and hummus vulnerable to denial of service by NULL pointer dereference

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

GHSA-r8gm-v65f-c973: acryl-datahub missing JWT signature check

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

GHSA-8g35-prrr-gxxf: ProcessWire vulnerable to Cross-site Scripting

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.