Maven 3.8.1 blocks external repositories that use plain HTTP by default, because downloads over HTTP can be intercepted and altered. The release fixed two CVEs, CVE-2021-26291 and CVE-2020-13956. If your build broke after upgrading, the right fix is to move the repository to HTTPS.
What was the problem?
The release notes describe a report about custom repositories declared in dependency POMs. It was split into three issues.
The first was a possible man in the middle attack. Maven Central contains POMs that point at custom repositories over HTTP, and uploaded POMs are immutable, so the fix had to happen in Maven itself. A download over HTTP can be tampered with in transit, and developers often do not know a given download uses an insecure address.
The second was possible domain hijacking, where a POM refers to a repository on an abandoned domain. The notes say Sonatype analyzed which domains were abandoned and claimed them.
The third was possible hijacking of downloads by redirecting to custom repositories. The Maven team's analysis was that dependencies are only downloaded from repositories within their context, and that this is a design feature, not a bug.
What changed in the defaults?
Maven extended mirror configuration with a blocked parameter and added a new mirror selector, external:http:*, meaning any external URL using HTTP. The default conf/settings.xml now includes a mirror that blocks insecure external HTTP URLs.
The second CVE, CVE-2020-13956, concerned Apache HttpClient, a transitive dependency of Maven Resolver through Maven Wagon. Those versions were updated in the same release.
Why is it called 3.8.1 and not a patch release?
The release notes answer this. It is not just a bug fix. Three features change default behavior, so builds may fail if they use repositories that are now blocked. The team said to check and fix before upgrading. They did not choose 3.7.0 because that number had been promoted as the release with the build and consumer feature, which was renamed 4.0.0 instead, and reusing it would have caused confusion.
A constructed example
A team upgrades the build image from an older Maven to 3.8.1 and CI fails with a message that a repository was blocked. The cause is an old third party library whose POM lists an HTTP repository for a dependency. The team has three choices. They can override the mirror to allow HTTP, which brings back the original risk. They can ask the library maintainer to publish over HTTPS. Or they can host the needed artifact in their own repository manager over HTTPS and point to it. They choose the third, and add a rule that the repository manager is the only source builds may use.
How to check or apply this
- Check the Maven version in CI and on developer machines to see which Maven versions are in use.
- Upgrade to a current Maven release, not only 3.8.1, since later versions carry later fixes.
- When a build fails on a blocked repository, find which dependency declares it and look for an HTTPS address.
- Prefer a repository manager that mirrors everything, so builds do not reach out to arbitrary hosts.
- Do not disable the HTTP block globally. If you must make an exception, scope it to one repository and record why.
- Scan the resolved dependency tree for known vulnerabilities after upgrading.
Safeguard scans Java dependency trees and can gate pull requests on policy, which helps verify what a newly allowed repository actually brought in.
Quick check
Is it safe to disable the HTTP repository block?
It restores the exposure the release was built to remove. If you must, limit the exception to one repository and set a date to remove it.
Do I need 3.8.1 specifically?
3.8.1 is where the change began. Use a current supported Maven release, which includes it and later fixes.
Sources
Last reviewed: 18 October 2026.
