GHSA-CRWC-VW2R-QR6M
Vulnerability from github – Published: 2026-10-21 16:31 – Updated: 2026-10-21 16:31Summary
OGNL's optional stricter invocation mode maintains a block list that prevents expressions from directly calling methods on dangerous classes such as Runtime, ProcessBuilder, and ClassLoader. The block list filters on the declaring class of the method OGNL invokes. Because java.lang.reflect.Method (and Constructor/Field) are not on the list, an expression can use reflection as a proxy — someMethod.invoke(target, args) — to reach a blocked method. The real call (e.g. ProcessBuilder.start()) then executes inside the JDK reflection machinery and never passes back through OGNL's invokeMethod, so the block list never sees it.
Proof of concept
Under the default OGNL context (public-only access, stricter invocation enabled), the following expression creates a file even though a direct new ProcessBuilder(...).start() is blocked:
(#pb=new java.lang.ProcessBuilder({"/usr/bin/touch","rce-proof.txt"}),
#methods=@java.lang.ProcessBuilder@class.getMethods(),
#names=#methods.{ #this.getName() },
#startIdx=#names.indexOf("start"),
#methods[#startIdx].invoke(#pb, null))
Impact and scope — please read carefully
This is hardening of a defense-in-depth secondary layer, not a break of OGNL's primary security boundary.
In OGNL the stricter-invocation block list is a secondary mitigation. The primary access-control gate is the MemberAccess implementation supplied by the integrating framework or application, which OGNL consults on every constructor and method call. Frameworks that evaluate untrusted expressions are expected to install a restrictive MemberAccess — for example, Apache Struts' SecurityMemberAccess, which excludes dangerous classes and the java.lang.reflect package. Against such a MemberAccess this PoC is blocked at the very first step (the new ProcessBuilder(...) constructor), before reflection is ever reachable.
The default context that ships with OGNL intentionally allows all public members and is not designed to sandbox untrusted input. An application that evaluates attacker-controlled expressions with that permissive default already has many paths to code execution, and this technique is not required to achieve it.
You are affected only if all of the following hold: (1) your application evaluates untrusted/attacker-controlled OGNL expressions, (2) it uses OGNL's default permissive MemberAccess (or an equivalently permissive one that allows java.lang.reflect), and (3) it relies on the stricter-invocation block list as its sandbox. Properly configured consumers — including Apache Struts with its SecurityMemberAccess — are not affected. The actual protection for untrusted-expression scenarios remains a correctly configured MemberAccess; the block list should not be treated as a sandbox.
Fix
java.lang.reflect.Method, java.lang.reflect.Constructor, and java.lang.reflect.Field are added to the stricter-invocation block list, so reflection objects can no longer be used as invocation proxies in stricter mode. The java.lang.invoke.MethodHandle path was verified not to be exploitable (its signature-polymorphic invoke/invokeExact fail through OGNL's reflection-based invocation), so no additional classes are required.
Credit
Reported responsibly through Tidelift by 毛锐 (youyi.mr@alibaba-inc.com).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.4.12"
},
"package": {
"ecosystem": "Maven",
"name": "ognl:ognl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-113730"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-21T16:31:04Z",
"nvd_published_at": "2026-10-20T22:19:30Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nOGNL\u0027s optional *stricter invocation* mode maintains a block list that prevents expressions from directly calling methods on dangerous classes such as `Runtime`, `ProcessBuilder`, and `ClassLoader`. The block list filters on the **declaring class of the method OGNL invokes**. Because `java.lang.reflect.Method` (and `Constructor`/`Field`) are not on the list, an expression can use reflection as a proxy \u2014 `someMethod.invoke(target, args)` \u2014 to reach a blocked method. The real call (e.g. `ProcessBuilder.start()`) then executes inside the JDK reflection machinery and never passes back through OGNL\u0027s `invokeMethod`, so the block list never sees it.\n\n### Proof of concept\n\nUnder the default OGNL context (public-only access, stricter invocation enabled), the following expression creates a file even though a direct `new ProcessBuilder(...).start()` is blocked:\n\n```\n(#pb=new java.lang.ProcessBuilder({\"/usr/bin/touch\",\"rce-proof.txt\"}),\n #methods=@java.lang.ProcessBuilder@class.getMethods(),\n #names=#methods.{ #this.getName() },\n #startIdx=#names.indexOf(\"start\"),\n #methods[#startIdx].invoke(#pb, null))\n```\n\n### Impact and scope \u2014 please read carefully\n\n**This is hardening of a defense-in-depth secondary layer, not a break of OGNL\u0027s primary security boundary.**\n\nIn OGNL the stricter-invocation block list is a *secondary* mitigation. The **primary** access-control gate is the `MemberAccess` implementation supplied by the integrating framework or application, which OGNL consults on every constructor and method call. Frameworks that evaluate untrusted expressions are expected to install a restrictive `MemberAccess` \u2014 for example, Apache Struts\u0027 `SecurityMemberAccess`, which excludes dangerous classes and the `java.lang.reflect` package. Against such a `MemberAccess` this PoC is blocked at the very first step (the `new ProcessBuilder(...)` constructor), before reflection is ever reachable.\n\nThe default context that ships with OGNL intentionally allows all public members and is **not** designed to sandbox untrusted input. An application that evaluates attacker-controlled expressions with that permissive default already has many paths to code execution, and this technique is not required to achieve it.\n\n**You are affected only if all of the following hold:** (1) your application evaluates untrusted/attacker-controlled OGNL expressions, (2) it uses OGNL\u0027s default permissive `MemberAccess` (or an equivalently permissive one that allows `java.lang.reflect`), and (3) it relies on the stricter-invocation block list as its sandbox. **Properly configured consumers \u2014 including Apache Struts with its `SecurityMemberAccess` \u2014 are not affected.** The actual protection for untrusted-expression scenarios remains a correctly configured `MemberAccess`; the block list should not be treated as a sandbox.\n\n### Fix\n\n`java.lang.reflect.Method`, `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` are added to the stricter-invocation block list, so reflection objects can no longer be used as invocation proxies in stricter mode. The `java.lang.invoke.MethodHandle` path was verified not to be exploitable (its signature-polymorphic `invoke`/`invokeExact` fail through OGNL\u0027s reflection-based invocation), so no additional classes are required.\n\n### Credit\n\nReported responsibly through Tidelift by \u6bdb\u9510 (youyi.mr@alibaba-inc.com).",
"id": "GHSA-crwc-vw2r-qr6m",
"modified": "2026-10-21T16:31:04Z",
"published": "2026-10-21T16:31:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/orphan-oss/ognl/security/advisories/GHSA-crwc-vw2r-qr6m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113730"
},
{
"type": "WEB",
"url": "https://github.com/orphan-oss/ognl/commit/16396fa4b560221294c2ab9ca04b76b161115e7d"
},
{
"type": "WEB",
"url": "https://github.com/orphan-oss/ognl/commit/f4c17f794754d516ea799c36ed8524d1b7fb98e2"
},
{
"type": "PACKAGE",
"url": "https://github.com/orphan-oss/ognl"
},
{
"type": "WEB",
"url": "https://github.com/orphan-oss/ognl/releases/tag/OGNL_3_4_13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "OGNL stricter-invocation block list bypass via java.lang.reflect reflection proxies"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.