OGNL includes an optional stricter‑invocation mode that checks the declaring class of any method accessed through the library. In versions prior to 3.4.13 the check omitted java.lang.reflect.Method, Constructor, and Field, allowing an expression crafted by an attacker to wrap a blocked method in a reflection proxy and thereby bypass the sandbox. The result is that the underlying method is executed inside Java’s reflection engine without the stricter‑invocation guard, giving the attacker the ability to invoke arbitrary code. This flaw is identified as an improper trust boundary handling (CWE‑693) and can lead to remote code execution when untrusted OGNL expressions are evaluated.

Vendor: Orphan OSS. Product: OGNL, the Object Graph Navigation Library for Java. Affected releases are any versions older than 3.4.13. Applications that use a restrictive MemberAccess policy, such as Apache Struts equipped with SecurityMemberAccess, are not impacted because the bypass requires a permissive MemberAccess that permits reflection.

The CVSS vector scores of 5.6 indicates a moderate severity overall. EPSS is not available, and the vulnerability is not listed in CISA’s Known Exploited Vulnerabilities catalog, so public exploitation activity is not currently documented. Nevertheless, the flaw requires that an attacker can inject an OGNL expression into a system that evaluates it with permissive reflection access. This is typically possible through web formulary or other input that is parsed by OGNL, such as Struts 2 action parameters. If such a vector exists, the attacker could execute arbitrary methods on blocked classes, potentially leading to system compromise. The risk is moderated by the prerequisite of a permissive MemberAccess configuration; applications in a hardened environment are less susceptible.