CVE-2026-113730: OGNL stricter-invocation block list bypass via java.lang.reflect reflection proxies
OGNL is an Object Graph Navigation Library for Java. Prior to 3.4.13, the optional stricter-invocation mode in OgnlRuntime.invokeMethod checks the declaring class of the method that OGNL invokes but does not block java.lang.reflect.Method, java.lang.reflect.Constructor, or java.lang.reflect.Field. An attacker-controlled expression can invoke one of these reflection objects as a proxy for a method on a blocked class, causing the real operation to execute inside JDK reflection without passing through the stricter-invocation check again. Exploitation requires an application to evaluate untrusted OGNL expressions, use the default or an equivalently permissive MemberAccess that permits reflection, and rely on stricter invocation as a sandbox. Applications using a restrictive MemberAccess, including Apache Struts with SecurityMemberAccess, are not affected by this bypass. This issue is fixed in 3.4.13.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OGNLto a version that resolves this vulnerability.Fixed in 3.4.13 - Configuration
Use a restrictive MemberAccess, such as Apache Struts SecurityMemberAccess, that does not permit the reflective bypass.
OGNL MemberAccess = restrictive
Event History
Frequently Asked Questions
Which applications are exposed to this bypass?
An application is exposed only if it evaluates untrusted OGNL expressions, relies on stricter-invocation mode as a sandbox, and uses the default or an equivalently permissive MemberAccess that allows reflection. Applications using restrictive MemberAccess, including Apache Struts with SecurityMemberAccess, are not affected by this bypass.
What does an attacker need to exploit the issue?
The attacker needs a way to supply an OGNL expression that the application evaluates. They can use java.lang.reflect.Method, Constructor, or Field objects as proxies to invoke operations on classes blocked by stricter-invocation checks.
What should be done if upgrading is not immediately possible?
Do not evaluate untrusted OGNL expressions, and use a restrictive MemberAccess that does not permit the reflection access required for the bypass. Do not rely on stricter-invocation mode alone as a sandbox.
How can I determine whether the deployed OGNL version is affected?
OGNL versions prior to 3.4.13 are affected under the vulnerable configuration. Version 3.4.13 contains the fix.