CVE-2025-48924

What it actually does

Apache Commons Lang contains an uncontrolled recursion flaw in ClassUtils.getClass(...). When supplied with very long or deeply nested class-name inputs, affected versions can recurse until the JVM throws java.lang.StackOverflowError. Because StackOverflowError is an Error rather than a normal application exception, many applications do not catch or recover from it, which can terminate the request thread, destabilize the application, or stop the process depending on runtime behavior and error handling. Affected ranges include commons-lang:commons-lang 2.0 through 2.6 and org.apache.commons:commons-lang3 3.0 before 3.18.0. The supplied package data also indicates Debian 12 Chromium packages are fixed in 138.0.7204.157-1~deb12u1.

Why it matters to the business

Successful exploitation can cause service crashes or degraded availability in applications that pass attacker-controlled class-name strings to Apache Commons Lang ClassUtils.getClass(...). The primary risk is denial of service rather than data theft or code execution. The CVSS score is medium and EPSS is low, with no known CISA KEV listing or ransomware association, so remediation should be prioritized based on whether exposed services accept untrusted input that reaches this library. Because Commons Lang is widely used as a transitive Java dependency, exposure may exist even when the library is not directly referenced by application code.

How an attack unfolds

An attacker first identifies an application path that accepts text input and eventually resolves it as a Java class name using Apache Commons Lang ClassUtils.getClass(...), directly or through a framework, plugin, expression feature, deserialization-adjacent workflow, configuration endpoint, or validation routine. The attacker then submits an unusually long or deeply structured class-name value designed to trigger excessive recursive parsing. In vulnerable versions, the recursion exhausts the JVM stack and raises java.lang.StackOverflowError. If the application does not isolate or handle this condition, the affected request handler may fail, the application may log repeated fatal errors, health checks may fail, or the JVM/container may restart, resulting in denial of service. There is no public evidence in the provided data of mature exploitation, KEV activity, named threat actor use, or ransomware use.

How to fix it

Upgrade org.apache.commons:commons-lang3 to version 3.18.0 or later. For legacy commons-lang:commons-lang 2.x deployments, migrate away from the unsupported 2.x line to commons-lang3 3.18.0 or later where feasible, and test any API differences before production rollout. Update dependency locks, Maven/Gradle/Bazel/SBT build files, shaded JARs, application server shared libraries, and container images so vulnerable copies are removed rather than merely overridden. If using Debian 12 Chromium packages from the supplied product data, update chromium to 138.0.7204.157-1~deb12u1 or later. Where immediate upgrade is not possible, reduce exposure by rejecting excessively long class/type-name inputs, enforcing strict allowlists for class names, limiting request body and parameter sizes, isolating risky parsing paths, and ensuring process supervisors restart failed services safely.

How to confirm the fix worked

Confirm dependency resolution shows org.apache.commons:commons-lang3 version 3.18.0 or later and no commons-lang:commons-lang 2.0-2.6 copies remain in runtime classpaths, shaded artifacts, fat JARs, application server library directories, or container layers. Use software composition analysis, mvn dependency:tree, gradle dependencies, SBOM comparison, jar inspection, and runtime classpath inspection to verify the effective version. For Debian 12 Chromium, confirm the installed package version is 138.0.7204.157-1~deb12u1 or later using package inventory tooling. Regression test application features that resolve class/type names and verify they reject oversized or malformed values without raising java.lang.StackOverflowError. Review production logs after deployment to ensure prior StackOverflowError events no longer occur in paths referencing Apache Commons Lang ClassUtils.

Typical attack path

1. Discover a remotely reachable feature or API that accepts class names, type names, object paths, expressions, plugin identifiers, or configuration-like input.
2. Determine or infer that the backend uses Apache Commons Lang ClassUtils.getClass(...) on attacker-controlled input.
3. Send a very long or deeply nested class-name string intended to force uncontrolled recursion.
4. Trigger java.lang.StackOverflowError in the vulnerable library.
5. Cause request failure, thread death, application instability, process termination, or repeated restarts depending on JVM and container behavior.
6. Repeat requests to sustain a denial-of-service condition.

How to detect it

To determine whether exploitation already occurred, review application logs, JVM logs, container logs, web access logs, reverse proxy logs, APM traces, crash reports, and orchestration events for StackOverflowError events correlated with inbound requests containing unusually long parameters, paths, headers, JSON fields, form values, or configuration/type-name inputs. Focus on stack traces that include org.apache.commons.lang3.ClassUtils.getClass or org.apache.commons.lang.ClassUtils.getClass. Look for sudden increases in HTTP 500 responses, request timeouts, pod/container restarts, JVM exits, OOM/crash-loop-like symptoms without memory exhaustion, failed liveness/readiness probes, and repeated requests from the same source immediately before application instability. Since exploitation causes denial of service rather than a persistent implant, indicators are primarily transient logs and crash artifacts rather than files, registry keys, or malware processes.

• java.lang.StackOverflowError
• org.apache.commons.lang3.ClassUtils.getClass
• org.apache.commons.lang.ClassUtils.getClass
• ClassUtils.getClass
• commons-lang3-3.17
• commons-lang3-3.16
• commons-lang3-3.15
• commons-lang3-3.14
• commons-lang3-3.13
• commons-lang3-3.12
• commons-lang-2.6
• commons-lang-2.5
• CrashLoopBackOff
• Liveness probe failed
• Readiness probe failed
• HTTP 500
• StackOverflowError: null

What your security team should do

• Inventory all Java applications, services, containers, and third-party products for commons-lang:commons-lang 2.0-2.6 and org.apache.commons:commons-lang3 versions before 3.18.0.
• Prioritize internet-facing or unauthenticated services that process user-supplied type names, class names, expressions, plugin identifiers, or configuration values.
• Upgrade commons-lang3 to 3.18.0 or later and remove legacy commons-lang 2.x where possible.
• Check for shaded or bundled vulnerable library copies inside executable JARs, vendor packages, and container images, not only declared build dependencies.
• Update Debian 12 Chromium packages to 138.0.7204.157-1~deb12u1 or later where applicable.
• Add input length limits and allowlists around any feature that resolves Java class names from user-controlled data.
• Create detections for java.lang.StackOverflowError events involving org.apache.commons.lang.ClassUtils or org.apache.commons.lang3.ClassUtils.
• Review historical logs for repeated StackOverflowError crashes, restart loops, health-check failures, or bursts of oversized requests since publication.
• Because EPSS is low and there is no KEV listing, treat this as a medium-priority availability issue unless exposure is internet-facing or business-critical.