Summary
CVE-2024-45195 is a critical vulnerability in Apache OFBiz, a widely used open-source enterprise resource planning (ERP) system with a CVSS score of 7.5 by NVD. The flaw enables unauthenticated remote code execution (RCE) due to an insecure use of Java's scripting engine within the web application's request handling logic.
Discovered in Apache OFBiz versions prior to 18.12.15, this vulnerability allows attackers to execute arbitrary code on the server without any authentication, leading to full system compromise. This exploit bypasses previously issued patches (CVE‑2024‑32113, ‑36104, ‑38856) by taking advantage of direct requests (“forced-browsing”) to reach Groovy service screens without authorization.
Technical Details
Before diving into the technical details, it's essential to have a high-level understanding of what Groovy is and what went wrong.
Groovy is a scripting language for the Java platform. It allows developers to write flexible, dynamic code that's easier to modify compared to pure Java.
- In Apache OFBiz, Groovy is used to build backend screens that perform admin-level tasks like exporting data or managing entities.
In OFBiz, users interact with "screens" (views) controlled by a combination of controller files and view maps. Earlier fixes focused only on securing the controller logic, assuming attackers wouldn't be able to access views directly.
However, by crafting specific URLs (via forced browsing), an attacker could bypass these controls and reach Groovy-based admin views. These screens were not individually protected, which opened the door to abuse.
Rapid7’s research links CVE-2024-45195 to earlier issues (CVE-2024-32113, CVE-2024-36104, CVE-2024-38856), all stemming from the same root cause: the controller and view-map state can be desynchronized via malicious URLs, allowing access to admin Groovy views without authentication.
Earlier patches attempted to normalize URIs by sanitizing path segments like .., ;, and %2e. Example patch from CVE‑2024‑36104:
However, these fixes didn't cover all desynchronization vectors, and new paths still allowed bypass.
The OFBiz system includes several Groovy screens intended for administrative purposes. Some of them include:
- EntitySQLProcessor.groovy
- ProgramExport.groovy
- XmlDsDump.groovy
- ViewDataFile.groovy
While some screens were blacklisted in earlier patches, others, like ViewDataFile.groovy and XmlDsDump.groovy, were overlooked. ViewDataFile.groovy screen accepts parameters from HTTP requests to load and write files, which an attacker can exploit.
The ViewDataFile.groovy screen uses request parameters:
By crafting a POST request to /webtools/control/forgotPassword/viewdatafile, attackers can:
- Supply DATAFILE_LOCATION & DEFINITION_LOCATION pointing to attacker-hosted XML/CSV
- Set DATAFILE_SAVE to a JSP within the web root (...index.jsp)
OFBiz fetches attacker files, saves a JSP shell, and allows execution via HTTP ?cmd=
Exploitation Steps
The attack targets the exposed ViewDataFile.groovy screen, which:
- Accepts a data schema (XML) and a data file (CSV) via URL. [ Exploit Source: Rapid7 ]
- Parses and processes them without authentication.
- Optionally writes the resulting file to a given local path.
By supplying:
- A schema that tells OFBiz how to interpret the input.
- A payload that contains JSP code.
- A path pointing to a .jsp location in the webroot...
We can trick OFBiz into writing a web shell that executes commands on the server.
Step 1 → Craft the Schema File (schema.xml)
Attackers first prepare a malicious schema definition (XML) that tells OFBiz how to interpret the structure of a data file. Normally, these schema files are used for defining CSV structures (e.g., column length, data type, etc.).
- Instead of normal CSV data, this schema will instruct OFBiz to interpret malicious JSP code as valid input.
Step 2 → Craft the Payload File (report.csv)
Next, attackers prepare a data file (CSV) that matches the schema definition. In the exploit, instead of plain text values, the attacker inserts server-side executable code (JSP).
Once processed by OFBiz, the uploaded data file is written directly into a web-accessible directory (such as /accounting/index.jsp).
Step 3 → Serve the Files Locally
To make the files accessible to OFBiz, you need to host them temporarily:
Then, make that local server available on the internet using SSH tunneling:
sish.revsh.net is used to port-forward your local Python HTTP server to the public internet. OFBiz will download the schema and payload from this tunnelled location.
Step 4 → Send the Exploit Request
With both files publicly accessible, send a POST request to the vulnerable Groovy screen [Assuming the lab is running on vulnerable-app.com:8443 ]:
Step 5 → Access the JSP Web Shell
Once the file is written, navigate to http://vulnerable-app.com:8443/accounting/index.jsp?cmd=id
Since index.jsp now contains our command execution shell; it executes id on the server.

You now have done remote code execution as the user running Apache OFBiz.
Mitigations
- Fixed in Apache OFBiz 18.12.16, where view-level authorization checks were added for all Groovy screens, not just controller maps. Update to the latest versions available.
- If upgrading immediately is not possible:
Temporarily disable or restrict access to the following screen:/webtools/control/forgotPassword/viewdatafile
- For additional hardening, avoid exposing Apache OFBiz directly to the public internet.