commons-lang3 3.12.0 is affected by CVE-2025-48924 — please bump to 3.18.0+

Nobody has claimed this yet.

mailgun-java declares commons-lang3 3.12.0, which is affected by [CVE-2025-48924 ](https://github.com/advisories/GHSA-j288-q9x7-2f5v)— uncontrolled recursion when processing long inputs, CVSS 6.5. The advisory covers >= 3.0, < 3.18.0.

This is still the case in 2.4.2 (published 2026-07-31), so every consumer of the library inherits a flagged transitive dependency.

Where it comes from

pom.xml line 27:

3.12.0

Used at lines 89–93 (no , so compile):

org.apache.commons
commons-lang3
${commons-lang3.version}

Suggested fix

Bump to 3.18.0 or later — the current release is 3.20.0:

3.20.0

This stays within the 3.x line, and Commons Lang maintains binary compatibility across minor versions, so it should be a drop-in change.

Why it matters downstream

Consumers can work around this by declaring commons-lang3 directly — Maven's nearest-definition rule then wins, and that is what we currently do. But:

- it is a workaround each consumer has to independently discover and maintain, and
- SCA tooling that parses the published POM rather than the resolved dependency graph keeps reporting the finding regardless, because the 3.12.0 declaration ships inside
META-INF/maven/com.mailgun/mailgun-java/pom.xml within the artifact. For anyone building a shaded/fat jar, that file gets copied into the output and scanned there — so on the consumer
side the finding cannot be resolved at all, only suppressed.

That second point is the one that motivated this issue: we cannot fix it on our end, only silence it.

Possibly related: is the dependency still needed?

While confirming the above I noticed that the published artifact contains no compiled reference to the library. Across mailgun-java 1.1.4, 2.0.0, 2.4.1 and 2.4.2, the string lang3 does
not appear anywhere in the jar bytes:

curl -s -o mailgun-java-2.4.2.jar \
https://repo1.maven.org/maven2/com/mailgun/mailgun-java/2.4.2/mailgun-java-2.4.2.jar
grep -c 'lang3' mailgun-java-2.4.2.jar # 0

I may well be missing something — an import on its own produces no constant-pool entry, so this is consistent with the dependency being used only in tests, or with a leftover import
after a refactor. If it turns out commons-lang3 is no longer needed on the compile classpath, dropping it would resolve the advisory for consumers outright. (commons-collections4 4.4,
declared at line 28, appears to be in the same position.) Entirely your call — the version bump alone resolves the issue either way.

Happy to open a PR for whichever you prefer.

Environment

- mailgun-java 2.4.2 (also reproduced on 2.4.1)
- Verified against Maven Central artifacts

Start in pom.xml at the commons-lang3 version on line 27 and its dependency declaration on lines 89–93. Check whether the dependency is used by the project or only tests, then verify the published Maven metadata no longer declares a vulnerable version; the issue is done when consumers receive a non-vulnerable dependency without a workaround.

Written by the indexing model from the issue text.