Apache Maven's Insecure HTTP Repository Resolution Enabli...

CVE-2021-26291 is a vulnerability in Apache Maven, the dependency-management and build automation tool used by the overwhelming majority of Java projects, that allowed a network-positioned attacker to tamper with artifact resolution and inject malicious code into a build. The root cause was deceptively simple: Maven would follow repository and mirror definitions declared inside a dependency's own pom.xml, including definitions that pointed at plain http:// endpoints. Because HTTP traffic is unauthenticated and unencrypted, anyone able to sit between a developer's machine (or a CI runner) and the internet — a hostile Wi-Fi network, a compromised upstream proxy, or DNS hijacking of an expired repository host — could intercept that request and substitute their own JAR in place of a legitimate dependency. The result is a textbook man-in-the-middle (MITM) supply chain attack: the victim's build tool asks for library.jar, and the attacker hands back library.jar with a backdoor stitched in.

What made this more than an academic concern is where the insecure references lived. Maven Central artifacts are immutable once published, so the tens of thousands of older POMs that hard-coded http:// repository or mirror URLs (legacy JBoss, Codehaus, and other now-defunct or since-migrated hosts) could never be edited after the fact. Every downstream project that pulled in one of those poisoned dependency trees inherited the same insecure resolution path — transitively, and usually without the development team ever noticing. Security researchers at Mend later scanned Maven Central and found the issue's fingerprints across roughly 100,000 libraries, with around a quarter of scanned artifacts still carrying an insecure repository reference well after a fix was available.

CVE-2021-26291 Root Cause: Insecure Artifact Resolution in a Java Build Tool

At its core, CVE-2021-26291 is an origin validation error (CWE-346). Maven's dependency resolution logic is designed to be extensible — a project or one of its transitive dependencies can declare additional <repositories> and <mirrors> in its POM, and Maven will honor them when resolving artifacts that aren't already available from the repositories the top-level build explicitly configured. Before the fix, Maven placed no restriction on the protocol used by those declarations. An http:// repository was trusted exactly the same as an https:// one.

That trust model collapses under a MITM scenario. HTTP gives an attacker on the network path everything they need: visibility into the request (so they know exactly which artifact, group, and version is being requested) and the ability to rewrite the response before it reaches the Maven client. Since build tools like Maven routinely execute plugin code, run annotation processors, and unpack resources as part of the build lifecycle — and the resolved artifacts frequently end up bundled into the shipped application — a single poisoned dependency can translate directly into arbitrary code execution on a developer's workstation, on a CI/CD build agent, or in the hands of anyone who later runs the compromised software. This is precisely the class of risk that makes software supply chain security a build-time concern, not just a runtime one.

Affected Versions and Components

• Affected: Apache Maven 3.6.3 and all earlier releases (effectively every Maven version prior to the fix).
• Fixed in: Apache Maven 3.8.1, released April 4, 2021.
• Affected artifacts: org.apache.maven:maven-core and org.apache.maven:maven-compat, the modules responsible for Maven's dependency and repository resolution logic.
• Not directly affected: Organizations that route all Maven traffic through an internal repository manager (Nexus, Artifactory, or similar) acting as the sole upstream, since the build client never talks to the internet-facing repositories directly. That said, the repository manager itself still needs to be configured to reject upstream HTTP proxying to fully close the gap.

The vulnerability sits in Maven itself rather than in any single library, which is why its blast radius is described in terms of "libraries affected" rather than a specific CVE-vulnerable package: any project resolving dependencies with a pre-3.8.1 Maven client was exposed, regardless of which artifacts it consumed.

CVSS and Exploitability Context

NVD scores CVE-2021-26291 as 9.1 (Critical) under CVSS v3.1, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — reflecting a network attack vector, low attack complexity, no privileges or user interaction required, and high impact to confidentiality and integrity. It's worth noting that other vendor feeds score it more conservatively: Snyk rates it around 7.1 and Red Hat around 7.4 (both High rather than Critical), largely because their scoring accounts for the practical precondition that an attacker must first achieve a man-in-the-middle position on the network path — a nontrivial but far from rare capability on shared Wi-Fi, misconfigured corporate proxies, or compromised transit infrastructure.

GitHub's Advisory Database has historically listed an EPSS score in the high single digits (roughly the 94th percentile among scored CVEs), indicating meaningful but not extreme observed exploitation signal relative to the broader CVE population. As of this writing, CVE-2021-26291 has not been added to CISA's Known Exploited Vulnerabilities catalog, which tracks CVEs with confirmed in-the-wild exploitation — consistent with the fact that this bug is exploited opportunistically via network position rather than through a scalable, internet-facing attack surface. That distinction matters for prioritization, but it shouldn't be mistaken for low risk: MITM conditions are easy to manufacture on purpose (open Wi-Fi at a conference, a compromised coffee-shop router, a rogue VPN exit node) and any CI environment that egresses through shared or third-party infrastructure carries some exposure.

Timeline

• Pre-2021: Maven's default and inherited repository configuration permits resolution over plain HTTP; numerous legacy POMs in Maven Central carry immutable http:// repository and mirror references.
• April 4, 2021: Apache releases Maven 3.8.1, which changes the default behavior to block external HTTP repository resolution.
• April 23, 2021: NVD publishes CVE-2021-26291, formally documenting the origin validation error and assigning it a Critical severity rating.
• Following months: Downstream advisories propagate across the ecosystem — GitHub Security Advisories, Red Hat, SUSE, Debian, IBM, and Oracle Critical Patch Updates all publish their own entries, since Maven's bundling in countless products (application servers, CI images, IDE tooling, data integration platforms) meant the fix had to ripple outward through many separate release trains.
• Ongoing: Security research firms including Mend continued to find substantial numbers of Maven Central libraries still shipping unpatched or unremediated HTTP repository references long after the fix shipped, underscoring how slowly build-tool-level fixes propagate through a dependency graph that nobody re-audits once it's "working."

Remediation Steps

1. Upgrade Maven to 3.8.1 or later on every developer workstation, CI/CD runner, and build container. This is the primary fix — Maven's default conf/settings.xml now includes a mirror entry that blocks any external:http:* repository unless explicitly allowed.
2. Audit your POMs and settings.xml for hard-coded http:// repository or mirror URLs, including ones inherited from parent POMs or transitive dependencies. Replace them with https:// equivalents or remove them if the host is no longer active.
3. Route all artifact resolution through a trusted internal repository manager (Nexus Repository, JFrog Artifactory, etc.) rather than letting build agents resolve directly from public or legacy hosts. Configure the repository manager itself to reject HTTP-only upstreams.
4. Enforce checksum and signature verification for resolved artifacts where your tooling supports it, so that even an unexpected repository substitution is more likely to be caught before the artifact is used.
5. Re-scan previously built dependency trees, not just new builds — since older, cached, or vendored artifacts resolved under a pre-3.8.1 Maven client could already reflect a compromised state if an attack occurred before the upgrade.
6. Restrict and monitor network egress from CI/CD environments so that build agents can't be trivially placed behind an attacker-controlled proxy or DNS resolver in the first place.

How Safeguard Helps

CVE-2021-26291 is a reminder that software supply chain risk doesn't only live in the packages you depend on — it lives in the build tool that fetches them. A perfectly reputable dependency can still be substituted for something malicious if the artifact resolution path underneath it isn't trustworthy. That's exactly the class of risk Safeguard is built to surface.

Safeguard continuously inventories the build tooling, Java build tool versions, and repository configurations across your codebases and CI/CD pipelines, flagging outdated Apache Maven installations, insecure or legacy http:// repository and mirror declarations, and CI environments that resolve artifacts without going through a governed repository manager. Rather than waiting for a quarterly audit to catch a stale settings.xml or a forgotten parent POM with a decade-old HTTP mirror, Safeguard's software composition analysis maps these conditions back to known CVEs like CVE-2021-26291, prioritizes them using real-world exploitability context (not CVSS score alone), and routes actionable remediation guidance to the teams that own the affected builds. For organizations securing complex, polyglot software supply chains, that means catching the build-time equivalent of an unlocked door before it becomes the entry point for a MITM code injection incident.