#maven

Jenkins Script Security Plugin 1367.vdf2fc45f229c and earlier, except 1365.1367.va_3b_b_89f8a_95b_ and 1362.1364.v4cf2dc5d8776, does not perform a permission check in a method implementing form validation, allowing attackers with Overall/Read permission to check for the existence of files on the controller file system. This allows attackers with Overall/Read permission to check for the existence of files on the controller file system. Script Security Plugin 1368.vb_b_402e3547e7 requires Overall/Administer permission for the affected form validation method.

Jenkins Pipeline: Groovy Plugin 3990.vd281dd77a_388 and earlier, except 3975.3977.v478dd9e956c3 does not check whether the main (Jenkinsfile) script for a rebuilt build is approved, allowing attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved. This allows attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved. Pipeline: Groovy Plugin 3993.v3e20a_37282f8 refuses to rebuild a build whose main (Jenkinsfile) script is unapproved.

Jenkins Authorize Project Plugin 1.7.2 and earlier evaluates a string containing the job name with JavaScript on the Authorization view, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission. This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission. Authorize Project Plugin 1.8.0 no longer evaluates a string containing the job name with JavaScript on the Authorization view.

### Impact The vulnerability may allow a remote attacker to terminate the application with a stack overflow error resulting in a denial of service only by manipulating the processed input stream when XStream is configured to use the BinaryStreamDriver. ### Patches XStream 1.4.21 detects the manipulation in the binary input stream causing the the stack overflow and raises an InputManipulationException instead. ### Workarounds The only solution is to catch the StackOverflowError in the client code calling XStream if XStream is configured to use the BinaryStreamDriver. ### References See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2024-47072](https://x-stream.github.io/CVE-2024-47072.html). ### Credits Alexis Challande of Trail Of Bits found and reported the issue to XStream and provided the required information to reproduce it.

### Summary Reposilite v3.5.10 is affected by an Arbitrary File Read vulnerability via path traversal while serving expanded javadoc files. ### Details The problem lies in the way how the expanded javadoc files are served. The `GET /javadoc/{repository}/<gav>/raw/<resource>` route uses the `<resource>` path parameter to find the file in the `javadocUnpackPath` directory and returns it's content to the user. [JavadocFacade.kt#L77](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocFacade.kt#L77): ```kotlin fun findRawJavadocResource(request: JavadocRawRequest): Result<JavadocRawResponse, ErrorResponse> = with (request) { mavenFacade.canAccessResource(accessToken, repository, gav) .flatMap { javadocContainerService.loadContainer(accessToken, repository, gav) } .filter({ Files.exists(it.javadocUnpackPath.resolve(resource.toString())) }, { notFound("Resourc...

### Impact The patch for the historical vulnerability CVE-2020-35460 in MPXJ is incomplete as there is still a possibility that a malicious path could be constructed which would not be picked up by the original fix and allow files to be written to arbitrary locations. ### Patches The issue is addressed in MPXJ version 13.5.1 ### Workarounds Do not pass zip files to MPXJ. ### References N/A

The load-language command expects a `lang` parameter from which it constructs the path of the localization file to load, of the form `translations-$LANG.json`. When doing so, it does not check that the resulting path is in the expected directory, which means that this command could be exploited to read other JSON files on the file system. The command should be patched by checking that the normalized path is in the expected directory.

The fix for CVE-2022-22968 made disallowedFields patterns in DataBinder case insensitive. However, String.toLowerCase() has some Locale dependent exceptions that could potentially result in fields not protected as expected.

### Impact Remote DOS attack can cause out of memory ### Description There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory. ### Affected Versions * Jetty 12.0.0-12.0.8 (Supported) * Jetty 11.0.0-11.0.23 (EOL) * Jetty 10.0.0-10.0.23 (EOL) * Jetty 9.3.12-9.4.55 (EOL) ### Patched Versions * Jetty 12.0.9 * Jetty 11.0.24 * Jetty 10.0.24 * Jetty 9.4.56 ### Workarounds Do not use `ThreadLimitHandler`. Consider use of `QoSHandler` instead to artificially limit resource utilization. ### References Jetty 12 - https://github.com/jetty/jetty.project/pull/11723

### Impact Jetty PushSessionCacheFilter can be exploited by unauthenticated users to launch remote DoS attacks by exhausting the server’s memory. ### Patches * https://github.com/jetty/jetty.project/pull/9715 * https://github.com/jetty/jetty.project/pull/9716 ### Workarounds The session usage is intrinsic to the design of the PushCacheFilter. The issue can be avoided by: + not using the PushCacheFilter. Push has been deprecated by the various IETF specs and early hints responses should be used instead. + reducing the reducing the idle timeout on unauthenticated sessions will reduce the time such session stay in memory. + configuring a session cache to use [session passivation](https://jetty.org/docs/jetty/12/programming-guide/server/session.html), so that sessions are not stored in memory, but rather in a database or file system that may have significantly more capacity than memory. ### References * https://github.com/jetty/jetty.project/pull/10756 * https://github.com/jetty/j...