Back to Blog
Cybersecurity

Black Hat 2026 Enterprise Java Flaws: Why Your Internal System Is Not Safe

Origami TeamEditorial Team
8 min read
Black Hat 2026 Enterprise Java Flaws: Why Your Internal System Is Not Safe

Black Hat 2026 Enterprise Java Flaws: Why Your Internal System Is Not Safe

On 5 August 2026, researchers from Novee led by Lidor Ben Shitrit presented work at Black Hat USA that disclosed twelve vulnerabilities across four enterprise Java platforms, including two critical chains that allow code execution on the server with no login at all, in the Bonita BPM workflow platform and in Apache OFBiz, the open-source ERP. The practical takeaway for any business owner: the system you assume is protected because it is internal can be reached with two browser requests if it is exposed and unpatched. Real protection starts with an inventory of what you run and a patching routine, not with trust in the network perimeter.

What the researchers actually found

The research was not built on one spectacular bug. It was built by combining small, common middleware mistakes: differences in how a URL is parsed, incomplete protection at the request-handling layer, cryptographic keys hardcoded into the source, and unsafe template evaluation. Individually none of these looks dangerous, which is exactly why they survive code review and get filed as low priority. Chained together they produce a complete path from anonymous visitor to command execution on the server. Of the twelve vulnerabilities, four work before authentication and one breaks isolation inside the execution sandbox.

The BadBonita chain: three weak points make one full compromise

The first chain affects Bonita BPM version 10.4.3. It begins with an authentication bypass built from three linked weaknesses: path traversal using the ..; notation, a security filter that matches on a substring rather than the full path, and internal request-forwarding logic. The result is that a request reaches an internal API nobody outside was ever supposed to see. That API accepts untrusted XML and passes it straight to the XStream library, which deserializes it, and through a well-known Commons Collections gadget chain the path ends in Groovy commands running on the server.

Note that none of these steps requires a leaked password, social engineering, or prior access. All the attacker needs is for the system to be reachable over the network.

OFBiz: a signing key published in an open repository

The second issue, tracked as CVE-2026-31986 and rated critical, affects Apache OFBiz version 24.09.05 when single sign-on is enabled. The problem is that the default signing keys live in the publicly published source code, and because many installations leave defaults untouched, an attacker can forge a valid SSO token in the name of an administrator account. From there the request passes a denylist that tried to block words such as java, process, and import, but the list was case-sensitive and checked specific patterns, so changing the case of a letter or using an alternative auto-imported class name is enough to slip through. The end result: two unauthenticated GET requests are enough to reach code execution on any install running SSO.

Why this matters to you specifically

Because neither of these is a marginal tool. OFBiz is an open-source ERP that many companies use to run inventory, procurement, and invoicing, and Bonita is a workflow engine that drives internal approvals and procedures. Whoever reaches those two places is not just reading data, they are standing in the middle of your operating cycle: purchase orders, supplier pricing, employee records, customer history. The researchers reported that both vendors shipped fixed releases within the standard ninety-day disclosure window, which means the update exists and responsibility now sits with whoever operates the system, not with whoever built it.

The real gap in the market is not missing patches, it is missing inventory. Many organisations have no current list of what they actually run, at which version, and on which domain. So an old staging copy stays hanging on a forgotten subdomain for two years and becomes the door nobody thought about.

What to do this week

  • Inventory your systems: a written list of every system you run, its version, whether it is exposed to the internet, and who owns it by name.
  • Update Bonita and OFBiz to the fixed releases immediately if you run either, and read the official Apache security page before you upgrade.
  • Replace every default encryption or signing key that shipped with the product. Any value printed in the documentation is not a secret.
  • Close admin gateways to the open internet and reach them over a private network or a short allowlist of addresses.
  • Decommission old staging copies and unused subdomains. They are the easiest target and the least monitored.
  • Turn on access logging and retain it. Without logs you will not be able to answer later whether anyone got in at all.

The engineering lesson: the internal network is not a security boundary

The most important recommendation to come out of this research is that internal routing should be treated with internet-level controls. The old idea that anything behind the firewall is safe has failed in practice: a single authentication-bypass flaw turns every internal endpoint into a public one. Three engineering rules follow, and they belong in your development standards:

Never rely on a denylist to protect a dangerous operation. If expression evaluation is not required in a code path, remove it entirely instead of trying to filter it.

The second rule is never to gate a sensitive operation on a settings flag or a user preference that can be changed from inside the system. The third is to audit authentication filter logic for any substring matching, because it is the most repeated and most easily exploited mistake in this class. When we build new business systems at Origami we apply this by default: explicit authorisation at every endpoint, and no trust derived from where a request sits on the network.

The regulatory angle in Saudi Arabia

If the compromised system holds personal data of individuals inside the Kingdom, this stops being purely technical. The Personal Data Protection Law obliges the controller to take the necessary measures to protect that data and to report incidents that affect its privacy. The National Cybersecurity Authority publishes essential controls covering vulnerability management, patching, and asset management, which are precisely the controls that would have stopped this chain. Running an old version of a product with a known, already-patched vulnerability is a position that is hard to defend in any audit.

The simple rule: treat security updates as a monthly operational commitment with an owner and a date, not as an emergency task performed after an incident.

Sources

#Cybersecurity#ERP Systems#Vulnerability Management#Data Protection

Frequently Asked Questions

Is my company exposed to these vulnerabilities?+

You are exposed if you run Bonita BPM 10.4.3 or earlier, or Apache OFBiz 24.09.05 or earlier with single sign-on enabled, and the system is reachable over the network. Check the version you actually run, not the version written in the contract or the handover document, then upgrade to the fixed release.

Our system is internal and not published on the internet, are we safe?+

Not necessarily. The core point of this research is that one authentication-bypass flaw turns any internal endpoint into an open one, and an infected device on the network or a leaked staff account is enough to reach it. Treat internal systems with the same level of protection: explicit authorisation, non-default keys, and regular updates.

What is the minimum I should demand from my system vendor?+

Ask for three things in writing: a list of the components and versions your system runs on, a security update policy with a defined response time for critical vulnerabilities, and a periodic report proving updates were actually applied. Put these clauses in the support and maintenance contract, not in email threads.

Is open-source software less secure than closed-source?+

No. The difference is that open-source flaws are disclosed publicly alongside their patches, so you can see them and act, while closed-source flaws depend on the vendor's schedule. The real risk is identical in both cases: running an old version when an update exists. Open source only becomes riskier when you leave its default keys and settings exactly as they shipped.

Rate this article

Related Articles

Weekly newsletter

The latest articles that matter to business owners, once a week. Just your email.

Looking for a software solution for your business?

At Origami we build custom systems, websites, and stores tailored to how your business works. Get in touch and we'll show you how we can help.

One session. Twenty minutes. No commitments.