Maven blocks external repositories that use plain HTTP, so a dependency POM that points at an http URL fails with a Blocked mirror error. Fix it by upgrading the dependency, changing your own POM to https, or mapping that repository id to an https mirror. Do not turn the blocker off.
What the message looks like
Could not transfer artifact ... from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [blocked-repository-id (http://blocked.repository.org, default, releases+snapshots)]
Why Maven does this
The 3.8.1 release notes explain that the block is a default mirror in conf/settings.xml named maven-default-http-blocker, using the external:http:* selector. It was added because HTTP repositories declared inside dependency POMs open the door to a man-in-the-middle attack. The release notes reference CVE-2021-26291. Because POMs already published to Maven Central are immutable, Maven had to enforce the rule on the client.
In plain terms: if a download travels over HTTP, someone on the network path could swap the artifact. The block closes that route.
How to fix it
| Where is the http URL? | Fix |
|---|---|
| In your own pom.xml | Change it to https in source |
| In a dependency's POM | Upgrade that dependency to a version with an https URL |
| In a dependency's POM and no upgrade exists | Add a mirror in settings.xml for that repository id pointing to an https URL |
The mirror sketch from the release notes pattern:
<mirrors>
<mirror>
<id>blocked-repo-https</id>
<mirrorOf>blocked-repository-id</mirrorOf>
<url>https://blocked.repository.org</url>
</mirror>
</mirrors>
Replace the id and URL with yours, and check that the https endpoint really serves that repository. Mirror wildcards have traps of their own, see Maven mirrorOf wildcards.
What not to do
- Do not override the blocker with a mirror that points back to an http URL.
- Do not copy a settings.xml from an old blog post that disables it.
- Do not leave CI with a private settings file nobody reviews.
If a repository truly cannot offer https, treat the artifacts it serves as unverified and prefer routing them through an internal repository manager you control.
How to tell where the URL comes from
The error names a repository id, not the artifact that declared it. Two quick checks help. Search your own POMs and parent POMs for that id. If it is not there, run the dependency tree and open the POM of each direct dependency in your local repository, since the declaring POM is often one or two levels down. A repository declared in a dependency's POM is applied to your build, which is why the original attack worked.
Why upgrading beats mirroring
Mapping the repository id to an https mirror keeps an old library working, but you still depend on a library whose POM is stuck on an insecure URL. That often means it is unmaintained. If you can, upgrade or replace it, and keep the mirror only as a bridge with a ticket to remove it.
Steps
- Read the repository id in the error.
- Find which POM declares it with
mvn dependency:treeor by inspecting the dependency's POM. - Apply the fix from the table.
- Rebuild with a clean local repository to confirm.
- Record the decision in the project README.
Quick check
Is the block a bug I can ignore?
No. It protects against tampered downloads. Fix the URL rather than bypassing it.
Which Maven versions block http repositories?
Maven 3.8.1 introduced it, so 3.8.1 and later behave this way.
Sources
Last reviewed: 19 October 2026.
