Skip to content

Fixes :: #1489 :: Add security warnings against version ranges and special version qualifiers #1494

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
HarshMehta112 wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fixes :: #1489 :: Add security warnings against version ranges and special version qualifiers #1494

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions content/markdown/pom.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -314,6 +314,8 @@ Version requirements have the following syntax:
Maven picks the highest version of each project that satisfies all the hard requirements of the dependencies on that project.
If no version satisfies all the hard requirements, the build fails.

**Security Warning**: The use of version ranges (hard requirements with brackets and parentheses) is **strongly discouraged** due to security concerns. Version ranges introduce unpredictability in builds, can lead to non-reproducible builds, and may unexpectedly pull in vulnerable versions of dependencies. Always prefer using explicit, fixed version numbers for dependencies to ensure build reproducibility and security. For similar reasons, the use of `min` and `max` suffixes in version strings should also be avoided (see [Version Order Specification](#version-order-specification) below).
Copy link
Contributor

@Bukama Bukama Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to only have warning a warning on this page that using those (as well as min/max, latest etc) are not recommended as they can lead to undesired behavior and pulled in artifacts and that we recommend using the enforcer-rule to enforce it. And then link to the page where version ranges are described, which is https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html and which also needs a warning with a more detailed explanation and examples and a link to the rule.

(at @elharo For me it's very similar to the system dependency: Maven support it and there are reasons to use it. Are those special and situations are rare? Yes, but they are there. So Maven should not warn about itself having a security problem, but explain it as best practice to avoid this pitfall. It's not a security problem of Maven, but of every automatic dependency mechanism.

Copy link
Contributor

@elharo elharo Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No,, this is much worse than system dependencies. It should never have been added and should never be used..

Copy link
Contributor

@elharo elharo Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, not all uses of brackets and parentheses introduce version ranges. They can also be used to pin a specific version during transitive dependency resolution


#### Version Order Specification

If version strings are syntactically correct [Semantic Versioning 1.0.0](https://semver.org/spec/v1.0.0.html)
Expand Down Expand Up @@ -399,6 +401,8 @@ Following semver rules is encouraged, and some qualifiers are discouraged:
* Avoid non-ASCII characters, including non-ASCII digits, which may sort in surprising ways.
* Avoid upper case characters.

**Security Warning**: The usage of `min` and `max` suffixes in version strings is **strongly discouraged** as they represent a security vulnerability similar to version ranges. These special qualifiers can lead to unpredictable dependency resolution behavior and potential security risks. Always use explicit, fixed version numbers for dependencies instead of relying on `min` or `max` qualifiers.

End Result Examples:

* `1` \< `1.1` (number padding)
Expand Down
21 changes: 21 additions & 0 deletions content/markdown/security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,27 @@ the code, dependencies and repositories that are used in your build.
If you want to use Maven to build untrusted code, it is up to you to
provide the required isolation.

## Security Best Practices
Copy link
Contributor

@Bukama Bukama Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the warning on this page. In my opinion this page is about CVE things.


### Avoid Version Ranges and Special Version Qualifiers

**Strongly discouraged**: The use of version ranges and special version qualifiers like `min` and `max` suffixes.

Version ranges (e.g., `[1.0,2.0)`, `[1.5,)`) and special version qualifiers (e.g., `-min`, `-max`) introduce several security concerns:

- **Non-reproducible builds**: Different versions may be resolved at different times, making builds unpredictable
- **Unexpected vulnerabilities**: Newer versions within a range may contain security vulnerabilities that weren't present when the dependency was initially added
- **Supply chain attacks**: Attackers could publish malicious versions within an acceptable range
- **Lack of determinism**: The same `pom.xml` may produce different artifacts depending on when and where it's built

**Best Practice**: Always use explicit, fixed version numbers for dependencies (e.g., `1.2.3` instead of `[1.0,2.0)` or `1.2.3-min`). This ensures:
- Build reproducibility
- Predictable dependency resolution
- Better security auditing
- Explicit control over dependency updates

See the [POM Reference documentation](./pom.html#dependency-version-requirement-specification) for more details on version specifications and the [Version Order Specification](./pom.html#version-order-specification) for information about version qualifiers.

## Security Vulnerabilities

Please note that binary patches are not produced for individual
Expand Down
Loading