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

[ucjonathan]

mailgun-java declares commons-lang3 3.12.0, which is affected by CVE-2025-48924 — 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:

<commons-lang3.version>3.12.0</commons-lang3.version>

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:

<commons-lang3.version>3.20.0</commons-lang3.version>

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