CVE-2026-45434 — Apache OFBiz LoginWorker checkLogin Password-Change Flow Authentication Bypass RCE

1. Overview

A vulnerability exists in Apache OFBiz’s login authentication workflow that allows an attacker to bypass a forced password-change restriction and achieve remote code execution. When an administrator sets the requirePasswordChange flag on a user account — for example after a credential leak, during new employee onboarding, or as a default on demo accounts — the account is supposed to be locked out of all functionality until the user changes their password through the dedicated ChangePassword form. However, LoginWorker.checkLogin() fails to recognize "requirePasswordChange" as an authentication failure, treating it identically to a successful login. An attacker who knows the current password of a locked account can bypass the restriction by injecting requirePasswordChange=Y as an HTTP request parameter along with a new password, causing the login and password change to execute inline and granting immediate access to the requested endpoint. Combined with ProgramExport.groovy lacking permission checks and a Groovy sandbox in versions prior to 24.09.06, this enables arbitrary OS command execution in a single HTTP request. Apache addressed this vulnerability in version 24.09.06.

2. Vulnerability Type

The vulnerability requires two flaws in combination:

1. CWE-287 (Improper Authentication): checkLogin() only validates against the "error" string, treating a "requirePasswordChange" return from login() as successful authentication. This means requests that trigger the password-change path are not rejected at the auth check level.

2. CWE-287 (Client-Controlled Auth Flow): The requirePasswordChange flag is read from the HTTP request parameter (attacker-controlled) rather than exclusively from the database. This allows the attacker to inject the password-change flow into the auth check of ANY endpoint — not just the login/ChangePassword endpoint.

Combined, these flaws let an attacker submit credentials + password change + target request to any auth-protected endpoint in a single POST, bypassing the normal ChangePassword form routing. The unsandboxed ProgramExport endpoint (CWE-306 + CWE-94) — which lacks both permission checks and a Groovy code sandbox — amplifies the impact from an auth workflow bypass to full remote code execution.

3. Severity

CVSS 3.1 (self-assessed — no published score at time of analysis)

Note: CVE-2023-51467, which exploits the same underlying requirePasswordChange logic flaw, was scored 9.8 by MITRE/NVD.

Our Assessment (CVSS 4.0)

Scoring rationale:

• AT:P (Attack Requirements: Present) — exploitation requires OFBiz demo data to be loaded (providing known default credentials). Production instances with custom credentials require the attacker to obtain valid credentials through other means.
• PR:L — the attacker must possess valid credentials for at least one OFBiz user account. OFBiz ships with 10+ demo accounts using the default password ofbiz, but these are credentials nonetheless — not zero-knowledge access.
• SC/SI/SA: High — full OS-level compromise allows lateral movement, data exfiltration from databases connected to OFBiz, and disruption of all business processes running on the server.

4. Affected Products

Affected Products

All Apache OFBiz releases prior to 24.09.06 are affected, including the entire 18.12.x branch and the 24.09.x series through 24.09.05.

Tested Environment (Vulnerable)

Tested Environment (Patched)

5. Root Cause Analysis

5a. Detailed Description

The vulnerability combines two authentication flaws (#1 + #2) to bypass the forced password-change workflow, then chains with a third flaw (#3) to escalate from workflow bypass to RCE. Flaws #1 and #2 together constitute CVE-2026-45434; flaw #3 amplifies the impact.

Flaw 1: checkLogin() only validates against "error" (LoginWorker.java, checkLogin+0x163)

The checkLogin() method delegates authentication to login() and checks its return value inside an OR-chain conditional:

// LoginWorker.java — checkLogin()
public static String checkLogin(HttpServletRequest request, HttpServletResponse response) {
    GenericValue userLogin = checkLogout(request, response);
    // ...
    if (userLogin == null) {
        username = request.getParameter("USERNAME");
        password = request.getParameter("PASSWORD");
        token = request.getParameter("TOKEN");
        // ...
        if (UtilValidate.isEmpty(username)
                || (UtilValidate.isEmpty(password) && UtilValidate.isEmpty(token))
                || "error".equals(login(request, response))) {  // <-- VULNERABLE
            // ... set 401 ...
            return "error";
        }
    }
    // ...
    return "success";  // falls through for ANY non-"error" return
}

The login() method can return three distinct values: "success", "error", or "requirePasswordChange". Because checkLogin() only tests for "error", a "requirePasswordChange" return evaluates as "error".equals("requirePasswordChange") → false, causing checkLogin() to fall through and return "success".

Flaw 2: requirePasswordChange read from attacker-controlled request parameter (LoginWorker.java, login+0x33)

Inside login(), the password-change flag is read directly from the HTTP request:

// LoginWorker.java — login()
boolean requirePasswordChange = "Y".equals(request.getParameter("requirePasswordChange"));

This allows an attacker to inject requirePasswordChange=Y into any login request. When the userLogin service validates the credentials successfully and the attacker provides newPassword/newPasswordVerify, the password change succeeds, doMainLogin() is called, and a fully authenticated session is established.

The login() method returns the result of doMainLogin() (which is "success"), and checkLogin() correctly passes through. The net effect is that the attacker authenticates, changes the password to their chosen value, and accesses the target endpoint — all in a single HTTP request.

Flaw 3: ProgramExport lacks permission checks and Groovy sandbox (ProgramExport.groovy)

In OFBiz 24.09.05, ProgramExport.groovy evaluates user-supplied Groovy code with no restrictions:

// ProgramExport.groovy (24.09.05) — NO permission check, NO sandbox
String groovyProgram = null
// ...
if (parameters.groovyProgram) {
    groovyProgram = parameters.groovyProgram
}
// ...
GroovyShell shell = new GroovyShell(loader, binding, configuration)
shell.parse(groovyProgram)
shell.evaluate(groovyProgram)  // arbitrary code execution

There is no security.hasPermission() check, no SecureASTCustomizer, no receiver whitelist, and no dangerous-pattern regex blocklist. The attacker has full JVM access, including Runtime.getRuntime().exec(), ProcessBuilder, and Groovy’s .execute() string method.

How the flaws combine:

In the intended flow, when an account has requirePasswordChange=Y in the database, the user is forced through the ChangePassword form before accessing any other endpoint. The ChangePassword form only submits to the /login endpoint, which has response mappings that route the user back to the form or to the main page — never directly to an arbitrary endpoint like ProgramExport.

The exploit bypasses this by submitting requirePasswordChange=Y directly to ProgramExport (Flaw #2 — client-controlled parameter). The checkLogin() auth check for ProgramExport calls login(), which processes the inline password change and calls doMainLogin(). When login() returns, checkLogin() does not reject the result (Flaw #1 — only checks for "error"), so the request proceeds directly to ProgramExport. The normal ChangePassword form routing is entirely skipped.

The unsandboxed ProgramExport (Flaw #3) then executes the attacker’s Groovy code with full JVM access, including OS command execution.

5b. Vulnerable Code and Call Stack

LoginWorker.java (OFBiz 24.09.05):

The vulnerable conditional at checkLogin():

// checkLogin — the OR chain that only checks for "error"
if (UtilValidate.isEmpty(username)
        || (UtilValidate.isEmpty(password) && UtilValidate.isEmpty(token))
        || "error".equals(login(request, response))) {
    // ^^^ "requirePasswordChange".equals("error") → false → falls through
    request.removeAttribute("_LOGIN_PASSED_");
    // ... save previous URL ...
    response.setStatus(HttpStatus.SC_UNAUTHORIZED);
    return "error";
}
return "success";  // reached when login() returns "requirePasswordChange"

The client-controlled parameter at login():

// login — requirePasswordChange from request parameter (attacker-controlled)
boolean requirePasswordChange = "Y".equals(request.getParameter("requirePasswordChange"));
if (!unpwErrMsgList.isEmpty()) {
    request.setAttribute("_ERROR_MESSAGE_LIST_", unpwErrMsgList);
    return requirePasswordChange ? "requirePasswordChange" : "error";
}

// After successful credential validation:
if (requirePasswordChange) {
    Map<String, Object> inMap = UtilMisc.toMap(
            "login.username", username,
            "login.password", password,
            "userLoginId", username,
            "currentPassword", password,
            "newPassword", request.getParameter("newPassword"),
            "newPasswordVerify", request.getParameter("newPasswordVerify"));
    Map<String, Object> resultPasswordChange = dispatcher.runSync("updatePassword", inMap);
    if (ServiceUtil.isError(resultPasswordChange)) {
        return "requirePasswordChange";  // → checkLogin treats as success
    }
    userLogin.refresh();
}

// After password change succeeds, session is established:
return doMainLogin(request, response, userLogin, userLoginSession);

Call Stack (from OFBiz server log during exploit):

RequestHandler      → extensionCheckLogin
LoginWorker         → checkLogin (LoginWorker.java:347)
LoginWorker         → login (LoginWorker.java:520 → userLogin service)
LoginWorker         → login (LoginWorker.java:550 → updatePassword service)
LoginWorker         → doMainLogin (LoginWorker.java:611)

5c. Fix (Patched Version — 24.09.06)

The fix consists of three commits:

Commit 6516157 — Remove client-controlled requirePasswordChange parameter:

Commit 771efc4 — Add ENTITY_MAINT permission check:

// ProgramExport.groovy (24.09.06) — permission check added
if (security.hasPermission('ENTITY_MAINT', session)) {
    // ... all Groovy execution logic wrapped inside this check ...
}

Commit c0592a3 — Add Groovy sandbox:

The patched ProgramExport.groovy adds:

• SecureASTCustomizer with a strict import whitelist (9 OFBiz entity classes only)
• setIndirectImportCheckEnabled(true) — prevents referencing non-whitelisted classes
• Receiver whitelist restricting method calls to OFBiz entity operations
• Regex blocklist detecting 40+ dangerous patterns (Runtime, ProcessBuilder, .execute(), etc.)
• Statement blacklist (while, for, switch)
• Method definition blocked

5d. Impact

Exploitation grants the attacker arbitrary OS command execution as the OFBiz process user. In the tested environment, OFBiz ran as root (uid=0), granting full system control. The attacker can read and modify all data in the OFBiz database (including user credentials, financial records, customer PII, and order data), install backdoors, pivot to other systems on the network, and completely compromise the business operations running on OFBiz.

The vulnerability is particularly severe because Apache OFBiz ships with over ten demo user accounts (admin, flexadmin, demoadmin, ltdadmin, bizadmin, etc.) all sharing the well-documented default password ofbiz. Many deployments — especially development, staging, and recently-installed production instances — retain these default credentials. The vulnerability is also present in the Atlassian JIRA supply chain, as OFBiz was historically integrated into JIRA’s backend. Any internet-facing OFBiz instance with default or known credentials is trivially exploitable with a single HTTP request.

6. Proof-of-Concept

6a. PoC Code

Download poc_cve_2026_45434.py (enterprise email verification required)

6b. Reproduce Instructions

Prerequisites:

• Apache OFBiz < 24.09.06 with demo data loaded
• Network access to port 8443 (HTTPS) or 8080 (HTTP)
• Python 3 with requests library

Setup (vulnerable target):

# Download and extract OFBiz 24.09.05
wget https://archive.apache.org/dist/ofbiz/apache-ofbiz-24.09.05.zip
unzip apache-ofbiz-24.09.05.zip
cd apache-ofbiz-24.09.05

# Initialize Gradle wrapper, load demo data, and start
bash gradle/init-gradle-wrapper.sh
./gradlew loadAll
./gradlew ofbiz

Steps to reproduce:

1. Verify the target is running:

   curl -ks https://<TARGET>:8443/webtools/control/main | grep -c "OFBiz"
   

2. Set requirePasswordChange=Y on the target account (simulating an admin lockdown). This can be done via the OFBiz admin UI (Party Manager → User Login → Edit) or via SQL/Groovy if you have another admin session:

   def ul = EntityQuery.use(delegator).from("UserLogin")
       .where("userLoginId", "ltdadmin1").queryOne()
   ul.set("requirePasswordChange", "Y")
   delegator.store(ul)
   

3. Verify normal login is blocked — the account cannot access ProgramExport:

   # Login and try to access ProgramExport — should return 401
   curl -ks -c cookies.txt -d "USERNAME=ltdadmin1&PASSWORD=ofbiz" \
       https://<TARGET>:8443/webtools/control/login
   curl -ks -b cookies.txt -o /dev/null -w "HTTP %{http_code}\n" \
       https://<TARGET>:8443/webtools/control/ProgramExport
   # Expected: HTTP 401 — account is locked behind password change
   

4. Run the exploit — bypass the restriction and execute code in one request:

   python3 poc_CVE-2026-45434.py https://<TARGET>:8443 -c "id" \
       -u ltdadmin1 -p ofbiz
   

5. Expected output:

   [*] Target: https://<TARGET>:8443
   [*] Command: id
   [+] RCE SUCCESS (HTTP 200)
   [+] Password changed to: Pwn3d!12345
   
   uid=0(root) gid=0(root) groups=0(root)
   

Note: The exploit changes the password of the target user account as a side effect (the requirePasswordChange=Y request parameter triggers an inline password change as part of the bypass). The default new password is Pwn3d!12345. Use the -u, -p, and --new-password flags to control which account is used and what the new password is set to.

6c. Test Results

Test environment: Apache OFBiz 24.09.05 on OpenJDK 17.0.18 (Ubuntu 24.04, containerized)

Setup: requirePasswordChange=Y set on ltdadmin1 account via admin Groovy (simulating admin-enforced password change lockout).

Tests A and B confirm the account is properly locked behind the forced password change — neither session-based nor direct-POST login grants access to ProgramExport. Test C demonstrates the exploit bypasses this restriction and achieves RCE in a single request.

Test C output:

RCE_PROOF:uid=0(root) gid=0(root) groups=0(root)

6d. Patched System Verification

Apache OFBiz 24.09.06 addresses the vulnerability through three complementary fixes:

1. The requirePasswordChange parameter is no longer read from the HTTP request — it is read exclusively from the database userLogin record
2. All login() return paths that previously returned "requirePasswordChange" now return "error", which checkLogin() correctly handles as an authentication failure
3. ProgramExport.groovy requires ENTITY_MAINT permission and enforces a strict Groovy sandbox

With 24.09.06, the same PoC request returns HTTP 401 (Unauthorized) and no Groovy code is executed.

7. Detection

Note: The detection rules below are provided as a starting point. Validate and tune them in your own environment before deploying to production.

7a. Network-Based Detection

Signature-Based Detection

The attack is identifiable by the following characteristics in a single HTTP POST request:

1. URI path contains /webtools/control/ProgramExport (or /control/ProgramExport under any OFBiz webapp)
2. POST body contains the requirePasswordChange=Y parameter alongside USERNAME and PASSWORD parameters
3. POST body contains a groovyProgram parameter with Groovy code

The combination of requirePasswordChange=Y with groovyProgram in a single request to ProgramExport is not seen in legitimate OFBiz usage — normal password changes go through the ChangePassword form, which does not submit Groovy code.

Suricata Rules

# CVE-2026-45434: OFBiz Auth Bypass + RCE via ProgramExport
# Detects the combined auth bypass (requirePasswordChange) and code execution (groovyProgram)
alert http any any -> $HOME_NET any (msg:"CVE-2026-45434 Apache OFBiz Auth Bypass + RCE via ProgramExport"; \
  flow:to_server,established; \
  http.method; content:"POST"; \
  http.uri; content:"/control/ProgramExport"; \
  http.request_body; content:"requirePasswordChange=Y"; \
  http.request_body; content:"groovyProgram"; \
  reference:cve,2026-45434; \
  classtype:web-application-attack; \
  sid:2026454341; rev:1;)

# CVE-2026-45434: OFBiz ProgramExport Groovy code execution with OS commands
# Detects Groovy code containing common OS command execution patterns
alert http any any -> $HOME_NET any (msg:"CVE-2026-45434 Apache OFBiz ProgramExport Groovy RCE (execute)"; \
  flow:to_server,established; \
  http.method; content:"POST"; \
  http.uri; content:"/control/ProgramExport"; \
  http.request_body; content:"groovyProgram"; \
  http.request_body; content:".execute()"; \
  reference:cve,2026-45434; \
  classtype:web-application-attack; \
  sid:2026454342; rev:1;)

# CVE-2026-45434: OFBiz requirePasswordChange parameter abuse on any endpoint
# Broader detection — flags the auth bypass parameter on any OFBiz webtools endpoint
alert http any any -> $HOME_NET any (msg:"CVE-2026-45434 Apache OFBiz requirePasswordChange Auth Bypass Attempt"; \
  flow:to_server,established; \
  http.method; content:"POST"; \
  http.uri; content:"/webtools/control/"; \
  http.request_body; content:"requirePasswordChange=Y"; \
  http.request_body; content:"USERNAME"; \
  http.request_body; content:"newPassword"; \
  reference:cve,2026-45434; \
  classtype:web-application-attack; \
  sid:2026454343; rev:1;)

7b. Host-Based Detection (YARA)

The following YARA rules detect vulnerable and patched versions of the affected OFBiz source and compiled files. Because OFBiz is a Java application distributed as source + compiled classes in JARs, these rules target string patterns present in the Java source files and compiled .class bytecode (Java class files embed method names, string literals, and class references as UTF-8 constants).

Vulnerability Detection Rule

Matches the vulnerable LoginWorker.java pattern where requirePasswordChange is read from the HTTP request parameter (client-controlled) and the checkLogin() method only compares against the "error" string:

rule CVE_2026_45434_LoginWorker_Vulnerable
{
    meta:
        description = "Detects vulnerable Apache OFBiz LoginWorker (< 24.09.06) — requirePasswordChange read from request parameter"
        cve = "CVE-2026-45434"
        component = "LoginWorker"
        severity = "high"
        type = "vulnerability"

    strings:
        // login() reads requirePasswordChange from HTTP request (attacker-controlled)
        $vuln_param = "request.getParameter(\"requirePasswordChange\")" ascii

        // checkLogin() only compares login() return against "error" — misses "requirePasswordChange"
        $vuln_check = "\"error\".equals(login(request, response))" ascii

        // The string "requirePasswordChange" returned by login() as a non-error value
        $return_rpc = "return \"requirePasswordChange\"" ascii

        // Class identifier
        $class_name = "LoginWorker" ascii

    condition:
        $class_name and $vuln_param and ($vuln_check or $return_rpc)
}

Patch Verification Rule

Matches patterns unique to the patched LoginWorker.java (24.09.06+), where the requirePasswordChange flag is read from the database entity instead of the HTTP request, and the login() method no longer returns "requirePasswordChange":

rule CVE_2026_45434_LoginWorker_Patched
{
    meta:
        description = "Detects patched Apache OFBiz LoginWorker (>= 24.09.06) — requirePasswordChange read from database"
        cve = "CVE-2026-45434"
        component = "LoginWorker"
        severity = "informational"
        type = "patch_verification"

    strings:
        // Patched code reads flag from database entity, not request parameter
        $db_check = "userLogin.getString(\"requirePasswordChange\")" ascii

        // Class identifier
        $class_name = "LoginWorker" ascii

        // The vulnerable request.getParameter pattern should be absent
        $vuln_param = "request.getParameter(\"requirePasswordChange\")" ascii

    condition:
        $class_name and $db_check and not $vuln_param
}

ProgramExport Sandbox Detection Rule

Detects whether ProgramExport.groovy has the Groovy sandbox applied (patched) or is unsandboxed (vulnerable):

rule CVE_2026_45434_ProgramExport_Vulnerable
{
    meta:
        description = "Detects unsandboxed Apache OFBiz ProgramExport.groovy (< 24.09.06)"
        cve = "CVE-2026-45434"
        component = "ProgramExport"
        severity = "high"
        type = "vulnerability"

    strings:
        // GroovyShell usage without sandbox
        $groovy_shell = "new GroovyShell" ascii
        $groovy_eval = "shell.evaluate" ascii

        // File identifier
        $file_name = "ProgramExport" ascii

        // Sandbox indicators (absent in vulnerable version)
        $sandbox_ast = "SecureASTCustomizer" ascii
        $sandbox_perm = "hasPermission" ascii

    condition:
        $file_name and $groovy_shell and $groovy_eval and not $sandbox_ast and not $sandbox_perm
}

rule CVE_2026_45434_ProgramExport_Patched
{
    meta:
        description = "Detects sandboxed Apache OFBiz ProgramExport.groovy (>= 24.09.06)"
        cve = "CVE-2026-45434"
        component = "ProgramExport"
        severity = "informational"
        type = "patch_verification"

    strings:
        $file_name = "ProgramExport" ascii
        $sandbox_ast = "SecureASTCustomizer" ascii
        $sandbox_perm = "ENTITY_MAINT" ascii

    condition:
        $file_name and $sandbox_ast and $sandbox_perm
}

Usage

# Scan OFBiz source tree for vulnerable LoginWorker
yara -s CVE_2026_45434_rules.yar /path/to/ofbiz-framework/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/

# Scan OFBiz webtools for vulnerable ProgramExport
yara -s CVE_2026_45434_rules.yar /path/to/ofbiz-framework/framework/webtools/groovyScripts/

# Scan an OFBiz installation directory recursively
yara -rs CVE_2026_45434_rules.yar /opt/ofbiz/

Rule Summary

8. References