CVE-2026-116486
Objenesis before 3.6 contains a type confusion vulnerability that allows code in one class loader to substitute objects into another by expl
CVSS
4.5
Medium
EPSS
—
KEV
—
Exploit Today
—
0-100
Published: Oct 26, 2026 · Last modified: Oct 26, 2026 · CWE-386
Not enough EPSS history yet.
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.
- github.comhttps://github.com/easymock/objenesis
- github.comhttps://github.com/easymock/objenesis/blob/fb36e5c377ed1bf57a18386fa79d2eed4ddfcfac/main/src/main/java/org/objenesis/ObjenesisBase.java#L92-L95
- github.comhttps://github.com/easymock/objenesis/commit/40f90f435a06b16af74a7398f0007faeaa52c00c
- github.comhttps://github.com/easymock/objenesis/security/advisories/GHSA-743r-26gf-97ff
- www.vulncheck.comhttps://www.vulncheck.com/advisories/objenesis-before-3.6-type-confusion-via-class-name-instantiator-cache
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-941145.9 MED20.2%
——6Symbolic name not mapping to correct class.
BCEL caches attacker-controlled classes under their self-declared names without validating the requested name, allowing subsequent lookups and name-keyed verification results to refer to a different class.
This issue affects Apache Commons BCEL: before 6.13.0.
Users are recommended to upgrade to version 6.13.0, which fixes the issue.19dCVE-2026-530817.8 HIG7.6%
——2In the Linux kernel, the following vulnerability has been resolved:
bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars
When regsafe() compares two scalar registers that both carry
BPF_ADD_CONST, check_scalar_ids() maps their full compound id
(aka base | BPF_ADD_CONST flag) as one idmap entry. However,
it never verifies that the underlying base ids, that is, with
the flag stripped are consistent with existing idmap mappings.
This allows construction of two verifier states where the old
state has R3 = R2 + 10 (both sharing base id A) while the current
state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap
creates two independent entries: A->B (for R2) and A|flag->C|flag
(for R3), without catching that A->C conflicts with A->B. State
pruning then incorrectly succeeds.
Fix this by additionally verifying base ID mapping consistency
whenever BPF_ADD_CONST is set: after mapping the compound ids,
also invoke check_ids() on the base IDs (flag bits stripped).
This ensures that if A was already mapped to B from comparing
the source register, any ADD_CONST derivative must also derive
from B, not an unrelated C.7d