Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -159,7 +159,7 @@ dependencies {
implementation 'info.picocli:picocli:4.7.7'
annotationProcessor 'info.picocli:picocli-codegen:4.7.7'
implementation 'io.quarkus.qute:qute-core:1.13.7.Final'
implementation 'org.codehaus.plexus:plexus-java:1.2.0'
implementation 'org.codehaus.plexus:plexus-java:1.5.2'
implementation 'com.google.code.gson:gson:2.13.2'
implementation 'org.jsoup:jsoup:1.17.1'
implementation 'org.codejive:java-properties:0.0.7'
Expand All @@ -170,7 +170,7 @@ dependencies {

implementation "eu.maveniverse.maven.mima:context:2.4.36"
runtimeOnly "eu.maveniverse.maven.mima.runtime:standalone-static:2.4.36"
implementation "org.apache.maven:maven-model:3.9.11"
implementation "org.apache.maven:maven-model:3.9.16"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Does CVE-2025-67030 affect org.apache.maven:maven-model and is it fixed in version 3.9.16?

💡 Result:

No clear evidence shows that CVE-2025-67030 directly affects the Apache Maven “maven-model” artifact (org.apache.maven:maven-model). The vulnerability described for CVE-2025-67030 is a directory traversal in org.codehaus.plexus.util.Expand (plexus-utils) in versions before the commit fix [1]. However, in practice, “maven-model” can be part of dependency trees that pull in plexus-utils (e.g., an example shows maven-model depending on plexus-utils:3.6.0 transitively) [2]. If your build uses a plexus-utils version in the vulnerable range via such transitive dependency, then you would be affected even if the flaw is in plexus-utils rather than maven-model itself [1][2]. Is it fixed in Maven Model 3.9.16? The sources available here do not state that org.apache.maven:maven-model:3.9.16 upgrades plexus-utils to a non-vulnerable version. They only identify the plexus-utils fix by commit 6d780b3378829318ba5c2d29547e0012d5b29642 / the vulnerable range “before 6d780b…” [1]. Community reports indicate plexus-utils versions like 4.0.2/4.0.3 are used to address CVE-2025-67030, and one example explicitly recommends upgrading maven-model so it pulls in plexus-utils >= 4.0.2 [2], but none of the retrieved sources confirm that 3.9.16 does that specific upgrade [2]. Bottom line: - CVE-2025-67030 is a plexus-utils (Expand.extractFile) issue [1], not a direct maven-model code issue. - You may still be exposed if your dependency resolution brings in a vulnerable plexus-utils version transitively through maven-model (shown in one example) [2]. - I cannot confirm from the provided authoritative sources that maven-model 3.9.16 is fixed for CVE-2025-67030; the fix depends on which plexus-utils version your build actually resolves [1]. Recommended check: - In the environment where you run Maven, inspect the resolved dependency graph for plexus-utils (e.g., mvn dependency:tree) and verify the plexus-utils version is not in the vulnerable range described by the CVE [1].

Citations:


🌐 Web query:

What is the latest version of org.apache.maven:maven-model and does version 3.9.16 exist?

💡 Result:

Latest version of org.apache.maven:maven-model: 3.9.16 (shown in the official Maven Model 3.9.16 dependency coordinates) [1][2]. Does version 3.9.16 exist? Yes—official Maven Model documentation for version 3.9.16 exists and includes the coordinates org.apache.maven:maven-model:3.9.16 [1].

Citations:


🏁 Script executed:

#!/bin/bash
# Description: Verify maven-model version 3.9.16 exists in Maven Central and check for API compatibility

# Check if version 3.9.16 exists in Maven Central
echo "Checking if maven-model version 3.9.16 exists in Maven Central..."
curl -sf "https://repo1.maven.org/maven2/org/apache/maven/maven-model/3.9.16/maven-model-3.9.16.pom" > /dev/null && echo "✓ Version 3.9.16 exists" || echo "✗ Version 3.9.16 not found"

# Check Maven Central for latest versions
echo -e "\nFetching available versions from Maven Central..."
curl -s "https://repo1.maven.org/maven2/org/apache/maven/maven-model/maven-metadata.xml" | grep -o '<version>[^<]*</version>' | sed 's/<[^>]*>//g' | tail -10

# Verify usage patterns in codebase are compatible
echo -e "\nVerifying Model class usage patterns in codebase..."
rg -n "org\.apache\.maven\.model\.Model" --type java -C2

Repository: jbangdev/jbang

Length of output: 840


Recheck the CVE-2025-67030 rationale for the maven-model version bump (build.gradle:173)

  • CVE-2025-67030 is reported as a plexus-utils/org.codehaus.plexus.util.Expand directory-traversal issue, not a direct org.apache.maven:maven-model code issue—upgrading to maven-model:3.9.16 only fixes it if your resolved dependency tree pulls in a non-vulnerable plexus-utils version transitively.
  • org.apache.maven:maven-model:3.9.16 exists in Maven Central.
  • Still need to check the resolved dependency graph for plexus-utils (to ensure the vulnerable range is eliminated) and confirm no API/binary compatibility breaks for the existing org.apache.maven.model.Model / org.apache.maven.model.io.xpp3.MavenXpp3Reader usage across 3.9.113.9.16.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@build.gradle` at line 173, The maven-model version bump to
org.apache.maven:maven-model:3.9.16 alone may not eliminate CVE-2025-67030
because the vulnerability is in plexus-utils; run your build's dependency
resolution (e.g., Gradle dependencyInsight/dependencies) to verify which
org.codehaus.plexus:plexus-utils version is actually resolved and ensure it is
outside the vulnerable range, and if it isn’t, add a direct dependency or a
dependencyConstraint/force for plexus-utils to a fixed safe version; then
compile and run tests to confirm there are no API/binary compatibility breaks
for usages of org.apache.maven.model.Model and
org.apache.maven.model.io.xpp3.MavenXpp3Reader when moving from 3.9.11 to 3.9.16
(or adjust to a different mitigation if incompatibilities are found).


implementation "org.jline:jline-console-ui:$jlineVersion"
implementation "org.jline:jline-terminal-jni:$jlineVersion"
Expand Down
Loading