An attacker sends a single web request to a Bonita server and lands inside an internal API that assumed nobody could reach it. The request arrives unauthenticated.
From there the attacker runs code on the host. Bonita BPM handles loan approvals, insurance claims, and employee onboarding for banks, insurers, and government agencies, and its internal surface answers to strangers.
Vulnerability researchers at Novee, found the path. They presented it today at Black Hat USA 2026 in a briefing on pre-auth remote code execution in enterprise Java.
The audit covered four enterprise Java platforms. It turned up 12 vulnerabilities, among them a sandbox escape and four flaws that work before any login.
The researchers walked through two of the chains in detail, one in Bonita and one in OFBiz. Both follow the same pattern. Routing reached a surface that trusted its callers. An execution sink turned that reach into running code.
One web address walks past three guards
Bonita BPM 10.4.3 runs a public API surface and an internal API surface. The public surface wants a session and a CSRF token. The internal surface takes basic auth and feeds whatever it receives to XStream, a library that turns XML into live Java objects.
Three separate checks guard the boundary between them. A single web address defeats them at once. The checks run independently, each trusting the others to have done its job.
The first check reads a path one way. Tomcat’s dispatcher reads it another. A path segment written as ..; passes the security filter as an ordinary name. Tomcat strips the semicolon, treats the remainder as a step up the directory tree, and routes the request onto the internal surface.
The second check runs a match that fires on any substring. A fabricated app name in the path satisfies the auth filter. The same substring satisfies the CSRF filter. Both filters stop reading at the substring they matched.
The remaining check protects direct requests and passes forwarded ones. Bonita declares that protection for a single request type and omits the rest. A request arriving by internal forward passes untouched.
Chained, the gaps fold the login wall into a single POST request. The attacker stands inside the internal API, unauthenticated.
XStream turns XML into a shell
XStream accepts any type. Attacker XML rebuilds a gadget chain from Commons Collections classes, routes it through a memory shortcut that skips the usual safety checks, and reaches a Groovy call that runs a command. The sequence executes inside a single XStream call before the request finishes.
One key unlocks OFBiz
Apache OFBiz 24.09.05 signs its single sign-on tokens with a key stored in a config file. That key ships in the public source repository. Every install that keeps the default signs tokens with a secret anyone can read.
Sign a token with that key and OFBiz trusts the claims inside it. Set the user to admin and an admin session appears. The attacker holds admin rights with a forged token.
The same key signs the widget engine’s callback tokens. A token carries a field naming a screen area to render. OFBiz reads the field off the token and pipes it into a template expander that evaluates Groovy.
An accessibility preference decides whether that evaluation runs. An admin can flip it. The forged admin flips it, then sends a token carrying a Groovy command in place of the screen name.
A denylist tries to block script injection. It matches lowercase text and known prefixes. A capital P on ProcessBuilder slips past it. An auto-imported class needs no prefix and slips past it too.
The result is CVE-2026-31986, rated critical. Two unauthenticated GET requests reach code execution on any OFBiz install with single sign-on turned on.
Scanners see nothing here
Each chain is built from parts that look harmless alone. A stray URL segment, a match set to the wrong mode, a missing line in a config file, a default key, a regex with no case flag.
A signature scanner has nothing to match. A generic model reads the code and flags a possible deserialization. Proof that the sink is reachable stays absent. The exploit lives in how the pieces connect.
What Bonita and OFBiz did next
Novee reported every finding to the affected projects and worked with them before publication.
“OFBiz has released new versions that address these specific vulnerabilities, and Bonita has also released a new version following our disclosure. Overall, both vendors responded very quickly, especially OFBiz, which kept us updated throughout the remediation process. Both vendors completed the fixes within the standard 90-day disclosure timeline,” Lidor Ben Shitrit, a founding-team vulnerability researcher at Novee, told Help Net Security.
The other platforms stay unnamed.
“The other two platforms are also considered large enterprise platforms. We haven’t received any recent updates from either vendor. However, we can share that the two platforms we are discussing, Bonita and OFBiz, had the most critical impact,” Ben Shitrit said.
Novee builds an offensive AI system and points it at applications like these.
“When reviewing the work that was done, the majority of the research was performed by humans, with targeted assistance from our Novee Agent. Novee’s built-in AI agent is constantly learning, expanding its knowledge, and significantly improving its results through research like this. These real-world findings help us continuously refine and fine-tune our product,” Ben Shitrit said.
What to check in your own stack
The same weak spots repeat across enterprise Java. A web config protects direct requests and passes forwarded ones. A filter exclude matches on a substring.
A signing key authorizes separate features at once. A denylist guards a script evaluator. A preference flag gates a branch into dangerous code.
Each one earns an audit pass. Harden internal routing as though it sits on the internet. Remove the unsafe execution primitives. A rendering toggle should never gate a call to eval.
Every piece in both chains is defensible on its own. Wired together, each one runs a stranger’s code.