OGNL CVE-2026-113730

Exploitation is gated on three specific, stacked conditions that must ALL hold: (1) the application must evaluate untrusted/attacker-controlled OGNL expressions; (2) it must use the default or an equivalently permissive MemberAccess that permits reflection; and (3) it must rely on OGNL's optional stricter-invocation mode (OgnlRuntime.invokeMethod) as its sandbox/guardrail. The concrete bypass uses java.lang.reflect.Method, Constructor, or Field as a proxy so the blocked operation runs inside JDK reflection. A major LIMITING factor: applications using a restrictive MemberAccess - explicitly including Apache Struts with SecurityMemberAccess - are NOT affected, so the dominant OGNL deployment is out of scope. No user interaction or authentication is required by the attacker (PR:N/UI:N), but the vulnerable configuration itself is non-default for hardened deployments, driving the high attack complexity.

This is a defense-in-depth bypass (CWE-693, protection mechanism failure) in the OGNL library's optional stricter-invocation mode, not a directly exploitable remote flaw. The provided CVSS vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L = 5.6 Medium) reflects the conservative view that the issue only matters under specific conditions. No EPSS score was provided and there is no CISA KEV listing, so there is no public signal of active exploitation or high exploitation probability; no public exploit code was supplied in the intelligence either. The real-world risk is narrow but, where applicable, significant: the referenced fix and test code show the reflection-proxy trick (e.g. #methods[i].invoke(#pb, null)) can reach blocked classes such as ProcessBuilder, meaning a successful bypass can escalate to arbitrary code execution rather than the low C/I/A the base score implies - this is a notable tension between the vendor's L/L/L impact rating and the actual technical consequence of the bypass. The AC:H rating is well justified because exploitation is gated on three stacked preconditions (untrusted OGNL evaluation, permissive MemberAccess, and reliance on stricter invocation as the sandbox). Critically, the most common real-world consumer - Apache Struts with SecurityMemberAccess - is explicitly NOT affected, which sharply limits the exploitable population. Net: prioritize patching for any application that evaluates untrusted OGNL and depends on stricter invocation as its only guardrail, but treat it as lower urgency than the raw RCE potential would suggest because the vulnerable configuration is uncommon and no exploitation is confirmed.

An application evaluates attacker-supplied OGNL expressions and relies on the stricter-invocation mode (with a default/permissive MemberAccess) as its sandbox. The attacker submits an expression that invokes java.lang.reflect.Method.invoke (or Constructor.newInstance / Field.get) as a proxy, so the real call to an otherwise-blocked class executes inside JDK reflection without re-passing the stricter-invocation check, enabling reach to classes like ProcessBuilder. No public exploit was provided in the intelligence, though the fix's test suite documents the Method.invoke vector; high attack complexity (AC:H) applies because the permissive-but-stricter-invocation configuration must be present.