OGNL stricter-invocation block list bypass via java.lang.reflect reflection proxies

Why it is Yellow

• CVSS 5.6 medium
• Public exploit or proof of concept referenced
• On your watchlist: Maven

Affected packages

References

• https://github.com/advisories/GHSA-crwc-vw2r-qr6m
• https://github.com/orphan-oss/ognl/security/advisories/GHSA-crwc-vw2r-qr6m
• https://nvd.nist.gov/vuln/detail/CVE-2026-113730
• https://github.com/orphan-oss/ognl/commit/16396fa4b560221294c2ab9ca04b76b161115e7d
• https://github.com/orphan-oss/ognl/commit/f4c17f794754d516ea799c36ed8524d1b7fb98e2
• https://github.com/orphan-oss/ognl/releases/tag/OGNL_3_4_13
• https://github.com/advisories/GHSA-crwc-vw2r-qr6m

Original description

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.