Upgrade to Commons Lang3 3.18.0

[snicoll]

Upgrade to Commons Lang3 3.18.0.

[waileong]

@snicoll
Are there any plans to backport this dependency bump to the 3.4.x/3.5.x branches, considering it contains security fixes? Thanks!

[snicoll]

@waileong thanks for the nudge. We have no plan to upgrade to a new feature release of Commons Lang3 in a maintenance release of Spring Boot. See our upgrade policy for more details.

If you believe you're affected by the CVE, you can override the version in your project. Alternatively, you can ask the Commons Lang3 team to backport the security fix and we'll include it next time we release.

[ppkarwasz]

Thanks for raising this.

From the Apache Commons perspective, we currently don't maintain LTS releases. While the idea has been discussed in the past, it hasn’t gained traction, largely because:

• We haven’t seen any demand from users for LTS releases.
• Apache Commons follows strict semantic versioning, so upgrading to a newer minor release (e.g., from 3.17.0 to 3.18.0) is generally considered safe and non-breaking. Of course, an LTS release could offer additional reassurance in more conservative environments.

As for releasing a patched 3.17.1, that would ultimately depend on our release manager’s availability (cc @garydgregory). However, it's unlikely for a couple of reasons:

• Version 3.18.0 already contains the fix for the CVE in question.
• The vulnerability (CVE-2025-48924) is not exploitable in most applications. Specifically, ClassUtils.getName is rarely reachable.

If there's interest, we could publish VEX (Vulnerability Exploitability eXchange) statements clarifying the reachability and risk of this CVE in other Apache Commons components. For reference, see this thread on dev@commons. We're also open to coordinating with other OSS projects on this, subject to our time availability.

[jesperronn]

Two very good arguments pulling in differnent directions

1. We have no plan to upgrade to a new feature release of [a package] in a maintenance release.
2. [package] follows strict semantic versioning, so upgrading to a newer minor release

It is very sad if both parties stand on their perspective and it will only lower the trust and quality of Spring Boot since all vulnerability scanners will flag issues 😢

From the perspective of Spring Boot team, you should definitely consider if the upgrade policy needs adjustments.

Meanwhile we have red flags in our security scannings of our projects using spring boot 3.5.x 😢

[snicoll]

Please review the comment before yours.

The vulnerability (GHSA-j288-q9x7-2f5v) is not exploitable in most applications. Specifically, ClassUtils.getName is rarely reachable.

it will only lower the trust and quality of Spring Boot since all vulnerability scanners will flag issues 😢

I think this is quite a partisans take. The CVE is not in Spring Boot. A maintainer of the project stated here that it's likely your application is not affected. So all that remain is your vulnerability scanner issuing a red flag you have to fix. The way to do that is not necessarily here.

[jesperronn]

@snicoll I fully understand and respect your point of view. However, scanners are seldom sofisticated per default, so I bet many users and companies will have to modify their vulnerability scanning policies based on this decision.

In my world, unfortunately, we will most likely not be able to upgrade spring boot until 4.0 is released several months from now.

The reason why I think it is an important subject is that historically in other open source projects, stuff will decay over time. As an example, consider the official postgresql docker image: For years, the image has been flagged as vulnerable, for instance on Dockerhub (as linked), with SNYK or similar.

(btw an interesting case because the original author of gosu package used refuses to rebuild the package because in his perspective it contains no security issues)

However, in my experience, customers and project teams will use time to discuss each vulnerability individually. This is my interest in having no security issues flagged in projects like Spring Boot.

Of course I respect your position, and acknowledge that it will be extra work to maintain branches if minor versions of dependencies also should be considered as fixes. And if possible, I agree that the optimal place to fix is to push back to the beginning of the the chain.

[ppkarwasz]

@jesperronn,

I think the real improvement needed here is in security scanners, not necessarily in how Spring Boot manages dependency versions or Apache Commons makes security releases.

1. Security-conscious companies

You clearly work for a company that takes security seriously, running scans on every release (which, believe me, is not the norm). When a scan flags a vulnerable dependency, two scenarios arise:

A. Exploitable vulnerability

If the vulnerability is actually exploitable, you can bump the dependency in your own application and verify everything still works. You don’t need to wait for Spring Boot to release an updated spring-boot-dependencies: it’s a suggestion list, not a guarantee of security.

Unless you have a support contract that explicitly promises zero vulnerabilities in spring-boot-dependencies, it’s still your team’s responsibility to ensure your app is “without known exploitable vulnerabilities” (to borrow the EU CRA terminology).

Yes, pinning dependencies is extra work, but you likely already do it for libraries not managed by Spring Boot.

B. Not exploitable vulnerability

Many scan results are false positives because:

• Most scanners cannot assess exploitability.
• Vendors benefit from reporting a high number of “issues” for marketing purposes.

The first problem is solvable.

Apache Commons example

Within Apache Commons, we’ve been experimenting with VEX files for CVE-2025-48924:

• Commons BCEL – not exploitable: https://github.com/apache/commons-bcel/tree/master/src/conf/security
• Commons Compress – not exploitable: https://github.com/apache/commons-compress/tree/master/src/conf/security
• Commons Configuration – only exploitable if security guidelines are ignored: https://github.com/apache/commons-configuration/tree/master/src/conf/security
• Commons Text – only exploitable if security guidelines are ignored: https://github.com/apache/commons-text/tree/master/src/conf/security

I used these to show that Apache Solr (with ~400 dependencies) was not affected: apache/solr-site#152.

We don’t advertise these on our website yet, but we’ll make every effort to keep them current for any OSS or commercial security scanner provider interested in testing them.

Tools that can help

The open-source SecObserve scanner is working on supporting VEX files from dependencies (SecObserve/SecObserve#3177). Supporting this kind of tooling is, in my opinion, time well spent.

2. Non security-conscious companies

Your concerns are more relevant for companies that don’t run regular scans. For them, having spring-boot-dependencies always point to “no known vulnerabilities” is indeed useful.

However, these companies rarely contribute back, either in code or financially. Since every release costs time (whether volunteer time in Apache Commons or paid time in Spring Boot), both projects have to prioritise work that benefits the broader community or their employer.

This means Apache Commons is unlikely to publish patch-only security releases solely for organisations that don’t actively manage their own security posture, just so Spring Boot can update the version in spring-boot-dependencies.