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.

Jenkins Pipeline Maven Integration Plugin 1330.v18e473854496 and earlier does not properly mask (i.e., replace with asterisks) usernames of credentials specified in custom Maven settings in Pipeline build logs if "Treat username as secret" is checked.

Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin 1.14 and earlier does not set the appropriate context for credentials lookup, allowing attackers with Item/Configure permission to access and capture credentials they are not entitled to.

Jenkins Maven Repository Server Plugin 1.10 and earlier does not escape project and build display names on the Build Artifacts As Maven Repository page, resulting in a stored cross-site scripting (XSS) vulnerability.

Jenkins Maven Repository Server Plugin 1.10 and earlier does not escape the versions of build artifacts on the Build Artifacts As Maven Repository page, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to control maven project versions in `pom.xml`.

The package snyk before 1.1064.0; the package snyk-mvn-plugin before 2.31.3; the package snyk-gradle-plugin before 3.24.5; the package @snyk/snyk-cocoapods-plugin before 2.5.3; the package snyk-sbt-plugin before 2.16.2; the package snyk-python-plugin before 1.24.2; the package snyk-docker-plugin before 5.6.5; the package @snyk/snyk-hex-plugin before 1.1.6 are vulnerable to Command Injection due to an incomplete fix for [CVE-2022-40764](https://security.snyk.io/vuln/SNYK-JS-SNYK-3037342). A successful exploit allows attackers to run arbitrary commands on the host system where the Snyk CLI is installed by passing in crafted command line flags. In order to exploit this vulnerability, a user would have to execute the snyk test command on untrusted files. In most cases, an attacker positioned to control the command line arguments to the Snyk CLI would already be positioned to execute arbitrary commands. However, this could be abused in specific scenarios, such as continuous integration pip…

Jenkins Maven Metadata Plugin for Jenkins CI server Plugin 2.2 and earlier does not perform URL validation for the Repository Base URL of List maven artifact versions parameters, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

Jenkins Maven Metadata Plugin for Jenkins CI server Plugin 2.1 and earlier does not escape the name and description of List maven artifact versions parameters on views displaying parameters, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

In Apache Maven maven-shared-utils prior to version 3.3.3, the Commandline class can emit double-quoted strings without proper escaping, allowing shell injection attacks.

Apache Maven will follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository. Maven is changing the default behavior in 3.8.1+ to no longer follow http (non-SSL) repository references by default. More details available in the referenced urls. If you are currently using a repository manager to govern the repositories used by your builds, you are unaffected by the risks present in the legacy behavior, and are unaffected by this vulnerability and change to default behavior. See this link for more information about repository management: https://maven.apache.org/repository-management.html