Same-GAV Maven patches are shadowed when a build plugin depends on the same GAV in a reactor build

[mikolalysenko]

[agent] Filed by Claude Code on behalf of Mikola Lysenko (@mikolalysenko) while adding Maven patch SBOM annotations to depscan. Reproduced with a release build of socket-patch 3efdc31d (sha256 dc5fb57f…), a stub patch API, and real Apache Maven 2.2.1 through 4.0.0-rc-7 (13 lines) on macOS arm64 / JDK 26.

Severity: medium for vendored and legacy same-GAV modes. This extends the existing vendor_maven_local_cache_shadow
advisory: the shadow can appear on a CLEAN CI machine, not only on a warm cache.

Observed in an earlier matrix iteration (commons-text 1.10.0 patch, 3.9.16, multimodule-modules × hosted-legacy,
evidence in this session's logs; the patch was then moved to commons-text 1.9 to keep the matrix clean):

• maven-dependency-plugin:3.6.1 itself depends on org.apache.commons:commons-text:1.10.0.
• In a two-module reactor, the plugin realm is set up while the first (pom-packaging) module builds. Maven then
  downloads Central's commons-text 1.10.0 into the local repository, from the plugin repositories, without asking
  the Socket or vendored repository.
• The second module then resolves the same GAV from the local repository and builds the pristine jar, exit 0.
• Fail-closed hosted mode is immune, because the suffixed version is a different GAV.
• Suggest: document it in the advisory ("a plugin or build extension that uses the same artifact can populate the
  local repository before your module resolves"), and treat it as one more reason to prefer fail-closed hosted.