CVE-2024-45507

What it actually does

The vulnerability combines server-side request forgery with improper control over generated code in Apache OFBiz versions before 18.12.16. A remote attacker can cause the OFBiz server to issue attacker-controlled requests to internal or external resources and, where vulnerable code-generation paths are reachable, inject code that is evaluated by the application. In a worst-case scenario this can lead to unauthorized access to internal services, credential or metadata exposure, application compromise, and remote code execution under the privileges of the OFBiz process.

Why it matters to the business

Compromise of an internet-facing OFBiz instance can expose business data, enable unauthorized changes to ERP workflows, disrupt order, accounting, inventory, or back-office operations, and provide an attacker a foothold into internal networks. Although this issue is not listed in CISA KEV, it has a critical severity score, a very high EPSS probability, and weaponized exploitation, so organizations should treat exposed instances as urgent remediation targets.

How an attack unfolds

An attacker first identifies an Apache OFBiz deployment running a version earlier than 18.12.16, commonly by fingerprinting web responses, known OFBiz paths, headers, or error pages. The attacker then sends crafted HTTP requests to vulnerable OFBiz functionality that accepts or constructs server-side URLs or generated code without adequate validation. Through the SSRF portion, the OFBiz server can be induced to connect to internal-only services, loopback addresses, cloud metadata endpoints, or attacker-controlled infrastructure. If the code-injection path is reachable, the attacker may supply malicious expressions or script-like content that OFBiz generates or evaluates, potentially resulting in command execution or application-level compromise. After successful exploitation, the attacker typically enumerates files, environment variables, credentials, application configuration, connected databases, and reachable internal services, then establishes persistence or uses the compromised OFBiz server as a pivot point.

How to fix it

Upgrade Apache OFBiz to version 18.12.16 or later immediately. Place OFBiz behind authenticated access controls where possible, restrict administrative and webtools interfaces from the public internet, and enforce network egress controls so the application cannot reach loopback-only services, cloud metadata endpoints, or sensitive internal ranges unless explicitly required. Review any custom OFBiz components, plugins, Groovy/FreeMarker usage, service definitions, and URL-fetching logic for unsafe dynamic code generation or unvalidated outbound requests. If the supplied package inventory is applicable to a Red Hat RHEL EUS 8.4 real-time/NFV environment, verify kernel-rt related packages are updated to 0:4.18.0-305.49.1.rt7.121.el8_4 or later; however, the primary upstream product identified by the vulnerability description is Apache OFBiz before 18.12.16.

How to confirm the fix worked

Confirm the installed Apache OFBiz version is 18.12.16 or later using application release files, deployment manifests, container image metadata, package inventories, and running service banners where available. Verify no vulnerable pre-18.12.16 OFBiz containers, WARs, expanded webapps, or backup deployments remain active. From a controlled test network, confirm the application no longer performs outbound requests to arbitrary user-supplied URLs, loopback addresses, RFC1918 destinations, or cloud metadata endpoints. Validate that webtools and administrative paths are not internet-accessible unless protected by strong authentication and network restrictions. For Red Hat package records in scope, verify rpm reports kernel-rt package versions at or above 0:4.18.0-305.49.1.rt7.121.el8_4.

Typical attack path

1. Scan for Apache OFBiz instances exposed to the internet or reachable from a foothold network.
2. Fingerprint the application version and identify instances running before Apache OFBiz 18.12.16.
3. Send crafted HTTP requests to vulnerable OFBiz functionality that influences server-side URL generation or code generation.
4. Use SSRF behavior to reach loopback, internal RFC1918 addresses, cloud metadata services, or attacker-controlled callback servers.
5. Attempt code injection through vulnerable generated-code paths to execute application-level logic or operating-system commands.
6. Collect configuration files, secrets, session data, database credentials, or cloud credentials accessible to the OFBiz process.
7. Move laterally to internal systems or maintain access through web shells, scheduled tasks, modified application files, or stolen credentials.

How to detect it

Investigate reverse-proxy, load balancer, WAF, and OFBiz access logs for unusual POST or GET requests to OFBiz control, webtools, service, or entity endpoints, especially requests containing full URLs, loopback addresses, RFC1918 addresses, link-local metadata addresses, encoded Java/Groovy expressions, or command-execution keywords. Review OFBiz application logs such as ofbiz.log, framework logs, container stdout/stderr, and Java exception traces for outbound connection errors, template/script evaluation failures, unexpected service invocations, or stack traces mentioning Groovy, BeanShell, FreeMarker, URLConnection, HttpClient, or script evaluation. Check EDR telemetry for the OFBiz Java process spawning /bin/sh, bash, cmd.exe, powershell.exe, curl, wget, nc, ncat, python, perl, or similar tools. Review DNS, proxy, and firewall logs from OFBiz servers for connections to attacker-controlled domains, unexpected internet destinations, cloud metadata endpoints, 127.0.0.1, ::1, 169.254.169.254, and internal management services. Examine the OFBiz installation for recently modified templates, Groovy scripts, service definitions, webapps, uploaded files, cron entries, systemd units, and suspicious files created by the OFBiz runtime user. If compromise is suspected, preserve logs and memory/process evidence before remediation and rotate credentials that may have been reachable by the application.

• /webtools/control/
• /control/
• /catalog/control/
• /accounting/control/
• /ordermgr/control/
• 169.254.169.254
• metadata.google.internal
• latest/meta-data
• 127.0.0.1
• localhost
• 0.0.0.0
• [::1]
• java.lang.Runtime
• Runtime.getRuntime
• ProcessBuilder
• groovy.lang.GroovyShell
• javax.script.ScriptEngine
• freemarker.template
• URLConnection
• HttpURLConnection
• org.apache.http.client
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe
• curl
• wget
• nc
• ncat
• python -c
• perl -e
• ofbiz.log
• runtime/logs/ofbiz.log
• framework/service/config
• framework/entity/config
• applications/*/webapp
• specialpurpose/*/webapp

What your security team should do

• Prioritize internet-facing Apache OFBiz instances for immediate upgrade to 18.12.16 or later because exploitation is weaponized and EPSS is very high.
• Run an exposure sweep for OFBiz web paths, containers, virtual hosts, reverse-proxy routes, and stale deployments running versions before 18.12.16.
• Restrict access to OFBiz administrative, webtools, and service endpoints to trusted networks or VPN-authenticated users only.
• Add outbound filtering from OFBiz servers to block access to 127.0.0.0/8, ::1, link-local ranges, RFC1918 networks not explicitly required, and cloud metadata IPs such as 169.254.169.254.
• Hunt historical web, reverse-proxy, application, EDR, DNS, and firewall logs for SSRF callbacks, requests to internal metadata services, suspicious Groovy/Java execution strings, and unexpected child processes spawned by the Java/OFBiz process.
• Review OFBiz configuration files, plugins, uploaded files, scheduled jobs, and modified templates for persistence or malicious code.
• Rotate credentials accessible to OFBiz, including database passwords, API keys, service-account tokens, and cloud credentials, if exploitation is suspected.
• Instrument detections for Java processes spawning shells, command-line interpreters, network utilities, or file-transfer tools from the OFBiz runtime account.