Maven 3.8.1 blocks external repositories that use plain HTTP, because downloads over HTTP can be intercepted and altered. The fix is to use an HTTPS URL for the repository, usually through your internal repository manager. Loosening the block is possible but trades away the protection.
What changed in 3.8.1
The Maven 3.8.1 release notes cover two CVEs, including CVE-2021-26291. The report concerned custom repositories declared in dependency POMs. Maven Central contains POMs that refer to repositories over HTTP, which makes downloads through those repositories a target for man in the middle attacks. Developers are often unaware that some downloads use an insecure URL.
Because POMs uploaded to Central are immutable, the POMs could not simply be fixed. The Maven team changed Maven instead. They extended mirror configuration with a blocked parameter, added a mirror selector for external HTTP URLs, and blocked such repositories by default through a mirror in conf/settings.xml.
The notes also cover two related issues: abandoned domains in custom repositories (Sonatype analyzed which domains were abandoned and claimed them) and possible redirection of downloads to custom repositories, which the team explained is by design, since repositories are only used within their dependency context.
What the error looks like
You will see a build failure saying a repository was blocked by a mirror, naming the repository id and an http URL. It can come from your own POM or from a dependency's POM several levels down.
How to fix it
- Read the error to find the repository id and URL, and which POM declares it.
- If it is yours, change the URL to https. Many hosts support it today.
- If a dependency's POM declares it, check whether the artifact is on Central or in your internal repository manager. Often you do not need the extra repository at all.
- Best, route everything through one internal repository manager over HTTPS. Maven's mirror guide describes setting mirrorOf to an asterisk so all requests go to that mirror. See how to force every Maven build through one internal repository.
- Rebuild and confirm the failure is gone.
What not to do
| Tempting move | Why to avoid it |
|---|---|
| Delete the blocking mirror from settings | Removes the protection for every project on that machine |
| Switch to an http mirror you control | Same interception risk on the internal network path |
| Add the repository to a global allowlist without review | You still trust whatever that host serves |
If you truly must reach an HTTP only host, such as a lab system, scope the exception narrowly to that repository id and document why.
Why it still matters today
The core lesson reaches beyond one CVE. Every extra repository your build can reach is another place where an artifact could come from. Fewer repositories, all over HTTPS, mean a shorter list of things to trust. Our earlier write up on the Maven HTTP repository CVE covers the vulnerability itself.
Safeguard dependency scanning reports on the libraries your build resolves, and its policies and gates can fail a pull request when a finding crosses your threshold. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is it safe to use Maven older than 3.8.1?
Older versions do not block HTTP repositories by default, so downloads through them are exposed to interception. Upgrading Maven is the simplest fix, and the release notes list the details.
Why did the Maven team not just fix the POMs on Central?
Published POMs are immutable, so they cannot be edited after the fact. Changing Maven's behavior was the available route.
Sources
- Maven 3.8.1 release notes
- Using Mirrors for Repositories, Apache Maven
- Immutability of Published Components, Sonatype Central documentation
Last reviewed: 19 October 2026.
