Vulnerabilities

Apache OFBiz fixes 46 flaws, three allow pre-login code execution

Apache OFBiz 24.09.08 fixes 46 CVEs, including three unauthenticated RCE flaws and a hard-coded JWT key. UK firms running OFBiz should upgrade now.

Bug motif graphic with the headline Apache OFBiz patches 46 flaws

Apache OFBiz has shipped version 24.09.08 to close 46 CVEs, at least three of which let an attacker run code on the server without ever logging in. Nobody has reported exploitation yet, but OFBiz has been attacked before and the fix code has been public for weeks, so that may not last.

What happened

On 4 November 2026 the Apache OFBiz project posted a list of 46 CVE identifiers to the oss-security mailing list, all fixed in release 24.09.08. OFBiz is the open-source enterprise resource planning (ERP) and e-commerce framework run by the Apache Software Foundation. The announcement, from Jacopo Cappellato, says every earlier version is affected and that the batch contains “some critical issues”. The CVE records began appearing in public databases on 5 November. CISA’s enrichment programme has since scored one of them, CVE-2026-83542, at 9.8 on CVSS 3.1.

The worst issues are unauthenticated remote code execution flaws. The project lists CVE-2026-68524 (pre-authentication code execution through a screen definition location the attacker controls), CVE-2026-83542 (widget injection on the login page) and CVE-2026-73578 (an unauthenticated bypass of saved-view authorisation with code execution impact). Alongside these are a hard-coded cryptographic key in the JWT authentication code (CVE-2026-105330) that permits unauthenticated administrative access, and a password reset routine (CVE-2026-109928) whose flawed logic allows full account takeover.

As of 5 November, analysis published by Ostorlab and SecurityOnline found no confirmed exploitation in the wild and no public proof of concept, and Ostorlab found CVE-2026-68524 absent from CISA’s Known Exploited Vulnerabilities (KEV) catalogue.

The technical picture

OFBiz builds its web pages from XML screen definitions, and those screens are often wrapped in a “decorator” whose location comes from the request context. Ostorlab’s write-up of CVE-2026-68524 shows how two separate weaknesses combined. First, the framework took every key from an unauthenticated visitor’s JSON body and stored it as a request attribute, so a visitor could overwrite values the application expected to come from its own trusted configuration. Second, the factories that load screens, forms, grids, menus and trees accepted almost any location they were handed, including local file paths. Because the login page renders before authentication, a crafted request could make the parser read XML the attacker supplied and run whatever actions it contained, inside the OFBiz Java process and with the privileges of the account running the server.

The CVE description for CVE-2026-83542 tells a similar story. Crafted widget XML staged in a multipart upload is loaded, and an unsandboxed Groovy expression evaluated, while the authentication-failure page is being drawn. Ostorlab says it is fixed by the same new gate, WidgetSecureLocation, which rejects file-scheme locations and path traversal and denies other filesystem paths unless an administrator explicitly allows them. Request body keys can also no longer shadow attributes the web application already defines.

The rest include SQL injection, XML external entity injection, server-side request forgery, path traversal, a REST API that skips authentication by default when an operation omits its auth attribute and many missing authorisation checks. Several of those let view-only users change order prices, payment allocations, refunds or financial account balances.

Timing matters too. According to Ostorlab’s timeline, the main widget location fix was merged into the public repository in mid-August and 24.09.08 was tagged on 21 October, two weeks before the CVEs were announced. No backports are being published for the 18.12 line or older releases, so anyone on those must move to 24.09.08.

Timeline showing the OFBiz fix merged in August, release tagged 21 October and 46 CVEs announced 4 November 2026

Why it matters for UK organisations

OFBiz is not a household name, and that is part of the problem. It often sits underneath bespoke order management and online shop systems built by smaller development houses, so many owners will not link an Apache advisory to their own estate.

OFBiz also has a track record. SecurityOnline notes that three 2024 OFBiz flaws (CVE-2024-32113, CVE-2024-38856 and CVE-2024-45195) are already in CISA’s KEV catalogue, so attackers know the platform. An ERP system typically holds customer names, addresses, order history and supplier bank details. If one is compromised through an unpatched internet-facing login page, a UK controller will struggle to explain itself to the ICO when a 72-hour breach report under UK GDPR is due.

For organisations working towards or holding Cyber Essentials, the scheme’s security update control requires high and critical fixes to be applied within 14 days of release. With CVSS 9.8 scoring already published, that clock is effectively running now for any in-scope OFBiz instance.

Expert view

A batch of 46 CVEs in one release looks alarming. What concerns me more is that the code-execution bugs sit on the login page. When we test ERP and e-commerce platforms, the login screen is almost always exposed to the internet, because remote staff, suppliers and customers need it. A flaw that fires before authentication on that page can be scanned for at internet scale, and OFBiz’s earlier KEV entries show that attackers already keep it on their target lists.

The gap between the public fix and the announcement is the other warning sign. In my experience, a fix that lands quietly in a public repository months before the advisory gives capable attackers a head start. I would not treat “no known exploitation” as meaning there is time to wait for the next maintenance window. Organisations that give staff or partners broad view-only access should also check those accounts could not have altered orders or balances.

What to do now

  1. Find every instance. Ask your developers and suppliers directly whether any system you run is built on Apache OFBiz, including containers and customised forks. Ostorlab notes that the VERSION file reads 24.09 for every 24.09 point release, so confirm the build from the install directory, git tag or archive name instead.
  2. Upgrade to 24.09.08. This is the only fix. Back up the database and runtime configuration first, and follow the project’s upgrade guidance rather than reloading seed data over a live database. Sites on 18.12 or older have no backport, so agree a migration with your integrator now.
  3. Cut exposure while you schedule the upgrade. Put the web interface, especially the login page and webtools, behind a VPN or an allowlist of known administrator addresses. This is the Cyber Essentials firewall control in practice, but it reduces risk without fixing the code.
  4. Check for signs of compromise. Review reverse proxy and access logs for unusual anonymous JSON or multipart POST requests to login and control endpoints, and OFBiz logs for unexpected XML parse errors. If anything looks wrong, rebuild from a clean 24.09.08 install and rotate the database, mail and API credentials the server held.
  5. Review accounts and business data. Audit administrator accounts, scheduled jobs, password reset activity and recent changes to orders, refunds and payment records, since several of the fixed flaws allowed changes beyond a user’s role.

Bottom line

Apache OFBiz 24.09.08 closes three pre-login code execution routes, a hard-coded admin key and dozens of authorisation flaws in a platform attackers have exploited before. No exploitation is known yet, but the fixes have been public for weeks. Find your instances, take them off the open internet and upgrade now.

Sources

Related Posts