Critical Flaws in Enterprise Java Platforms Let Attackers Execute Remote Code
Key Takeaways Multiple critical vulnerabilities have been discovered in leading enterprise Java platforms, Bonita BPM and Apache OFBiz. The flaws include pre-authentication remote code execution...
Key Takeaways
- Multiple critical vulnerabilities have been discovered in leading enterprise Java platforms, Bonita BPM and Apache OFBiz.
- The flaws include pre-authentication remote code execution (RCE) chains, allowing attackers to execute commands without prior authentication.
- Impacted versions include Bonita BPM 10.4.3 and Apache OFBiz 24.09.05.
- Patches are available, and administrators are strongly advised to apply updates immediately and review system configurations.
Enterprise Java platforms continue to present attractive targets for adversaries, primarily due to internal middleware components often exposing pathways that developers initially intended to be private. Recent research, slated for presentation at Black Hat 2026, has unearthed a dozen critical flaws across various products, including a significant sandbox escape and four distinct pre-authentication issues.
Table Of Content
Among the most severe discoveries are two remote code execution (RCE) chains affecting widely used platforms: Bonita BPM and Apache OFBiz. Both attack chains originate prior to any user authentication, exploiting intricate connections between routing mechanisms, authentication logic, and server-side execution features.
The researchers involved confirmed that every identified vulnerability was reported responsibly through a coordinated disclosure process before public announcement. Therefore, administrators are urged to implement available updates, meticulously audit all exposed services, and refrain from unauthorized testing of production systems. A core takeaway from these findings is that internal middleware must be treated with the same security posture as externally exposed systems.
Chaining Flaws in Bonita BPM
Bonita BPM version 10.4.3 serves as a prime example of how seemingly minor defects can collectively dismantle an authentication boundary. While its public API is designed to require an active session and robust CSRF protection, the platform’s internal server API service simultaneously handles authentication and processes XStream XML data. Researchers identified a specific path containing encoded semicolons that different components of the application interpreted inconsistently.
One security layer initially classified the incoming request as part of the public API. However, the Tomcat server subsequently resolved the request towards the more sensitive serverAPI. Further compounding the issue, regular expression checks, specifically those utilizing Matcher.find, were found to accept innocuous substrings, inadvertently weakening the intended path validation. Crucially, the serverAPI’s security constraint did not extend to forwarded requests. This oversight permitted an unauthenticated request to reach XStream deserialization, where carefully crafted type permissions and a gadget chain could be leveraged to execute arbitrary commands on the server.
Forging Identities in Apache OFBiz
Apache OFBiz version 24.09.05 exhibited a similar outcome, leading to remote code execution. This comprehensive resource planning platform incorporates features such as SSO tokens, widget rendering, and support for Groovy and FreeMarker templates.
Researchers at Novee.Security reported that a default configuration flaw allowed a signing key, included out-of-the-box, to validate HMAC-SHA-512 JWTs. In installations where this default key had not been replaced by administrators, attackers could forge a JSON Web Token, effectively impersonating an administrator.
With this forged administrative identity, an attacker could set the JavaScriptEnabled preference, a UI flag necessary to proceed with the attack chain. A subsequent forged callback token could inject a Groovy expression into the areaTarget claim. The platform’s widget engine would then expand this claim and pass it directly into an evaluator for execution.
The system’s defense mechanism proved inadequate because OFBiz relied on a denylist approach to inspect expressions prior to execution. This pattern matching was case-sensitive and attempted to block keywords such as “java,” “process,” “import,” and “class.” However, the flexible semantics of Groovy made this method unreliable. Alternative class names, variations in capitalization, and imported functions could easily bypass these listed patterns while retaining full malicious functionality. The complete attack required only two GET requests on systems with SSO enabled: one to modify the preference and another to trigger the vulnerable flow. This critical vulnerability is tracked as CVE-2026-31986.
The researchers emphasized that this chain of weaknesses underscores why signed data must be rigorously validated not only by its signature but also by its intended purpose, data type, content, and adherence to trust boundaries. Defenders should proactively search for these types of chained vulnerabilities. Security constraints must extend their protection to all dispatch paths, including REQUEST, FORWARD, INCLUDE, and ERROR. Furthermore, authentication and CSRF filters should always compare normalized paths rather than relying on potentially insecure substring matches.
What You Should Do
- Apply Updates Immediately: Ensure all Bonita BPM and Apache OFBiz installations are updated to versions that address CVE-2026-31986 and other reported flaws.
- Replace Default Keys: For Apache OFBiz, replace any default signing keys with strong, unique, and rotating secrets across all trust domains.
- Review Exposed Services: Conduct a thorough audit of all exposed middleware services, treating internal components as potentially accessible from external networks.
- Strengthen Authentication and CSRF Filters: Configure authentication and CSRF filters to use normalized path comparisons, avoiding reliance on substring matching.
- Limit Server-Side Evaluation: Remove template evaluation and deserialization functionalities where they are not strictly necessary. If deserialization is essential, implement strict allowlists and JEP 290 filters to minimize exposure.
- Isolate User Preferences: Never allow user preferences or settings to directly authorize server-side code evaluation.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.