Apache Johnzon EUVD-2026-104193

Exploitation requires that the host application use Johnzon to deserialize attacker-controlled JSON into a type routed through ClassConverter (i.e., a java.lang.Class-typed target field), AND that a class whose loading or static initialization causes a harmful side effect be present on the application classpath. Limiting factors: the app must actually expose such a deserialization path to untrusted input (no exploitation against Johnzon in isolation), realized impact is bounded by available classpath gadgets, and only Johnzon 1.0.0 to <1.3.1 (javax) and 2.0.0 to <2.2.0 (jakarta) are affected. No authentication is required per CVSS PR:N where the deserialization endpoint is unauthenticated.

Signals conflict sharply and should be weighed together rather than reading the 9.8 at face value. The NVD CVSS vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H) and SSVC (Automatable: yes, Technical Impact: total) describe a worst-case unauthenticated network path with full impact, consistent with unsafe reflection (CWE-470) that loads and static-initializes an attacker-named class. Against that, EPSS is low (0.36%, 28th percentile), the vulnerability is NOT in CISA KEV, SSVC Exploitation is 'none', and no public exploit was identified - so there is no evidence of real-world exploitation yet. The 9.8 also assumes conditions the description implies but does not guarantee: the application must actually route untrusted JSON through Johnzon's ClassConverter (i.e., deserialize into a java.lang.Class-typed field), and a class whose mere loading/static-initialization causes harm must exist on the classpath. That makes this a genuinely serious library-level flaw worth prioritizing for teams that embed Johnzon and deserialize untrusted JSON, but the CVSS 9.8 likely overstates typical real-world risk; realized impact is gadget- and integration-dependent. Note the EPSS-vs-CVSS gap (low probability despite critical score) suggests latent rather than active risk. Patch and affected ranges are vendor-confirmed, so remediation is straightforward.

An application uses Apache Johnzon to deserialize untrusted JSON (e.g., a JAX-RS request body) into an object whose field is resolved through ClassConverter. The attacker supplies a class name in that JSON field; Johnzon loads and static-initializes the attacker-chosen class, running its static initializer and triggering side effects (potential code execution or resource abuse) bounded by what gadget classes exist on the classpath. No public exploit code was identified at time of analysis.