CVE-2026-116486

Objenesis before 3.6 Type Confusion via Class Name Instantiator Cache

Published Oct 26, 2026 CVSS 4.0 · 2 Low EPSS < 1% KEV · Not listed
Description
Objenesis before 3.6 contains a type confusion vulnerability that allows code in one class loader to substitute objects into another by exploiting instantiator caching keyed on class name. When a shared ObjenesisStd instance caches instantiators by clazz.getName() in ObjenesisBase.getInstantiatorOf(), same-named classes collide, causing newInstance() to return wrong-class objects and ClassCastException failures.

Analysis

AI-generated

Technical impact

Objenesis before 3.6 contains a type‑confusion vulnerability that lets code in one class loader substitute objects into another by using an instantiator cache keyed on class name. The cached instantiators are returned for classes with the same fully‑qualified name, causing newInstance() to produce an object of an unexpected type, which in turn leads to ClassCastException failures or other logic errors. This flaw is related to CWE‑386, a type safety violation.

Affected Systems

The library affected is EasyMock’s Objenesis. Versions prior to 3.6 are vulnerable. Any Java application that includes Objenesis earlier than 3.6 and shares a single ObjenesisStd instance between multiple class loaders is at risk.

Risk and Exploitability

The CVSS score of 2 indicates a low severity. No EPSS score is available and the vulnerability is not listed in the CISA KEV catalog, suggesting it is not widely exploited. The attack vector is inferred to be local within an application that uses Objenesis; an attacker would need to influence class loading in a shared class loader environment, which can lead to application crashes or aborts but not remote code execution. Thus, the primary risk is a denial‑of‑service scenario.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade to Objenesis 3.6 or later, which removes the type‑confusion flaw.
  • If an upgrade cannot be performed immediately, create separate ObjenesisStd instances for each class loader so that the cache cannot be shared across them.
  • Audit your class loading strategy to prevent loading different classes with the same fully‑qualified name into a shared class loader that uses a common Objenesis instance; consider renaming or repackaging conflicting classes.

Generated by OpenCVE AI on October 27, 2026 at 13:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories available
History
Type Values Removed Values Added
First Time appeared Easymock
Easymock objenesis
Vendors & Products Easymock
Easymock objenesis
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Description Objenesis before 3.6 contains a type confusion vulnerability that allows code in one class loader to substitute objects into another by exploiting instantiator caching keyed on class name. When a shared ObjenesisStd instance caches instantiators by clazz.getName() in ObjenesisBase.getInstantiatorOf(), same-named classes collide, causing newInstance() to return wrong-class objects and ClassCastException failures.
Title Objenesis before 3.6 Type Confusion via Class Name Instantiator Cache
Weaknesses CWE-386
References
Metrics cvssV3_1

{'score': 4.5, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L'}

cvssV4_0

{'score': 2, 'vector': 'CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N'}

Weaknesses
  • CWE-386

    Symbolic Name not Mapping to Correct Object

  • CWE-843

    Access of Resource Using Incompatible Type ('Type Confusion')

Sources

Status
PUBLISHED
Assigner
VulnCheck
Published
Updated
Oct 26, 2026, 4:15 PM
Reserved
Oct 26, 2026, 11:37 AM
Status
Awaiting Analysis
Published
Oct 26, 2026, 2:16 PM
Modified
Oct 26, 2026, 6:39 PM
Severity
Moderate
Public date
Oct 26, 2026, 1:08 PM