CVE-2026-82630: PowerJob Server-Side Request Forgery Flaw

CVE-2026-82630 Overview

CVE-2026-82630 is a server-side request forgery (SSRF) vulnerability affecting PowerJob versions up to 5.1.2. The flaw resides in the MuConnectionManager.getOrCreateConnection function within powerjob-server/powerjob-server-starter/src/main/java/tech/powerjob/server/web/controller/TestController.java, part of the Transport Endpoint component. Attackers can manipulate the endpoint remotely without authentication to force the PowerJob server into issuing arbitrary outbound requests. The exploit is publicly available, and the maintainers have not yet responded to the disclosure filed via a public issue report. This vulnerability is classified under CWE-918: Server-Side Request Forgery.

Critical Impact
An unauthenticated remote attacker can coerce the PowerJob server to send arbitrary HTTP requests to internal or external systems, enabling internal network reconnaissance, metadata service abuse, and interaction with services otherwise unreachable from the internet.

Affected Products

PowerJob versions up to and including 5.1.2
PowerJob Server component (powerjob-server-starter)
Transport Endpoint handled by TestController.java

Discovery Timeline

2026-08-31 - CVE-2026-82630 published to the National Vulnerability Database (NVD)
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-82630

Vulnerability Analysis

The vulnerability is a server-side request forgery (SSRF) in the PowerJob distributed task scheduling server. PowerJob exposes a TestController endpoint intended to validate transport connections. That endpoint routes user-supplied connection parameters into MuConnectionManager.getOrCreateConnection, which establishes a connection to the caller-specified destination. Because the destination is not restricted to a trusted allowlist, an attacker can direct the server to arbitrary hosts and ports. The exploitation path is fully remote and requires no authentication or user interaction. Public exploit details are referenced on VulDB and in the associated GitHub issue.

Root Cause

The root cause is missing validation of destination targets in a test-connection code path that reaches network I/O. The TestController accepts attacker-controlled host and port values and passes them to MuConnectionManager.getOrCreateConnection without enforcing an allowlist, blocking loopback or link-local ranges, or requiring authentication. Diagnostic transport-test functionality is exposed on a production HTTP interface, which converts an internal debug helper into an unauthenticated SSRF primitive.

Attack Vector

An attacker sends a crafted HTTP request to the PowerJob server's transport test endpoint, specifying a target host and port under their control or inside the victim's internal network. The server then initiates an outbound connection to that target. This can be used to probe internal services, reach cloud instance metadata endpoints such as 169.254.169.254, or pivot against systems that trust the PowerJob server's IP address. Because responses may be reflected or inferred from timing and error behavior, attackers can enumerate reachable internal assets.

No verified proof-of-concept code is included in this advisory. Refer to the GitHub Issue #1181 and VulDB CVE-2026-82630 for technical details.

Detection Methods for CVE-2026-82630

Indicators of Compromise

Unexpected outbound connections originating from the PowerJob server process to internal IP ranges (RFC1918), loopback, or cloud metadata addresses such as 169.254.169.254.
Inbound HTTP requests targeting the PowerJob TestController transport endpoint from untrusted networks or unusual source addresses.
Repeated requests to the transport test endpoint with varying host and port parameters, indicative of SSRF-based scanning.

Detection Strategies

Monitor web access logs on the PowerJob server for requests to controller paths handled by TestController.java, correlating with outbound socket activity.
Implement egress filtering telemetry to identify PowerJob server processes making connections to unexpected destinations.
Deploy signatures on network security tooling to flag HTTP requests carrying internal IP ranges or cloud metadata addresses as parameter values.

Monitoring Recommendations

Ingest PowerJob application, host, and network telemetry into a centralized analytics platform to correlate inbound HTTP activity with outbound network calls from the JVM process.
Alert on any outbound traffic from the PowerJob host to cloud metadata services, private ranges, or non-approved destinations.
Track the frequency and diversity of destinations requested via the transport test endpoint to identify enumeration behavior.

How to Mitigate CVE-2026-82630

Immediate Actions Required

Restrict network access to the PowerJob server management interface using firewall rules or a reverse proxy, exposing it only to trusted operator networks.
Disable or remove the TestController transport endpoint in production deployments if it is not required for operational use.
Enforce strict egress filtering from the PowerJob server so it cannot reach cloud metadata endpoints, internal management planes, or arbitrary internet destinations.

Patch Information

At the time of publication, the PowerJob maintainers have not released a fixed version. The project was notified via GitHub Issue #1181 but has not responded. Monitor the PowerJob GitHub repository for updates beyond version 5.1.2 that address the SSRF in MuConnectionManager.getOrCreateConnection.

Workarounds

Place PowerJob behind an authenticating reverse proxy that blocks requests to the transport test endpoint from untrusted clients.
Apply a host-based network policy that limits PowerJob outbound connections to a defined allowlist of scheduler workers and databases.
If self-patching, add validation in TestController to reject destinations resolving to loopback, link-local, private, or metadata address ranges before invoking MuConnectionManager.getOrCreateConnection.

bash

# Example egress restriction using iptables to block metadata and private ranges
# from the PowerJob server process user (adjust UID as needed)
iptables -A OUTPUT -m owner --uid-owner powerjob -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner powerjob -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner powerjob -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner powerjob -d 192.168.0.0/16 -j REJECT