Raw vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-27727 is a high-severity Injection (CWE-74) vulnerability in Mchange Mchange Commons Java. Its CVSS base score is 8.9 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 46% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-27727 is a critical vulnerability in the mchange-commons-java library, which provides Java utilities and includes an independent implementation mirroring early JNDI functionality. This allows remote code download and execution via support for remote factoryClassLocation values in maliciously crafted javax.naming.Reference objects or serialized objects. The issue affects versions prior to 0.4.0, particularly when the library is on the application CLASSPATH, as seen in dependent libraries like c3p0. Although JDK implementations of similar JNDI dereferencing were hardened by defaulting com.sun.jndi.ldap.object.trustURLCodebase to false, mchange-commons-java's separate code bypasses this protection.
An attacker can exploit this remotely over the network with low complexity, requiring no privileges or user interaction (CVSS 9.8: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). By provoking an application to process a malicious Reference or serialized object, the attacker triggers the library to download and invoke arbitrary remote code, achieving full remote code execution (RCE) with high impact on confidentiality, integrity, and availability. Associated with CWE-74, exploitation targets applications using vulnerable versions of mchange-commons-java or dependents like c3p0.
Advisories recommend upgrading to mchange-commons-java version 0.4.0 or later, where JNDI functionality is gated by configuration parameters defaulting to restrictive values, mirroring the JDK's mitigation approach. No known workarounds exist, and versions prior to 0.4.0 should be removed from application CLASSPATHs. Relevant guidance appears in the library's security advisories and c3p0 documentation.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-8683
Vulnerability Data
mchange-commons-java, a library that provides Java utilities, includes code that mirrors early implementations of JNDI functionality, including support for remote `factoryClassLocation` values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an…
more
application to read a maliciously crafted `jaxax.naming.Reference` or serialized object, they can provoke the download and execution of malicious code. Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to `false`, `com.sun.jndi.ldap.object.trustURLCodebase`. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened. Mirroring the JDK patch, mchange-commons-java's JNDI functionality is gated by configuration parameters that default to restrictive values starting in version 0.4.0. No known workarounds are available. Versions prior to 0.4.0 should be avoided on application CLASSPATHs.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.2.1V1.2.3V1.2.5V1.2.8
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can uncover deserialization flaws before deployment.
SI-10 directly requires validation of information inputs to reject malformed or special-element content before it reaches downstream parsers.
Engineering principles such as safe deserialization and input sanitization structurally prevent the weakness from being introduced.
Integrity verification tools can detect malformed or tampered serialized data after the fact.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input validation and output encoding that prevent injection flaws.
PR.PS-02 addresses only post-deployment updates/patching and cannot prevent introduction of unsafe deserialization code, yet it can remediate some instances when the flaw exists in outdated libraries or components.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development catches injection vulnerabilities before release.
Logging supports detection of injection attempts but does not prevent the weakness.
Monitoring activities can identify active injection attacks after they occur.
Secure development life cycle mandates input validation and output encoding that directly prevent injection flaws.
Application security requirements explicitly call for controls against injection attacks in software design.
Secure architecture principles reduce injection surfaces but do not prescribe specific neutralization techniques.