Objenesis EUVD-2026-109813

Exploitation requires all of the following, drawn from the advisory: a single shared Objenesis/ObjenesisStd instance (caching is enabled by default) reused across more than one class loader - the library's documented 'create once and reuse' pattern as seen in servlet containers, OSGi, application servers, and plugin hosts; two distinct classes that share the same fully-qualified name but are loaded by different class loaders (e.g. com.shared.AuthContext in two tenants); and the attacker's ability to run code in the same JVM (a co-tenant, uploaded module, or plugin) that reaches objenesis.newInstance for the attacker's same-named class BEFORE the trusted class is instantiated, so the attacker wins the cache slot. Limiting factors that reduce real-world risk: the vector is local (AV:L) - the attacker must already have code execution inside the JVM as a co-tenant; the ordering/race-for-cache-slot and the specific multi-class-loader deployment make it high-complexity (AC:H / AT:P); single-class-loader or single-instance-per-tenant deployments are not affected; and impact is limited to object substitution and a repeatable ClassCastException crash.

Signals converge on genuinely low real-world priority. The input CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:L/UI:N, all impacts Low) scores 2.0, and the GHSA advisory's own CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L) scores 4.5 Medium - both agree the flaw is local, high-complexity, needs some privilege, and yields only limited confidentiality, integrity, and availability impact. The vuln.today decision label is 'monitor', consistent with that. No CISA KEV entry is present (not actively exploited) and no EPSS score was supplied, so widespread-exploitation probability cannot be quantified from the data. A reproduced proof-of-concept is published in the GHSA advisory, but PoC availability is not active exploitation. The two CVSS versions differ in headline number (2.0 vs 4.5) but not in substance - both reflect a local, conditional, low-impact issue. Bottom line: this is a real correctness/security defect but not an emergency; it matters only to specific multi-tenant Java deployments and should be patched on a routine schedule rather than treated as an urgent threat.

In a JVM that reuses one shared ObjenesisStd instance across multiple class loaders (servlet container, OSGi, application server, or plugin host), an attacker-controlled plugin ships its own class bearing the same fully-qualified name as a trusted class and triggers the shared service to instantiate it first, poisoning the name-keyed instantiator cache. When the host later asks the same Objenesis instance for the trusted same-named class, it receives the attacker's instantiator and object (object substitution across the trust boundary), or the host crashes with a ClassCastException denial of service when it casts the value to its own type. A reproduced working proof-of-concept against objenesis-3.5.jar is published in the GHSA advisory.