Security research presented at Black Hat 2026 has identified 12 vulnerabilities across four enterprise Java platforms, including two critical pre-authentication remote code execution (RCE) chains affecting Bonita BPM and Apache OFBiz.
Researchers Lidor Ben Shitrit and Assaf Levkovich demonstrated how seemingly minor middleware vulnerabilities, such as differences in URL parsing, incomplete servlet protections, hardcoded cryptographic keys, and insecure template evaluation, can combine to create pathways for complete unauthenticated compromises.
Enterprise Java Vulnerabilities
The findings were shared through a coordinated disclosure process. This research underscores that enterprise Java environments remain vulnerable, not only due to individual flawed libraries but also because internal components often incorrectly assume they are safe from external attackers.
The first chain, named BadBonita, affects Bonita BPM version 10.4.3. Bonita is a widely used platform for managing business workflows, human tasks, process lifecycles, and integrations with various enterprise systems, including SAP, LDAP, databases, and Salesforce.
Novee Security discovered that attackers could access Bonita’s normally restricted `/serverAPI/` interface by exploiting a combination of routing and authorization failures. While the public `/API/` surface requires authentication and CSRF protections, the internal API allows for raw XStream deserialization and is intended for HTTP API users.
The exploit chain relied on a discrepancy in how path parameters containing semicolons were parsed, weak regular expression matching in authentication and CSRF filters, and a lack of servlet dispatcher restrictions.
Java URI normalization processed a specially crafted path differently than Tomcat’s request dispatcher, allowing a request that was validated as public-facing to be forwarded internally.
Once the internal endpoint became accessible, attacker-controlled XML could be deserialized via XStream. The combination of permissive type handling and a gadget chain involving Groovy could lead to code execution before the request was completed.
This case illustrates that “internal-only” APIs should not be assumed to be inherently secure. Security controls must account for forwarded, included, and error-dispatch paths, rather than only for direct HTTP requests.
The second chain, named SSOnOf(a)biz, targets Apache OFBiz version 24.09.05 with SSO (Single Sign-On) enabled. OFBiz is a long-standing enterprise resource planning (ERP) platform used for accounting, inventory management, manufacturing, HR, e-commerce, and related business functions.
According to Novee Security, OFBiz was shipped with a hardcoded JWT (JSON Web Token) HMAC signing key in its public source code. An attacker could leverage this default key to forge a valid SSO token containing an administrator identity, effectively bypassing password authentication if the key had not been changed.
The researchers then identified another flaw in the widget-rendering workflow. A JWT callback claim, which was supposed to contain a widget target, was passed into OFBiz’s FlexibleStringExpander, which can evaluate Groovy expressions.
A user preference named `javaScriptEnabled` served as a gate before such evaluations. However, an attacker with the forged token could modify that preference.
A denylist intended to block dangerous expressions proved inadequate because it relied on case-sensitive patterns and incomplete keyword matching, resulting in a two-request pre-authentication RCE chain tracked as CVE-2026-31986.
Both exploit chains follow a similar pattern: an attacker gains access to an internal component through a trust boundary failure and subsequently reaches an execution-capable sink.
Organizations operating enterprise Java applications should conduct audits focusing on:
- `web.xml` constraints that lack coverage for FORWARD, INCLUDE, or ERROR dispatchers.
- Regex-based filter exemptions that utilize partial matching, such as `Matcher.find()`.
- Default or shared signing keys used across unrelated authentication features.
- Template engines, deserializers, and scripting runtimes that are accessible from untrusted input.
- UI flags or preference settings that influence sensitive server-side logic.
- XStream configurations that allow overly permissive type permissions.
The key takeaway is clear: middleware should be considered part of the attack surface. Internal routes, serialization handlers, SSO glue code, and rendering engines must be secured as if attackers can access them, because chained vulnerabilities can effectively invalidate that assumption.
Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world
