#maven

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-34q3-p352-c7q8. This link is maintained to preserve external references. ## Original Description Central Dogma versions prior to 0.64.0 is vulnerable to Cross-Site Scripting (XSS), which could allow for the leakage of user sessions and subsequent authentication bypass.

In Spring Cloud Contract, versions 4.1.x prior to 4.1.1, versions 4.0.x prior to 4.0.5, and versions 3.1.x prior to 3.1.10, test execution is vulnerable to local information disclosure via temporary directory created with unsafe permissions through the shaded com.google.guava:guava dependency in the org.springframework.cloud:spring-cloud-contract-shade dependency.

CrateDB 5.5.1 is contains an authentication bypass vulnerability in the Admin UI component. After configuring password authentication and_ Local_ In the case of an address, identity authentication can be bypassed by setting the X-Real IP request header to a specific value and accessing the Admin UI directly using the default user identity.

In Apache Kylin version 2.0.0 to 4.0.3, there is a Server Config web interface that displays the content of file 'kylin.properties', that may contain serverside credentials. When the kylin service runs over HTTP (or other plain text protocol), it is possible for network sniffers to hijack the HTTP payload and get access to the content of kylin.properties and potentially the containing credentials. To avoid this threat, users are recommended to  * Always turn on HTTPS so that network payload is encrypted. * Avoid putting credentials in kylin.properties, or at least not in plain text. * Use network firewalls to protect the serverside such that it is not accessible to external attackers. * Upgrade to version Apache Kylin 4.0.4, which filters out the sensitive content that goes to the Server Config web interface.

Jenkins Git server Plugin 99.va_0826a_b_cdfa_d and earlier does not disable a feature of its command parser that replaces an '@' character followed by a file path in an argument with the file's contents, allowing attackers with Overall/Read permission to read content from arbitrary files on the Jenkins controller file system.

Jenkins has a built-in command line interface (CLI) to access Jenkins from a script or shell environment. Since Jenkins 2.217 and LTS 2.222.1, one of the ways to communicate with the CLI is through a WebSocket endpoint. This endpoint relies on the default Jenkins web request authentication functionality, like HTTP Basic authentication with API tokens, or session cookies. This endpoint is enabled when running on a version of Jetty for which Jenkins supports WebSockets. This is the case when using the provided native installers, packages, or the Docker containers, as well as when running Jenkins with the command java -jar jenkins.war. Jenkins 2.217 through 2.441 (both inclusive), LTS 2.222.1 through 2.426.2 (both inclusive) does not perform origin validation of requests made through the CLI WebSocket endpoint, resulting in a cross-site WebSocket hijacking (CSWSH) vulnerability.

Jenkins GitLab Branch Source Plugin 684.vea_fa_7c1e2fe3 and earlier unconditionally discovers projects that are shared with the configured owner group, allowing attackers to configure and share a project, resulting in a crafted Pipeline being built by Jenkins during the next scan of the group.

Jenkins sets the Content-Security-Policy header to static files served by Jenkins (specifically DirectoryBrowserSupport), such as workspaces, /userContent, or archived artifacts, unless a Resource Root URL is specified. Red Hat Dependency Analytics Plugin 0.7.1 and earlier globally disables the Content-Security-Policy header for static files served by Jenkins whenever the 'Invoke Red Hat Dependency Analytics (RHDA)' build step is executed. This allows cross-site scripting (XSS) attacks by users with the ability to control files in workspaces, archived artifacts, etc.

Impact SOFARPC defaults to using the SOFA Hessian protocol to deserialize received data, while the SOFA Hessian protocol uses a blacklist mechanism to restrict deserialization of potentially dangerous classes for security protection. But there is a gadget chain that can bypass the SOFA Hessian blacklist protection mechanism, and this gadget chain only relies on JDK and does not rely on any third-party components. Patches Fixed this issue by adding a blacklist, users can upgrade to sofarpc version 5.12.0 to avoid this issue. Workarounds SOFARPC also provides a way to add additional blacklist. Users can add some class like -Drpc_serialize_blacklist_override=org.apache.xpath. to avoid this issue.

An incomplete fix was found in Keycloak Core patch. An attacker can steal authorization codes or tokens from clients using a wildcard in the JARM response mode "form_post.jwt". It is observed that changing the response_mode parameter in the original proof of concept from "form_post" to "form_post.jwt" can bypass the security patch implemented to address CVE-2023-6134.