If you patched OFBiz to 18.12.15 in August, you were exposed again by September

A sysadmin who heard about CVE-2024-38856 in August, patched Apache OFBiz to 18.12.15, and crossed it off the list was exposed again by early September. Not because the patch failed. Because Apache fixed the endpoint, not the design that made the endpoint reachable. CVE-2024-45195 published September 4 and routed to a different Groovy view through the exact same bypass. The version number changed. The problem did not.

That is the story of OFBiz in 2024: four releases in five months, 18.12.13 through 18.12.16, each one closing a door while the wall stayed missing.

What the bug actually is

OFBiz is a free, open-source Java ERP/CRM framework. Organizations run it for accounting, order management, inventory, supply chain, and HR. The HTTP routing has two parts that do not agree with each other, and that disagreement is the whole vulnerability.

ControlServlet takes the incoming request and decides whether to require authentication. It checks the first path segment after /webtools/control/. If that segment is a public endpoint like /forgotPassword, /showDateTime, or /main, it passes the request through without credentials.

The view renderer then decides what to actually display. It looks at the full path or an override view URI, not just that first segment. So it can render a protected view even though ControlServlet only checked auth against the public one.

Put those together and the attack is one request. As SonicWall’s Hasib Vhora documented, a POST /webtools/control/forgotPassword/ProgramExport looks like a password-reset call to ControlServlet, so it passes. The renderer reads the full path, resolves ProgramExport, and lands on the Groovy script evaluation endpoint. The body carries groovyProgram= with Base64-encoded Groovy, .execute() runs OS commands, and that is remote code execution with no credentials and no user interaction. CVSS 9.8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Vhora found it while testing the patch for the sibling CVE-2024-36104. That detail matters, and we will come back to it.

Four CVEs, one flaw

Here is the year, laid out:

CVE	Published	How it got in	Fixed in
CVE-2024-32113	May 2024	Path traversal via .. and semicolons	18.12.13
CVE-2024-36104	June 2024	Encoded traversal %2e%2e evading the prior patch	18.12.14
CVE-2024-38856	August 2024	Chaining through public endpoints to ProgramExport	18.12.15
CVE-2024-45195	September 2024	Other Groovy views (XmlDsDump and friends) lacking explicit auth	18.12.16

Read the “how it got in” column top to bottom. The mechanism shifts every time. The cause does not. Every one of these is the controller and the view renderer consulting different signals for the same request.

The 38856 fix added explicit authorization checks so unauthenticated users could not reach protected screen-rendering endpoints. That closed ProgramExport. CVE-2024-45195 found other Groovy views that also invoked the scripting engine and also lacked their own explicit auth check, and walked through. The fix architecture was sound; the list of endpoints it covered was incomplete. So Apache extended the list. That is not the same as removing the disagreement between the two components, which is still there in 18.12.16. It just has fewer reachable expressions today.

When the person who finds your RCE finds it while reviewing your patch for the last RCE, the issue isn’t a clever attacker. It’s that each release treated a symptom as the diagnosis.

This was being scanned within days

CVE-2024-38856 was disclosed August 5. It went into the CISA Known Exploited Vulnerabilities catalog around August 27 — CISA’s confirmation that exploitation in the wild was already happening — with the federal remediation deadline for FCEB agencies set at September 17 under BOD 22-01.

No named ransomware crew or APT has been publicly tied to 38856 specifically; exploitation looks opportunistic, which is worse for your purposes, not better. Opportunistic means scanned indiscriminately, not targeted at someone else. The sibling CVE-2024-32113 drew Mirai botnet variants. And OFBiz has a long exploitation record: CVE-2020-9496 was hit by the Syssrv botnet, and CVE-2021-29200 saw active exploitation that GreyNoise tracked across more than 29 unique IPs. This vulnerability class in this product gets weaponized, reliably.

OFBiz also showed up briefly in our dev-tools and CMS supply-chain RCE roundup when CVE-2024-45195 landed. It earns its own post because the pattern is the point, not the single bug.

The part that makes this a blind spot

You may run OFBiz and not know it. That is the operational trap.

It isn’t a household name in vulnerability scanning the way Cisco IOS or FortiOS is, so it’s frequently not in the default scanner config. It also hides under other products. HotWax Systems builds supply-chain SaaS, order management, warehouse management, product information management, on top of OFBiz for 50-plus enterprises across automotive, aerospace, FMCG, and fashion retail. Customers of those products may have no idea OFBiz is underneath. Adoption estimates put OFBiz at 240-plus organizations globally, with names like United Airlines, Home Depot, HP, IBM, and Accenture in the mix.

Then there’s the assumption that quietly does the most damage: “our implementation partner handles patching.” Maybe they do. Maybe their SLA covers it in 90 days. The internet-facing exposure does not wait for the SLA. Teams often deploy OFBiz with only the e-commerce components facing the internet and the ERP internal, which sounds safe. The 38856 bypass needs only /webtools/control/ to be reachable. Not the full ERP surface. Just the control path.

What you actually do

Patch to 18.12.16. Not 18.12.15. 18.12.15 closes 38856 and leaves 45195 open, which is the entire reason this post exists. If you took the August fix and stopped, you are on the exposed version right now.

Short of patching, you can block /webtools/control/ at the WAF or reverse proxy, and specifically restrict /webtools/control/ProgramExport and /webtools/control/xmlrpc. Treat that as a tourniquet, not a fix. WAF rules written for 38856’s ProgramExport did not cover 45195’s alternative views, which is the same lesson the version-number approach taught, one layer up.

Finding it is the real work. Query for Java services on 443 and 8443 with /webtools/control/main in the path. Pull deployment records and search for “OFBiz” or “HotWax.” Add it to the security questionnaires you send supply-chain partners, because the OFBiz in your environment may belong to someone else’s product.

We track exactly this kind of multi-CVE remediation in the daily digest: when one update clears several CVEs, and when last month’s patch quietly stopped being enough.

The renderer and the controller still don’t talk to each other. Patch to 18.12.16, and assume the next door is already being knocked on.

Sources

• CVE-2024-38856 — NVD — 2024-08-05
• CVE-2024-45195 — NVD — 2024-09-04
• SonicWall Discovers Second Critical Apache OFBiz Zero-Day Vulnerability — SonicWall — 2024-08
• CVE-2024-36104 — NVD — 2024-06
• CVE-2024-32113 — NVD — 2024-05
• CISA Known Exploited Vulnerabilities Catalog — 2024-08-27