#maven

Exposure of Sensitive Information to an Unauthorized Actor, Insecure Storage of Sensitive Information vulnerability in Maven Archetype Plugin. This issue affects Maven Archetype Plugin: from 3.2.1 before 3.3.0. Users are recommended to upgrade to version 3.3.0, which fixes the issue. Archetype integration testing creates a file called ./target/classes/archetype-it/archetype-settings.xml This file contains all the content from the users ~/.m2/settings.xml file, which often contains information they do not want to publish. We expect that on many developer machines, this also contains credentials. When the user runs mvn verify again (without a mvn clean), this file becomes part of the final artifact. If a developer were to publish this into Maven Central or any other remote repository (whether as a release or a snapshot) their credentials would be published without them knowing.

### Summary When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team <[email protected]> Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. ### Severity [CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. ### Proof of Concept For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffer...

### Impact 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 update blacklist, users can upgrade to sofahessian version 3.5.5 to avoid this issue. ### Workarounds You can maintain a blacklist yourself in this directory `external/serialize.blacklist`.

### Impact It's possible to get access to notification filters of any user by using a URL such as `<hostname>xwiki/bin/get/XWiki/Notifications/Code/NotificationFilterPreferenceLivetableResults?outputSyntax=plain&type=custom&user=<username>`. This vulnerability impacts all versions of XWiki since 13.2-rc-1. The filters do not provide much information (they mainly contain references which are public data in XWiki), though some info could be used in combination with other vulnerabilities. ### Patches The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0RC1. The patch consists in checking the rights of the user when sending the data. ### Workarounds It's possible to workaround the vulnerability by applying manually the patch: it's possible for an administrator to edit directly the document `XWiki.Notifications.Code.NotificationFilterPreferenceLivetableResults` to apply the same changes as in the patch. See c8c6545f9bde6f5aade994aa5b5903a67b5c2582. ### Reference...

### Impact It's possible for any user knowing the ID of a notification filter preference of another user, to enable/disable it or even delete it. The impact is that the target user might start loosing notifications on some pages because of this. This vulnerability is present in XWiki since 13.2-rc-1. ### Patches The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0-rc-1. The patch consists in checking properly the rights of the user before performing any action on the filters. ### Workarounds It's possible to fix manually the vulnerability by editing the document `XWiki.Notifications.Code.NotificationPreferenceService` to apply the changes performed in this commit e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20337 * Commit: e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https...

Apache Druid allows users with certain permissions to read data from other database systems using JDBC. This functionality allows trusted users to set up Druid lookups or run ingestion tasks. Druid also allows administrators to configure a list of allowed properties that users are able to provide for their JDBC connections. By default, this allowed properties list restricts users to TLS-related properties only. However, when configuration a MySQL JDBC connection, users can use a particularly-crafted JDBC connection string to provide properties that are not on this allow list. Users without the permission to configure JDBC connections are not able to exploit this vulnerability. CVE-2021-26919 describes a similar vulnerability which was partially addressed in Apache Druid 0.20.2. This issue is fixed in Apache Druid 30.0.1.

Deserialization of Untrusted Data vulnerability in Apache Seata.  When developers disable authentication on the Seata-Server and do not use the Seata client SDK dependencies, they may construct uncontrolled serialized malicious requests by directly sending bytecode based on the Seata private protocol. This issue affects Apache Seata: 2.0.0, from 1.0.0 through 1.8.0. Users are recommended to upgrade to version 2.1.0/1.8.1, which fixes the issue.

Applications serving static resources through the functional web frameworks WebMvc.fn or WebFlux.fn are vulnerable to path traversal attacks. An attacker can craft malicious HTTP requests and obtain any file on the file system that is also accessible to the process in which the Spring application is running. Specifically, an application is vulnerable when both of the following are true: * the web application uses RouterFunctions to serve static resources * resource handling is explicitly configured with a FileSystemResource location However, malicious requests are blocked and rejected when any of the following is true: * the Spring Security HTTP Firewall https://docs.spring.io/spring-security/reference/servlet/exploits/firewall.html  is in use * the application runs on Tomcat or Jetty

### Impact The REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private. On a private wiki, this can be tested by accessing `/xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history`, if this shows the history of the main page then the installation is vulnerable. ### Patches This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1. ### Workarounds There aren't any known workarounds apart from upgrading to a fixed version. ### References * https://jira.xwiki.org/browse/XWIKI-22052 * https://github.com/xwiki/xwiki-platform/commit/9cbca9808300797c67779bb9a665d85cf9e3d4b8

An open redirect vulnerability was found in Keycloak. A specially crafted URL can be constructed where the `referrer` and `referrer_uri` parameters are made to trick a user to visit a malicious webpage. A trusted URL can trick users and automation into believing that the URL is safe, when, in fact, it redirects to a malicious server. This issue can result in a victim inadvertently trusting the destination of the redirect, potentially leading to a successful phishing attack or other types of attacks. Once a crafted URL is made, it can be sent to a Keycloak admin via email for example. This will trigger this vulnerability when the user visits the page and clicks the link. A malicious actor can use this to target users they know are Keycloak admins for further attacks. It may also be possible to bypass other domain-related security checks, such as supplying this as a OAuth redirect uri. The malicious actor can further obfuscate the `redirect_uri` using URL encoding, to hide the text of t...