Apache Maven may follow repositories that are defined in a
dependency’s Project Object Model (pom) which may be surprising to
some users, resulting in potential risk if a malicious actor takes
over that repository or is able to insert themselves into a position
to pretend to be that repository. Maven is changing the default
behavior to no longer follow http (non-SSL) repository references by
default in version 3.8.1


Apache Maven uses pom files as descriptors to build software and
declare dependencies. The pom files can contain references such as
plugins and configuration to be used for compilation, testing,
packaging etc, as well as a list of dependencies.

Each dependency itself is also expected to contain basic information,
including its own dependencies, allowing a transitive dependency tree
to be calculated and resolved as needed. In cases where dependencies
are not located in a default repository, a reference to an additional
repository where the dependencies can be resolved may be included in
the pom.

There are two distinct use cases for how repositories defined in poms are used:

When building a project that has a pom.xml file on disk that
references a repository, the repository reference takes precedence
over previous configuration. This is to be expected since in this
mode, one should consider the declaration to be an explicit
instruction as part of the build process.

When building a project that depends upon a dependency which
references a remote repository, things work differently. In this
instance, the remote repository is added at the end of the search list
and is scoped such that only dependencies of the pom referencing it
may be retrieved from this referenced repository. This capability has
existed in Maven since the beginning, because without the pointer to
the location of these dependencies, a consumer’s build is going to
fail. Since the repository was defined in the pom for use case #1 (ie
at build time), it made sense to allow it to be automatically
referenced during use case #2 (ie at dependency consume time).

The order in which repositories are searched is documented at

The issue at hand is that although users should always understand code
they depend upon or reuse, many consumers of dependencies do not
inspect the poms. Those users may not be aware that a pom can point
their build at yet another repository to fetch dependencies and their

With this ability for 3rd party pom authors to point a build to a new
location, it creates an opportunity for a malicious actor to direct
builds to fetch dependencies from this untrusted repository. There is
the additional possibility that a bad actor could take over an
abandoned repository url. If the attackers are in a privileged
location on the network, they could additionally exploit the lack of
ssl encryption over legacy repository definitions and attempt a Man In
The Middle (mitm) attack to insert malicious components.

Given the fact that the average consumer of dependencies may not
inspect poms for remote repositories and may not have other
compensating mechanisms in place, the Maven project has decided to
harden the default behavior in version 3.8.1 and above in the
following ways:

 (MNG-7117): A new block parameter is added to the settings.xml mirror
section. This allows a user to define a particular url that should
never be accessed by setting block = true.

(MNG-7116): A new external:http:* pattern is added to the mirrorOf
field that allows a user to redirect or, in combination with the above
block setting, block any repository reference that is not using ssl.
In combination, with the existing negation patterns, this would allow
users to selectively allow certain trusted repositories while blocking
all others. See here for more information on these patterns: Maven –
Guide to Mirror Settings

Finally, (MNG-7118) we have added a new entry to the default
conf/settings.xml which will automatically create a mirror of
external:http:* with block set to true. This will have the effect of
blocking all http repository references by default. Detailed release
notes can be found at

While this hardening limits the impact of external repositories
introduced by dependencies by only allowing ssl secured urls, and the
scope of dependency resolution is limited such that these external
repositories are searched a) last and b) only for dependencies in the
pom where it was introduced, it does not completely eliminate all
possible future attack vectors.

For absolute control over the repositories used by Maven, the
longstanding best practice for management of dependency resolution and
allowed repositories has been to use a repository manager. The typical
mechanism for enabling this mode of operation has Maven config set to
override all repository definitions (for both use case 1 and 2) by
means of setting “<mirrorOf>*</mirrorOf> in the Maven settings. This
would cause Maven to make all external requests to your Repository
Manager and thus only to the repositories defined and allowed in that

If you are currently using a repository manager in this way, you are
unaffected by the risks present in the legacy behavior, and are
unaffected by this vulnerability and change to default behavior. See
this link for more information about repository management:

Reply via email to