12 Enterprise Java Flaws Expose Bonita BPM and Apache OFBiz to Pre-Auth RCE Attacks

Security researchers have disclosed 12 vulnerabilities affecting four enterprise Java platforms, including four pre-authentication flaws and a sandbox escape that demonstrate how weaknesses across middleware components can be chained into complete remote code execution (RCE) attacks.

Presented at Black Hat USA 2026, the research focuses on frequently overlooked components such as servlet dispatchers, authentication filters, SSO handlers, deserializers, routing mechanisms, and template engines.

Among the most serious findings are exploitation chains affecting Bonita BPM 10.4.3 and Apache OFBiz 24.09.05. Although the platforms use different architectures and vulnerability classes, researchers found a common security problem.

12 Enterprise Java Flaws

Inconsistencies between multiple middleware layers can allow an unauthenticated request to reach functionality developers assumed was protected from external attackers.

Researchers Lidor Ben Shitrit and Assaf Levkovich of Novee dubbed the Bonita BPM attack chain BadBonita. The exploitation path begins with differences in how URLs are interpreted by security filters, servlet routing components, and the underlying Tomcat environment.

Bonita separates authenticated public /API/ endpoints from an internal /serverAPI/ interface containing more sensitive functionality, including raw XStream deserialization.

A specially constructed request path can reportedly cause different application components to reach conflicting conclusions about the requested resource.

A security filter can classify the request as targeting the permitted public API, while subsequent Tomcat processing forwards it toward the protected internal interface. This creates an opportunity to cross an intended authentication boundary.

Researchers found that the problem is compounded by regular-expression handling within Bonita’s authentication and CSRF filters. The filters reportedly use Java’s Matcher.find() functionality instead of requiring a complete path match.

Consequently, an attacker can construct a URL containing an allowed substring while having the final routing destination resolve to a more sensitive endpoint.

A missing FORWARD dispatcher declaration within the /serverAPI/* security constraint completes the routing chain. Once attacker-controlled input reaches the internal API, malicious XML can be processed by XStream deserialization.

Combined with an appropriate gadget chain, this can result in arbitrary code execution inside the application process without requiring prior authentication.

Researchers also detailed a serious Apache OFBiz exploitation chain tracked as CVE-2026-31986, affecting certain environments where SSO functionality is enabled.

Novee named the chain SSOnOf(a)biz, reflecting its combination of weaknesses involving authentication tokens, application preferences, callback processing, and server-side expression evaluation.

According to the research, affected OFBiz configurations can use a default HMAC signing key for SSO and widget callback tokens.

If administrators have not replaced the shipped key, attackers may be able to forge cryptographically valid tokens, potentially including tokens representing privileged users.

The attack chain then abuses the javaScriptEnabled user preference. Although seemingly related to interface functionality, the setting also influences whether particular widget-rendering paths evaluate expressions.

An attacker-controlled callback token can reportedly place malicious content into the areaTarget claim, which eventually reaches FlexibleStringExpander and Groovy expression evaluation.

OFBiz includes regex-based protections designed to reject dangerous expressions, but researchers identified potential bypasses involving case-sensitive matching and Groovy’s default imports.

Chaining these conditions can reportedly provide remote code execution without legitimate user credentials on vulnerable SSO-enabled deployments.

The findings illustrate why enterprise Java security cannot be evaluated solely at individual endpoints. Middleware layers may independently appear secure while producing exploitable behavior when their assumptions conflict.

Administrators should apply vendor security updates, rotate default cryptographic keys, enforce strict full-path validation, and review servlet constraints for FORWARD, INCLUDE, and ERROR dispatch behavior.

Dangerous deserialization and dynamic server-side expression evaluation should be removed wherever possible. Where legacy requirements prevent this, organizations should implement restrictive XStream allowlists, JEP 290 serialization filters, strong sandboxing, and comprehensive monitoring.

Most importantly, internal APIs should be designed as potentially attacker-reachable rather than relying solely on routing or middleware assumptions for protection.