Jpom's Control-Plane Footprint Fits a Focused Authentication Review
Jpom manages builds, deployments and scripts for connected servers. A small external inventory can still represent substantial control over production systems.
The following observations used sub_type=all, page 1 and page size 1 on 2026-11-13 between 07:40 and 07:42 Asia/Shanghai.
| Query | Matching assets |
|---|---|
app="Jpom" |
242 |
title="Jpom" |
227 |
The counts are close. That gives analysts two candidate views without a large unexplained gap, but neither view proves the running version or authentication policy.
Why the small pool matters
CVE-2026-120201 affects Jpom 2.10.0 through 2.11.12. An attacker can inject query conditions into the JPOM-USER-TOKEN header. A value such as is not null can match a user record in Hutool's Condition parser.
Successful matching leads to super-administrator access. Jpom's script features can then run commands on managed nodes. The impact extends beyond the web application because the control plane usually holds deployment and SSH credentials.
The 242 app matches are few enough for a direct ownership and version campaign. They are not automatically vulnerable.
Review each candidate
Confirm the Jpom page, product version and owning team. Record whether the endpoint is internet-facing, behind a VPN or protected by an identity-aware proxy.
Review the JPOM-USER-TOKEN handling in the deployed build. Test malformed values in a non-production environment and confirm that they produce an authentication failure rather than a broad database match.
Inspect Jpom users, managed nodes, scripts and recent executions. Compare authentication events with known token issuance and session records.
Response priority
Start with internet-reachable instances and those managing production servers. Then cover internal instances with many nodes or powerful script permissions.
Apply a fixed Jpom release verified with the upstream project. The advisory lists affected versions but no patched version, so do not infer a safe tag from the affected range.
Until the fix is deployed, restrict access to trusted networks and limit script execution. Rotate Jpom credentials and managed-node keys after any suspicious administrative event.
Detection evidence
Review audit logs for logins that do not correspond to a real session, new administrator actions, script creation and deployment jobs. Check managed hosts for commands that did not originate from an approved job.
The external count cannot show whether a token injection succeeded. The decisive evidence is in the application database, audit trail and managed-node process history.
Record the result
Store the dorks, timestamp and totals with the host inventory. Keep candidate, version-confirmed and compromise-confirmed states separate. A Jpom title alone should not appear as a vulnerable server in a management report.
Top comments (0)