How to check your Apache OFBiz runs 24.09.08, the release that fixes two pre-login RCEs

Every Apache OFBiz release before 24.09.08 lets a request without an authenticated user make the server load widget XML the requester supplied and evaluate the Groovy inside it (CVE-2026-83542, CVSS 9.8, and CVE-2026-68524). Upgrade to 24.09.08 today. Confirm it from a clean git tag or the verified release zip and from how the service was actually started, because the VERSION file in the fixed release only says 24.09.

This guide is for protecting OFBiz installations you own or maintain.

	CVE-2026-83542	CVE-2026-68524
Entry point	login-page widget, decorator location shadowed by request data	screen definition loaded through an injected file: URI
Severity	CVSS 3.1 9.8, AV:N/AC:L/PR:N/UI:N	"important" (no CVSS from the CNA)
Weakness	CWE-94 code injection	CWE-94 code injection
Affected	all versions before 24.09.08	all versions before 24.09.08
Fixed	24.09.08	24.09.08
Published	2026-11-05	2026-11-05

Why it is dangerous

OFBiz renders pages from XML screen definitions. A screen names its decorator and included screens by location, normally a component:// URI, and widget attributes can carry Groovy expressions that run at render time. Whoever controls a location string controls which code the renderer evaluates.

The trusted locations, such as mainDecoratorLocation, come from the webapp configuration in web.xml and live as servlet context attributes. Before the fix, WebAppUtil.setAttributesFromRequestBody copied every key of a JSON request body into request attributes, and a request attribute with the same name shadows the context value when the screen looks it up. According to the CVE-2026-83542 record, a crafted body could point the decorator used on the authentication-failure path at widget XML staged by an earlier upload, and the renderer evaluated its Groovy.

The requests execute without an authenticated user. The CVE-2026-68524 record describes temporary-file handling and an open file descriptor reached through an injected file: URI (CVE-2026-68524 record). Either way the result is code running as the OFBiz service user, with the database credentials in its configuration and anything else that user can read. CISA's enrichment of CVE-2026-83542 rates it automatable with total technical impact.

PR #1654 closes both halves. The body copier now skips any key that already exists as a servlet context attribute and logs a warning, so request data can no longer stand in for configuration. Every widget load (screen, form, grid, menu, tree) now passes through WidgetSecureLocation.sanitize(): file: in any letter case is rejected, other URLs must be component://, component:// paths containing .. are rejected, and bare filesystem paths pass only if they match security.allowFilePaths, which is blank by default. That allowlist replaces an older blocklist entry for proc/self/fd. PR #1653 is a separate layer: it filters request parameters ending in Location, Screen, Template or Uri before view state is saved in the session, so a value cannot be persisted and replayed on a later page.

Am I affected?

Yes, if the OFBiz serving traffic was built from anything older than the release24.09.08 tag. That includes all of 18.12. Read a record that names the patch release, and confirm the tree matches it:

# git checkout: the tag HEAD sits on (want release24.09.08 or later)
cd /opt/ofbiz
git describe --tags --exact-match 2>/dev/null || git describe --tags
git status --porcelain          # must print nothing, or the tag does not describe these files

# release zip: the archive you unpacked (want apache-ofbiz-24.09.08), not just the folder name
basename "$PWD"

# this prints only the branch, "24.09", even on the fixed tag
cat VERSION

A result like release24.09.07-12-gabc1234 means 12 commits past 24.09.07 on some branch. Treat it as unknown until you check those commits, or move to the tag. A folder name is a hint; the zip's checksum and signature are the record.

Fix it now

# git checkout (back up the database first)
git fetch --tags
git checkout release24.09.08
git status --porcelain            # empty before you build
git rev-parse HEAD                # record this commit
./gradlew build

# release zip: download apache-ofbiz-24.09.08.zip with its .sha512 and .asc
shasum -a 512 -c apache-ofbiz-24.09.08.zip.sha512
gpg --verify apache-ofbiz-24.09.08.zip.asc apache-ofbiz-24.09.08.zip

# container: the project's Dockerfile builds locally, so rebuild from the tag
git checkout release24.09.08
docker build --tag ofbiz-docker:24.09.08 .

Then check what is running, which is a different question from what is on disk:

# Linux host: take the PID from the service manager, not from a process-name search
pid=$(systemctl show -p MainPID --value ofbiz)
ps -o lstart= -p "$pid"             # confirms a restart only
tr '\0' ' ' < /proc/"$pid"/cmdline  # the actual launch command and classpath
readlink /proc/"$pid"/cwd           # the working directory

# container: compare image IDs, then check mounts
docker inspect --format '{{.Image}}' <container>
docker image inspect --format '{{.Id}}' ofbiz-docker:24.09.08
docker inspect --format '{{json .Mounts}}' <container>

These checks identify the working directory and current on-disk JAR. Verify the service's actual launch command and classpath, deploy the complete build into a new release directory, and restart from that directory. Record the source commit and deployment manifest. In a container, matching image IDs mean little if a mount replaces the application files, so check that no mount covers the OFBiz tree.

What our lab checked

ofbiz-version-check-lab is a read-only version classifier. It runs no OFBiz code and sends no requests. It builds 16 synthetic OFBiz-shaped fixtures that hold only version records (a VERSION file, gradle.properties, the root build.gradle, a zip folder name, a git HEAD and tags), reads every version it finds and classifies the lowest one against an advisory. The lab advisory uses made-up branches 90.12 and 94.09 with fixes 90.12.4 and 94.09.2, so nobody mistakes them for real numbers.

Check (run 2026-11-07 00:34 UTC, Node 22.13.1, this Mac)	Result
old-version fixtures classified as unsafe	9/9
same fixtures classified ok after the record change	9/9
normal fixtures unchanged	7/7

Two cases mattered. A 94.09.2-SNAPSHOT sorts below the release it precedes, so it is OLD. A fixture whose VERSION says 94.09.2 while git HEAD sits on tag release94.09.1 is also OLD, because the lowest-wins rule trusts the older record. A trunk checkout with no version anywhere is NOVER, never ok.

What this does not show: the lab performs no OFBiz upgrade, renders no screen and does not test that 24.09.08 blocks either CVE; that rests on the Apache advisory and the fix PRs. It also has a gap. The real VERSION file on release24.09.08 reads 24.09, and we have no fixture for a branch-only value yet. Our reader would treat it as 24.09.0 and call a correctly upgraded checkout OLD. The error is on the safe side, but until the lab treats branch-only values as incomplete evidence, use a clean git describe or the verified zip as your verdict on a real install.

If you cannot update today

No alternative mitigation is specified; upgrade is recommended. Until the upgrade is deployed, restrict network access to the affected service. Both flaws are reached without login, so public routes count as much as admin pages. A request to / checks only that address and route; review every published listener and proxy route. From a host outside your network:

curl -sSk -o /dev/null -w '%{http_code}\n' --max-time 5 https://ofbiz.example.com:8443/
echo "curl exit status: $?"

000 means no HTTP response arrived. DNS, TLS and timeout failures print it too, so read the exit status and error message; 000 alone does not prove the block works (curl documentation).

Timeline and sources

Date	Event
2026-07-30	CVE-2026-68524 reserved
2026-08-14	PRs #1653 and #1654 merged into release24.09
2026-08-31	CVE-2026-83542 reserved
November 2026	24.09.08 released (download page); fixes 46 CVEs (security page)
2026-11-05	both CVE records published
2026-11-06	CISA ADP enrichment of CVE-2026-83542: exploitation none, automatable yes
2026-11-07	our lab run

Our take

The OFBiz VERSION file names the branch, so on the tag that carries the fix it reads 24.09, the same as every older 24.09 release. We found this by checking our own lab against the repository. Any inventory script or scanner that reads only VERSION cannot tell a patched OFBiz from an unpatched one. A clean tag, a verified zip and a recorded commit are the records that change with the patch.

The fix PRs merged into release24.09 on August 14, months before the CVE records went public. A team building from the branch may already carry them without knowing, and a team on a pinned older tag does not, even though both say 24.09. That is the same gap between "fix released" and "fix installed" we measured for PHP and Node.js, and the WordPress and PHP runtime checks follow the same order: version record first, then the running process.

Both CVEs cross the boundary between request data and executable screen resources. If you maintain custom OFBiz components, search them for request parameters ending in Location, Screen, Template or Uri, and for code that copies request bodies into attributes. The framework now guards its own path, and custom code can open a new one. The Rails upload check is a related case, where an uploaded file was trusted as more than data.