CVE-2014-0114 is a vulnerability in Apache Commons BeanUtils — and in Apache Struts 1.x, which bundles it — where the library does not suppress the class property when populating bean properties from request parameters, letting a remote attacker manipulate the ClassLoader and, in the right conditions, execute arbitrary code. It carries a CVSS v2 base score of 7.5, and despite being disclosed back in 2014 it keeps resurfacing because Commons BeanUtils sits deep in the dependency trees of long-lived enterprise Java applications.
The short version: when a framework maps HTTP parameters onto a Java bean's properties, and it does so with a BeanUtils version that still exposes the inherited class getter, an attacker can reach class.classLoader through the parameter name and influence the ClassLoader. That is a foothold that, depending on the surrounding container and application, has been chained into remote code execution.
What is actually vulnerable
Two things are in scope. First, Apache Commons BeanUtils itself in versions before 1.9.4 — the library did not suppress the class property by default. Second, Apache Struts 1.x through 1.3.10, the older Struts 1 line (not the separate Struts 2 codebase), which used BeanUtils for its ActionForm population and inherited the flaw.
The attack surface is the property-population path. Struts 1 populated an ActionForm from request parameters by name, so a parameter named along the lines of class.classLoader.... was mapped onto the bean's class accessor, which returns the object's Class, from which getClassLoader() is reachable. Manipulating the ClassLoader from an unauthenticated request is the core of the issue.
The CVSS picture and the related CVE
CVE-2014-0114 is scored 7.5 (High) on CVSS v2. It is worth knowing its sibling: CVE-2019-10086 covers essentially the same class-property exposure that was found still reachable through a different code path afterward. Commons BeanUtils 1.9.4 is the release that suppresses the class property by default and is the version you want to be at or above. If you fixed for one of these but not the other, verify you are on 1.9.4 or later, because the two together are why "just upgrade" advice has confused teams over the years.
Always confirm the current details against the NVD entry for CVE-2014-0114 before acting, since advisory metadata is occasionally revised.
How to tell if you are exposed
The tricky part is that almost nobody depends on commons-beanutils directly. It arrives transitively, pulled in by Struts 1, by older Spring modules, by validation frameworks, and by a long tail of enterprise libraries. A direct search of your pom.xml will usually come up empty while the jar sits happily in your build output.
Resolve the full dependency tree instead:
# Maven: show every path that pulls in commons-beanutils
mvn dependency:tree -Dincludes=commons-beanutils:commons-beanutils
# Gradle equivalent
./gradlew dependencies --configuration runtimeClasspath | grep commons-beanutils
If the resolved version is below 1.9.4, you are exposed. If you find Struts 1.x anywhere, treat that as a separate and larger flag — Struts 1 reached end of life in 2013 and receives no security support at all, so it is a liability well beyond this single CVE.
Because the risk is transitive, this is the kind of finding that hides from manual review. Composition analysis is built for exactly this: a tool such as Safeguard can trace the exact dependency path that drags in a vulnerable commons-beanutils and show which of your services inherit it. Our SCA product page explains how that transitive tracing works.
Remediation
The fix, in priority order:
- Upgrade Commons BeanUtils to 1.9.4 or later. This suppresses the
classproperty by default and addresses both CVE-2014-0114 and CVE-2019-10086. If a transitive dependency pins an older version, override it with a dependency-management entry so the resolved version is 1.9.4+. - Migrate off Struts 1. If Struts 1.x is present, upgrading BeanUtils reduces this specific exposure, but the framework is unmaintained. Plan a migration to a supported framework; there is no patched Struts 1 to move to.
- Add a request-parameter filter as a stopgap. If you genuinely cannot upgrade immediately, filtering incoming parameters that reference
classon the property-population path blunts the specific vector. Treat this as a bridge, not a cure.
After remediating, rescan to confirm the resolved version actually changed — a dependencyManagement override that is scoped wrong will look applied in the POM but not in the resolved tree. The Academy has a broader walkthrough on managing transitive dependency risk if this is your first time chasing one down.
FAQ
What does CVE-2014-0114 actually let an attacker do?
It lets a remote attacker reach the class property during bean population and manipulate the ClassLoader. Depending on the application and container, that has been chained into arbitrary code execution. The CVSS v2 base score is 7.5 (High).
Which versions fix it?
Apache Commons BeanUtils 1.9.4 and later suppress the class property by default, resolving both CVE-2014-0114 and the related CVE-2019-10086. Upgrade the resolved version to 1.9.4 or above.
I don't use BeanUtils directly — am I safe?
Not necessarily. Commons BeanUtils is almost always pulled in transitively by Struts 1, older Spring modules, and validation libraries. Resolve your full dependency tree with mvn dependency:tree or the Gradle equivalent to see whether a vulnerable version is present.
Is Struts 1 patched against this?
No. Struts 1 reached end of life in 2013 and receives no security updates. Upgrading the bundled BeanUtils reduces this specific exposure, but the framework itself is unsupported and should be migrated off.