#maven

ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.

Cross-site scripting (XSS) vulnerability in the edit Service Access Policy page in Liferay Portal 7.0.0 through 7.4.3.87, and Liferay DXP 7.4 GA through update 87, 7.3 GA through update 29, and older unsupported versions allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a service access policy's `Service Class` text field.

### Impact The welcome and about page includes version and revision information about the software in use (including library and components used). This information is sensitive from a security point of view because it allows software used by the server to be easily identified. ### Proof of Concept 1. Welcome page footer: <img width="432" alt="image" src="https://github.com/geoserver/geoserver/assets/629681/a7fd5151-55d5-432b-9d5d-79136833609f"> 2. About page *build information*. <img width="401" alt="image" src="https://github.com/geoserver/geoserver/assets/629681/59fcd8dd-eaee-4bf8-9578-a2a94b2864db"> ### Patches No patch presently available. ### Workarounds No workaround available, although the ADMIN_CONSOLE can be disabled completely. ### References * [About GeoServer](https://docs.geoserver.org/latest/en/user/webadmin/about.html)

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server._ There is a potential XXE(XML External Entity Injection) vulnerability when http4k handling malicious XML contents within requests, which might allow attackers to read local sensitive information on server, trigger Server-side Request Forgery and even execute code under some circumstances. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ https://github.com/http4k/http4k/blob/25696dff2d90206cc1da42f42a1a8dbcdbcdf18c/core/format/xml/src/main/kotlin/org/http4k/format/Xml.kt#L42-L46 XML contents is parsed with DocumentBuilder without security settings on or external entity enabled ### PoC _Complete instructions, including specific configuration details, to reproduce the vulnerability._ #### ...

### Summary sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients...

### Impact Executing policy checks using custom schematron files via the CLI invokes an XSL transformation that may theoretically lead to a remote code execution (RCE) vulnerability. ### Patches We are currently working on a patch that will be released when ready. ### Workarounds This doesn't affect the standard validation and policy checks functionality, veraPDF's common use cases. Most veraPDF users don't insert any custom XSLT code into policy profiles, which are based on Schematron syntax rather than direct XSL transforms. For users who do, only load custom policy files from sources you trust. ### References Original issue: #1488

Jenkins Filesystem List Parameter Plugin 0.0.14 and earlier does not restrict the path used for the File system objects list Parameter. This allows attackers with Item/Configure permission to enumerate file names on the Jenkins controller file system. Filesystem List Parameter Plugin 0.0.15 ensures that paths used by the File system objects list Parameter are restricted to an allow list, with the default base directory set to $JENKINS_HOME/userContent/. The allow list can be configured to include additional custom base directories.

### Summary sigstore-java has insufficient verification for a situation where a validly-signed but "mismatched" bundle is presented as proof of inclusion into a transparency log ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() The verifier may accept a bundle with an unrelated log entry, cryptographically verifying everything but fails to ensure the log entry applies to the artifact in question, thereby "verifying" a bundle without any proof the signing event was logged. This allows the creation of a bundle without fulcio certificate and private key combined with an unrelated but time-correct log entry to fake logging of a signing event. A malicious actor using a compromised identity may want to do this to prevent discovery via rekor's log monitors. The signer's identity will still be available to the verifier. The signature on the bundle must still be on the correct artifact for the verifier to pass. sigstore-gradle-plugin and sigstore-maven-pl...

A vulnerability was found in Keycloak. Deployments of Keycloak with a reverse proxy not using pass-through termination of TLS, with mTLS enabled, are affected. This issue may allow an attacker on the local network to authenticate as any user or client that leverages mTLS as the authentication mechanism.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-jgwc-jh89-rpgq. This link is maintained to preserve external references. ## Original Description A vulnerability was found in the Keycloak Server. The Keycloak Server is vulnerable to a denial of service (DoS) attack due to improper handling of proxy headers. When Keycloak is configured to accept incoming proxy headers, it may accept non-IP values, such as obfuscated identifiers, without proper validation. This issue can lead to costly DNS resolution operations, which an attacker could exploit to tie up IO threads and potentially cause a denial of service. The attacker must have access to send requests to a Keycloak instance that is configured to accept proxy headers, specifically when reverse proxies do not overwrite incoming headers, and Keycloak is configured to trust these headers.