- The Mess: PowerJob Worker exposes a container-deployment endpoint without authentication. Anyone who can reach the default transport port can potentially turn that endpoint into remote code execution.
The bug is tracked as CVE-2026-75430.
It was publicly disclosed on September 4 and carries a CVSS 9.8 Critical rating.
The vulnerable component is PowerJob Worker 5.1.2, with earlier releases also believed to be affected.
The problem is brutally simple.
PowerJob exposes:
/worker/deployContainer
on its default transport port, 27777, without requiring authentication.
That endpoint accepts a deployment request containing an attacker-controlled downloadURL.
The Worker can then retrieve the supplied JAR and load it.
That’s not a harmless API mistake.
That’s a remote code execution path.
- The Damage: An unauthenticated attacker who can reach the Worker can potentially execute arbitrary code with the privileges of the PowerJob process and take control of the underlying host.
PowerJob is a distributed task scheduling and execution platform.
That makes the Worker particularly interesting from an attacker’s perspective.
The Worker is supposed to execute jobs.
Give an attacker the ability to control what the Worker loads, and the distinction between “scheduled workload” and “attacker code” starts disappearing.
The Endpoint Was the Problem
The vulnerable request reaches the WorkerActor handler.
According to the available technical analysis, the handler accepts a ServerDeployContainerRequest containing a downloadURL without first establishing that the caller is authorized to perform the operation.
The supplied JAR is subsequently handled by PowerJob’s container mechanism.
The chain can reach URLClassLoader and Spring’s ClassPathXmlApplicationContext, allowing attacker-controlled Java code to execute during initialization.
No stolen password is required.
No browser exploit is required.
No victim needs to click anything.
The attacker needs network access to the Worker.
That’s it.
Port 27777 Is the Red Flag
PowerJob Workers normally communicate with the scheduling infrastructure over their transport port.
The default is:
TCP 27777
If that port is exposed beyond the trusted network, the vulnerable endpoint becomes remotely reachable.
That creates an especially ugly deployment problem.
A service can be perfectly functional, correctly registered with its scheduler and still be dangerously exposed if administrators treat the Worker like an ordinary application server and allow unnecessary network access.
The safest architecture is to keep Workers reachable only by the systems that actually need to communicate with them.
Internet exposure is a completely different story.
This Isn’t an Authentication Bypass
There’s an important distinction here.
CVE-2026-75430 isn’t a sophisticated authentication bypass.
The vulnerable functionality simply doesn’t authenticate the caller.
The CVSS vector reflects that:
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Network reachable.
Low complexity.
No privileges.
No user interaction.
And high impact across confidentiality, integrity and availability.
That is why the score lands at 9.8.
The Worker Is the Execution Plane
This is the part that makes the vulnerability more interesting than a generic unauthenticated endpoint.
PowerJob separates scheduling from execution.
The server decides what needs to run.
The Worker executes it.
That means compromising a Worker can give an attacker something much more useful than access to a random HTTP service.
They land directly on a machine whose job is to execute workloads.
Depending on the Worker process privileges and surrounding network permissions, that can become a launch point for lateral movement.
Credentials stored on the host, internal services, shared files and reachable databases can all become potential secondary targets.
The CVE itself doesn’t magically grant access to every system around the Worker.
But it gives the attacker a foothold on the execution infrastructure.
That’s enough to make defenders uncomfortable.
A Public PoC Has Already Appeared
The vulnerability is barely a day old and references already point to a public GitHub/Gist exploit resource.
The CVE record lists a repository named:
CVE-2026-75430_PowerJob_worker_deployContainer_RCE
alongside source-code references showing the vulnerable WorkerActor and OmsContainerFactory components.
That changes the urgency.
This isn’t simply a CVE that exists in a database while researchers wait for somebody to figure out how the code works.
The technical path is already documented publicly.
There is still no evidence in the sources reviewed that CVE-2026-75430 is being actively exploited in the wild.
It is also not currently listed in the CISA Known Exploited Vulnerabilities catalog.
That’s good news.
It also won’t remain reassuring if vulnerable Workers are sitting on publicly reachable networks.
PowerJob Server Has Another Problem
There is an unpleasant companion vulnerability.
IONIX also identified CVE-2026-75431, affecting PowerJob Server 5.1.2 and earlier.
This one involves a predictable JWT signing key and can allow an unauthenticated attacker to forge administrator tokens.
The reported CVSS score is 9.1.
That creates a potentially nasty combination:
PowerJob Server authentication weakness + PowerJob Worker unauthenticated code execution.
They are separate CVEs and should not be presented as one vulnerability.
But organizations running the platform should audit both sides of the deployment rather than patching only the Worker.
What Defenders Should Check Now
If PowerJob is running in your environment, don’t start by asking whether somebody has exploited the CVE.
Start by asking whether the vulnerable service was reachable.
Check:
- PowerJob Worker version;
- TCP/27777 exposure;
- firewall and security-group rules;
- unexpected connections to Worker hosts;
- requests hitting
/worker/deployContainer; - unexpected JAR downloads;
- recently created or modified Java artifacts;
- unusual child processes spawned by the Worker;
- outbound connections from Worker machines to previously unseen hosts.
Also inspect whether the Worker runs with unnecessary operating-system privileges.
Remote code execution under a tightly restricted service account is still bad.
Remote code execution under a privileged account is considerably worse.
The Fix
PowerJob 5.1.2 and earlier installations should be treated as exposed if the Worker transport port is reachable by untrusted systems.
Until an appropriate vendor fix is applied, restrict access to the Worker transport port at the network layer and do not expose it to the public Internet.
There is currently no CISA KEV entry for CVE-2026-75430, and public exploit references have appeared almost immediately after disclosure.
- The Fix: Upgrade to a vendor-fixed release when available, restrict TCP/27777 to trusted PowerJob infrastructure, investigate requests to
/worker/deployContainer, and audit both PowerJob Worker and Server installations.
Bugstoday Opinion
This is the kind of vulnerability that makes security engineers stare at an endpoint and ask:
“Why was this ever reachable without authentication?”
A job scheduler has one job.
Schedule work.
A Worker has another.
Execute it.
Giving an unauthenticated remote caller a way to feed code into the execution component is not an exotic attack chain. It’s a straight line.
And someone has already published the technical details.
No active exploitation has been confirmed yet.
That’s the window.
Patch it while the exploit is still a research artifact instead of waiting for it to become someone’s automated scanner.
Because once scanners start looking for port 27777, the question won’t be whether PowerJob has an RCE.
It will be whether yours is reachable.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
MITRE CVE-2026-75430
NVD CVE-2026-75430
PowerJob GitHub Repository
PowerJob Worker — WorkerActor.java
PowerJob Worker — OmsContainerFactory.java
IONIX Threat Center
Positive Technologies PT-2026-85781
