CyberSecBulletin
CVE-2026-55153NVD status: Awaiting Analysis

mchange-commons-java: Use of Externally-Controlled Input to Select Classes or Code

CVE-2026-55153 is a high-severity use of externally-controlled input to select classes or code vulnerability in mchange-commons-java from Swaldman, with a CVSS 3.1 base score of 7.1 out of 10. It can be exploited from the same local network by an attacker with a low-privileged account, without any action from a user. Affected mchange-commons-java versions: < 0.6.0. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.19% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Check which version of mchange-commons-java you run against the affected versions below, and install the vendor's latest release.
  2. Read the advisory on github.com for workarounds and exact fixed builds.

Affected products and versions

VendorProductAffected versionsFixed in
Swaldmanmchange-commons-java< 0.6.0Not stated

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
AdjacentThe attacker must be on the same local network segment.
Attack complexity
HighSuccess depends on conditions outside the attacker's control.
Privileges required
LowA basic user account is enough.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA (github.com).

Official description

mchange-commons-java is a Java library of shared utility classes used by mchange projects like the c3p0 connection pool. Prior to version 0.6.0, its JNDI ObjectFactory implementation (com.mchange.v2.naming.JavaBeanObjectFactory) will construct objects of arbitrary classes and initialize "JavaBean"-style properties, which for certain classes enables JNDI injection and "deserialization gadgets." Such initialization is unsafe for some classes: for example, setting the contentType property of a Swing JEditorPane to text/html and its text property to HTML containing a stylesheet <link> will provoke an HTTP GET on an arbitrary URL, potentially from within a trusted security domain. The problem is aggravated by the library's ReferenceIndirector, through which malicious JNDI Reference objects can be smuggled in for dereferencing wherever an application reads a Java-serialized object. This has been resolved in version 0.6.0.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Use of Externally-Controlled Input to Select Classes or Code

The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.

How developers prevent this class of flaw

  • Refactor your code to avoid using reflection.
  • Do not use user-controlled inputs to select and load classes or code.
  • Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.

More Use of Externally-Controlled Input to Select Classes or Code vulnerabilities (CWE-470)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in mchange-commons-java

All mchange-commons-java vulnerabilities

Recent Use of Externally-Controlled Input to Select Classes or Code vulnerabilities

Spotted an error? Tell us.