Live › vulnerability › CVE-2026-116486
Go to dashboardObjenesis before 3.6 caches instantiators by class name, so two same-named classes from different class loaders can collide in a shared ObjenesisStd instance. The result is newInstance() returning objects of the wrong class, causing ClassCastException failures and possible substitution of objects across loaders.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 14:30 UTC. All times on this page are UTC.
Projects that depend on Objenesis below 3.6 and use it in an environment where several class loaders load same-named classes through one shared ObjenesisStd instance, such as plugin containers or application servers. Single-loader applications and those that create a fresh Objenesis instance per loader are unlikely to be affected; the sources do not quantify this further.
No product ranges from the sources yet.
org.objenesis:objenesis in your build files (mvn dependency:tree | grep objenesis or gradle dependencies | grep objenesis) and note the resolved version.ObjenesisStd instance across multiple class loaders, such as in an app server, plugin system, or test framework.org.objenesis:objenesis to 3.6 or later.ObjenesisStd instance across class loaders.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-116486")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.