Pulling in old vulnerable version of maven-core

[johanblumenberg]

Precondition

• I checked the issues list for existing open or closed reports of the same problem.

Describe the bug

dependency-check-maven contains a compile dependency to org.apache.maven.shared:maven-artifact-transfer:0.13.1 which contains a compile dependency to org.apache.maven:maven-core.
dependency-check-maven contains a provided dependency to org.apache.maven:maven-core:3.6.3.
This means that dependency-check-maven will pull in org.apache.maven:maven-core:3.6.3 as a compile dependency.

org.apache.maven:maven-core:3.6.3 contains the critical vulnerability CVE-2021-26291: https://mvnrepository.com/artifact/org.apache.maven/maven-core/3.6.3

The recommendation is to have a provided dependency to maven-core, not compile, and the org.apache.maven.shared:maven-artifact-transfer artifact is deprecated.

Version of dependency-check used
The problem occurs using version 12.1.0 of the maven plugin.

Log file
N/A

To Reproduce
Steps to reproduce the behavior:

1. Create a simple project containing dependency-check-maven, like this: https://gist.github.com/johanblumenberg/72d74aa8520292e1fb220a06de1490af
2. Run mvn verify
3. Open target/dependency-check-report.html and check the critical items reported.

Expected behavior

No critical vulnerabilities coming from the dependency-check-maven plugin itself.

Additional context

N/A

[aikebah]

It does not drag in the library at compile scope, but at provided scope as can be observed when running mvn dependency:tree -Dincludes=org.apache.maven on the maven plugin:

1387 [main] [INFO] org.apache.maven.cli.event.ExecutionEventLogger - --- dependency:3.8.1:tree (default-cli) @ dependency-check-maven ---
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - org.owasp:dependency-check-maven:maven-plugin:12.1.1-SNAPSHOT
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - +- org.apache.maven:maven-plugin-api:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - +- org.apache.maven:maven-settings:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - +- org.apache.maven:maven-core:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - |  +- org.apache.maven:maven-builder-support:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - |  +- org.apache.maven:maven-repository-metadata:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - |  +- org.apache.maven:maven-model-builder:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - |  \- org.apache.maven:maven-resolver-provider:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - +- org.apache.maven:maven-settings-builder:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - +- org.apache.maven:maven-model:jar:3.6.3:provided
1690 [main] [INFO] org.apache.maven.plugins.dependency.tree.TreeMojo - \- org.apache.maven:maven-artifact:jar:3.6.3:provided

The maven dependencies are dependency-managed at version 3.6.3 in order to avoid any risk of using post-3.6.3 new maven API, thereby breaking our claim of Maven 3.6.3+ compatibility. The plugin will (because of this provided scope) use the maven libraries of the maven install that runs the plugin.

[aikebah]

What your project is surfacing is a potential bug in the plugin dependencies scope evaluation, or a scope override for maven-core by another part of your project.

[bjansen]

@chadlwilson may I ask why you closed the issue? Its title might be badly worded, I don't believe @johanblumenberg wants you to upgrade the version of maven-core you use. They are just observing that on an empty pom with no plugins other than dependency-check, and with a Maven runtime in version 3.9.9, dependency-check flags itself as vulnerable because even though maven-core has a provided scope, version 3.6.3 is analyzed and appears in the HTML output file:

[chadlwilson]

Ok, was probably a bit hasty. Perhaps misinterpreted what aikebah and OP were saying. OP didn't respond.

FWIW this project gets vast amounts of noise and I don't think anyone has the time to be second guessing over multiple interactions. Having hundreds of open issues doesn't get any of them resolved 😓

[johanblumenberg]

Thank you for reopening this issue.

Indeed, the dependency to maven-core is supposed to have the provided scope, since the pom in the dependency-check plugin has set it to provided.

But when executing the plugin, it is clearly downloading maven-core:3.6.3.

Here I am removing maven-core and plexus-utils from the local repository to see what is being downloaded. I am comparing with plexus-core since that is a compile dependency, and should for sure be downloaded before the plugin executes.

$ rm -rf ~/.m2/repository/org/apache/maven/maven-core
$ rm -rf ~/.m2/repository/org/codehaus/plexus/plexus-utils/

$ mvn verify                                               
[INFO] Scanning for projects...
[INFO] 
[INFO] -----------------------< com.test:root-project >------------------------
[INFO] Building root-project 0.0.1-SNAPSHOT
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- dependency-check-maven:12.1.0:aggregate (default) @ root-project ---
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.2/plexus-utils-4.0.2.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.2/plexus-utils-4.0.2.pom (13 kB at 78 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-core/3.6.3/maven-core-3.6.3.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-core/3.6.3/maven-core-3.6.3.pom (8.8 kB at 630 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.2/plexus-utils-4.0.2.jar
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-core/3.6.3/maven-core-3.6.3.jar
Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.2/plexus-utils-4.0.2.jar (193 kB at 5.1 MB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-core/3.6.3/maven-core-3.6.3.jar (633 kB at 8.7 MB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.1/plexus-utils-4.0.1.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.1/plexus-utils-4.0.1.pom (7.8 kB at 373 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.1/plexus-utils-4.0.1.jar
Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/4.0.1/plexus-utils-4.0.1.jar (193 kB at 10 MB/s)
[INFO] Checking for updates
[INFO] Skipping the NVD API Update as it was completed within the last 240 minutes
[INFO] Skipping Known Exploited Vulnerabilities update check since last check was within 24 hours.
[INFO] Check for updates complete (169 ms)
[INFO] 

However, it looks like maven-core:3.6.3 is never being executed. The plugin has no problems executing, but when analyzing maven-core:3.6.3 it cannot open the jar file.

$ echo "" > ~/.m2/repository/org/apache/maven/maven-core/3.6.3/maven-core-3.6.3.jar

$ mvn verify                                               
[INFO] Scanning for projects...
[INFO] 
[INFO] -----------------------< com.test:root-project >------------------------
[INFO] Building root-project 0.0.1-SNAPSHOT
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- dependency-check-maven:12.1.0:aggregate (default) @ root-project ---
[INFO] Checking for updates
[INFO] Skipping the NVD API Update as it was completed within the last 240 minutes
[INFO] Skipping Known Exploited Vulnerabilities update check since last check was within 24 hours.
[INFO] Check for updates complete (189 ms)
[INFO] 

Dependency-Check is an open source tool performing a best effort analysis of 3rd party dependencies; false positives and false negatives may exist in the analysis performed by the tool. Use of the tool and the reporting provided constitutes acceptance for use in an AS IS condition, and there are NO warranties, implied or otherwise, with regard to the analysis or its use. Any use of the tool and the reporting provided is at the user's risk. In no event shall the copyright holder or OWASP be held liable for any damages whatsoever arising out of or in connection with the use of this tool, the analysis performed, or the resulting report.


   About ODC: https://jeremylong.github.io/DependencyCheck/general/internals.html
   False Positives: https://jeremylong.github.io/DependencyCheck/general/suppression.html

💖 Sponsor: https://github.com/sponsors/jeremylong


[INFO] Analysis Started
[INFO] Finished Archive Analyzer (0 seconds)
[INFO] Finished File Name Analyzer (0 seconds)
[WARNING] Unable to open jar file 'maven-core-3.6.3.jar'.

[jeremylong]

It cannot open the jar file in your last example because you overwrote it with an empty string:

echo "" > ~/.m2/repository/org/apache/maven/maven-core/3.6.3/maven-core-3.6.3.jar

[jeremylong]

I decided to ask ChatGPT o4 and received a really interesting explanation:

---

Yes, this behavior is subtle but understandable when you dig into how Maven resolves plugin dependencies and interprets the provided scope in the context of plugins, which differs from how it works for application dependencies.

💡 TL;DR:

Even though you've declared maven-core as provided, Maven resolves the plugin's dependencies based on what's declared in its pom.xml, not based on the runtime Maven version—because plugin dependencies are resolved from the plugin's POM metadata, not the Maven runtime classpath.

🧩 Explanation

1. Scope provided for maven-core in a plugin POM:

   The provided scope means: "this dependency is needed to compile the plugin but will be provided at runtime". In theory, this tells Maven not to package or resolve it during plugin execution, because it's assumed to be present in the environment (e.g., the running Maven instance).

2. But during dependency:resolve-plugins:

   The dependency:resolve-plugins goal analyzes the plugin’s POM and resolves all dependencies (even provided ones) to determine what would be required if the plugin were run in isolation.

   Thus, even provided dependencies are listed—because the plugin POM explicitly names maven-core with version 3.6.1.

3. Why 3.6.1 shows up:

   Maven doesn't automatically align the provided dependency version with the version of Maven running the build.

   If your plugin declares maven-core version 3.6.1, even with scope provided, Maven sees that version as part of the plugin metadata and includes it when listing dependencies via dependency:resolve-plugins.

4. At runtime (actual plugin execution):

   The Maven runtime provides its own version of maven-core, which overrides any provided dependency from the plugin. So even though resolve-plugins shows 3.6.1, at actual execution, it uses the Maven runtime’s maven-core.

✅ How to avoid confusion

If your goal is to:

• Avoid locking the plugin to a specific Maven version,
• Signal that the plugin should work with whichever Maven version is executing the build,

Then you have a few options:

1. Omit maven-core entirely
   If you only use Maven API classes that are guaranteed to exist in the runtime, you don’t need to declare maven-core at all. The Maven runtime will always provide it.

2. Use Maven's provided BOM
   If you must compile against Maven core APIs, you can optionally use a Maven BOM or property to match the runtime Maven version used in your build environment (but this only helps within your own builds, not plugin consumers).

3. Document compatibility, don’t lock versions
   Simply omit the or at least avoid declaring an old one like 3.6.1—otherwise, it gives the false impression that your plugin is pinned to that version.

🔎 Summary

• Maven resolves plugin dependencies strictly based on the plugin's POM.
• scope=provided doesn't stop the dependency from showing up in tools like dependency:resolve-plugins.
• Actual plugin execution uses the Maven runtime’s maven-core, regardless of what’s declared in the plugin POM.
• Declaring a specific version like 3.6.1 gives misleading signals unless you’re actively targeting that version.

[chadlwilson]

As to the "root cause" here, when scanning Maven plugins, I don't think the current logic has the ability to apply the normal skipProvidedScope exclusions (or other exclusions) that can be applied to regular dependencies?

DependencyCheck/maven/src/main/java/org/owasp/dependencycheck/maven/BaseDependencyCheckMojo.java

Lines 1398 to 1436 in 91ffcf6

	protected ExceptionCollection scanPlugins(MavenProject project, Engine engine, ExceptionCollection exCollection) {
	ExceptionCollection exCol = exCollection;
	final Set<Artifact> plugins = new HashSet<>();
	final Set<Artifact> buildPlugins = getProject().getPluginArtifacts();
	final Set<Artifact> reportPlugins = getProject().getReportArtifacts();
	final Set<Artifact> extensions = getProject().getExtensionArtifacts();
	plugins.addAll(buildPlugins);
	plugins.addAll(reportPlugins);
	plugins.addAll(extensions);
	final ProjectBuildingRequest buildingRequest = newResolveArtifactProjectBuildingRequest(project, project.getPluginArtifactRepositories());
	for (Artifact plugin : plugins) {
	try {
	final Artifact resolved = artifactResolver.resolveArtifact(buildingRequest, plugin).getArtifact();
	exCol = addPluginToDependencies(project, engine, resolved, "pom.xml (plugins)", exCol);
	final DefaultDependableCoordinate pluginCoordinate = new DefaultDependableCoordinate();
	pluginCoordinate.setGroupId(resolved.getGroupId());
	pluginCoordinate.setArtifactId(resolved.getArtifactId());
	pluginCoordinate.setVersion(resolved.getVersion());
	final String parent = buildReference(resolved.getGroupId(), resolved.getArtifactId(), resolved.getVersion());
	for (Artifact artifact : resolveArtifactDependencies(pluginCoordinate, project)) {
	exCol = addPluginToDependencies(project, engine, artifact, parent, exCol);
	}
	} catch (ArtifactResolverException ex) {
	throw new RuntimeException(ex);
	} catch (IllegalArgumentException ex) {
	throw new RuntimeException(ex);
	} catch (DependencyResolverException ex) {
	throw new RuntimeException(ex);
	}
	}
	return null;
	}

[jeremylong]

After doing some more testing - I'm positive ChatGPT's answer is correct. In a sample project I ran mvn dependency:resolve-plugins:

[INFO] The following plugins have been resolved:
[INFO]    org.owasp:dependency-check-maven:maven-plugin:12.1.2-SNAPSHOT:runtime
[INFO]       org.owasp:dependency-check-maven:jar:12.1.2-SNAPSHOT
[INFO]       org.owasp:dependency-check-core:jar:12.1.2-SNAPSHOT
...
[INFO]       org.apache.maven.shared:maven-artifact-transfer:jar:0.13.1
[INFO]       org.apache.maven:maven-core:jar:3.6.3
[INFO]       org.apache.maven:maven-model:jar:3.6.3
...
[INFO]    org.apache.maven.plugins:maven-site-plugin:maven-plugin:3.12.1:runtime
...
[INFO]       org.apache.maven:maven-artifact:jar:3.2.5
[INFO]       org.apache.maven:maven-core:jar:3.2.5

You'll see that when we resolve the plugin's dependencies the tree has two different versions of maven-core listed. Unlike what happens with the standard dependencies where it would select one.

[jeremylong]

@chadlwilson we can get the scope by calling getScope() on the artifacts retrieved. Maybe we can denote in the report the provided plugin dependencies?

Maybe the best option would be to add a skipProvidedPluginDependencies option that defaults to true.

[chadlwilson]

If that provided metadata is still there in the Artifact as returned by the API it may still be possible to filter that version, I suppose.

[johanblumenberg]

It cannot open the jar file in your last example because you overwrote it with an empty string:

Exactly. The point was to see if the jar file is executed when executing the plugin.
If I overwrite the jar file and the plugin still executes fine, then either it is not used, or I did not invoke a usecase that calls that jar file. If it would fail to execute, that would prove that the jar file is used in some way.

[johanblumenberg]

I tried to log the classpath of the plugin when executing. According to https://maven.apache.org/guides/mini/guide-maven-classloading.html#Plugin_Classloaders:

Plugins can inspect their effective runtime class path via the expressions ${plugin.artifacts} or ${plugin.artifactMap} to have a list or map, respectively, of resolved artifacts injected from the PluginDescriptor.

I get this list of artifacts, which incudes maven-core:3.6.3:

org.owasp:dependency-check-maven:12.1.2-SNAPSHOT
org.owasp:dependency-check-core:12.1.2-SNAPSHOT
org.anarres.jdiagnostics:jdiagnostics:1.0.7
org.whitesource:pecoff4j:0.0.2.1
org.apache.commons:commons-jcs3-core:3.2.1
us.springett:cpe-parser:3.0.0
org.semver4j:semver4j:5.6.0
org.slf4j:slf4j-api:1.7.36
org.apache.commons:commons-collections4:4.4
org.apache.commons:commons-compress:1.27.1
commons-codec:commons-codec:1.18.0
commons-io:commons-io:2.18.0
org.apache.commons:commons-text:1.13.0
org.apache.commons:commons-dbcp2:2.13.0
org.apache.commons:commons-pool2:2.12.0
commons-logging:commons-logging:1.3.4
jakarta.transaction:jakarta.transaction-api:1.3.3
org.apache.lucene:lucene-core:9.12.0
org.apache.lucene:lucene-analysis-common:9.12.0
org.apache.lucene:lucene-queryparser:9.12.0
org.apache.lucene:lucene-queries:9.12.0
org.apache.lucene:lucene-sandbox:9.12.0
org.apache.lucene:lucene-facet:9.12.0
org.apache.velocity:velocity-engine-core:2.4.1
com.h2database:h2:2.3.232
org.glassfish:jakarta.json:2.0.1
org.jsoup:jsoup:1.19.1
com.fasterxml.jackson.core:jackson-databind:2.18.3
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.18.3
com.fasterxml.jackson.module:jackson-module-blackbird:2.18.3
com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.18.3
org.yaml:snakeyaml:2.3
com.h3xstream.retirejs:retirejs-core:3.0.4
com.github.spullara.mustache.java:compiler:0.9.6
org.sonatype.ossindex:ossindex-service-client:1.8.2
javax.inject:javax.inject:1
com.google.code.gson:gson:2.9.0
javax.xml.bind:jaxb-api:2.3.1
javax.activation:javax.activation-api:1.2.0
com.google.guava:guava:33.4.6-jre
com.google.guava:failureaccess:1.0.3
com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava
com.google.errorprone:error_prone_annotations:2.36.0
com.google.j2objc:j2objc-annotations:3.0.0
com.moandjiezana.toml:toml4j:0.7.2
com.hankcs:aho-corasick-double-array-trie:1.2.3
commons-validator:commons-validator:1.9.0
commons-beanutils:commons-beanutils:1.9.4
commons-digester:commons-digester:2.1
commons-collections:commons-collections:3.2.2
org.eclipse.packager:packager-rpm:0.21.0
org.eclipse.packager:packager-core:0.21.0
org.bouncycastle:bcprov-jdk18on:1.78
org.bouncycastle:bcpg-jdk18on:1.78
org.tukaani:xz:1.9
org.apache.httpcomponents.core5:httpcore5:5.3.4
org.apache.httpcomponents.client5:httpclient5:5.4.3
org.apache.httpcomponents.core5:httpcore5-h2:5.3.4
com.fasterxml.jackson.core:jackson-core:2.18.3
com.fasterxml.jackson.core:jackson-annotations:2.18.3
org.sonatype.goodies:package-url-java:1.2.0
joda-time:joda-time:2.14.0
org.sonatype.ossindex:ossindex-service-api:1.8.2
javax.ws.rs:javax.ws.rs-api:2.0.1
com.esotericsoftware:minlog:1.3.1
com.vaadin.external.google:android-json:0.0.20131108.vaadin1
org.owasp:dependency-check-utils:12.1.2-SNAPSHOT
io.github.jeremylong:jcs3-slf4j:1.0.5
org.apache.maven.doxia:doxia-sink-api:2.0.0
org.apache.maven.shared:file-management:3.1.0
org.codehaus.plexus:plexus-utils:4.0.2
org.codehaus.plexus:plexus-xml:3.0.1
org.apache.maven.reporting:maven-reporting-api:4.0.0
org.apache.maven.shared:maven-dependency-tree:3.3.0
org.apache.maven.resolver:maven-resolver-util:1.4.1
org.apache.maven.resolver:maven-resolver-api:1.4.1
org.apache.maven.shared:maven-artifact-transfer:0.13.1
org.apache.maven:maven-core:3.6.3
org.apache.maven:maven-settings:3.6.3
org.codehaus.plexus:plexus-interpolation:1.25
org.apache.maven:maven-builder-support:3.6.3
org.apache.maven:maven-repository-metadata:3.6.3
org.apache.maven:maven-plugin-api:3.6.3
org.apache.maven:maven-model-builder:3.6.3
org.apache.maven:maven-resolver-provider:3.6.3
org.apache.maven.resolver:maven-resolver-impl:1.4.1
org.apache.maven.resolver:maven-resolver-spi:1.4.1
org.apache.maven.shared:maven-shared-utils:3.4.2
org.eclipse.sisu:org.eclipse.sisu.plexus:0.3.4
javax.enterprise:cdi-api:1.0
javax.annotation:jsr250-api:1.0
org.eclipse.sisu:org.eclipse.sisu.inject:0.3.4
com.google.inject:guice:4.2.1
aopalliance:aopalliance:1.0
org.codehaus.plexus:plexus-classworlds:2.6.0
org.codehaus.plexus:plexus-component-annotations:2.1.0
org.apache.maven.shared:maven-common-artifact-filters:3.4.0
org.apache.commons:commons-lang3:3.17.0
io.github.jeremylong:open-vulnerability-clients:7.3.2
org.jspecify:jspecify:1.0.0
org.apache.httpcomponents.client5:httpclient5-cache:5.4.3
com.samskivert:jmustache:1.16
com.github.package-url:packageurl-java:1.5.0
org.jetbrains:annotations:26.0.2
com.github.spotbugs:spotbugs-annotations:4.9.3
com.google.code.findbugs:jsr305:3.0.2

[johanblumenberg]

Regarding the idea to use skipProvidedScope or other flags to tweak what the dependency check is reporting:

• This is not only about solving this particular case, where the dependency-check maven plugin has a dependency to maven-core. This will affect how vulnerabilities are reported for every existing plugin and every possible corner case of weird dependency chains.
• To implement this behaviour, you need to be really, really, really sure that these artifacts are only downloaded but never executed. If there is any case where they are actually executed, this would hide vulnerabilities from the user.
• Since the maven-core artifact is actually downloaded during the execution of the plugin, I would very much want this to be reported, regardless of if it is ever executed or not.

Considering this, I think it would be a lot more safe to update the dependency-check plugin not to depend on vulnerable artifacts.