On this page (6 sections)
A critical authentication bypass has been published for Jpom. According to the GitHub advisory, versions 2.10.0 through 2.11.12 let an unauthenticated attacker gain super-administrator access by sending a crafted value in the JPOM-USER-TOKEN header, and then execute commands through Jpom's script features.
If you run Jpom anywhere, especially on an address reachable from the internet, treat this as urgent. The advisory lists no patched version at the time of writing, so the first steps are about reducing exposure rather than simply upgrading.
What happened
The flaw was published on October 31, 2026 through the National Vulnerability Database and the GitHub Advisory Database. The description is short: an attacker can inject query conditions into the JPOM-USER-TOKEN header and obtain super-administrator access without any credentials.
The CVSS v4 metrics in the advisory describe a network attack with low complexity, no attack requirements, no privileges and no user interaction, with high impact on confidentiality, integrity and availability of the vulnerable system. That combination is why the score is 9.3.
How the weakness works
The weakness is classified as CWE-943, which covers improper neutralization of special elements in a data query language. In plain terms, input that should be treated as plain data is allowed to act as part of a query condition.
Per the advisory, an attacker can send a value such as 'is not null' in the JPOM-USER-TOKEN header. The Hutool library's Condition parser treats that text as an operator, and the result is super-administrator access for an unauthenticated attacker. The advisory does not spell out the internal steps between those two points, so we do not describe them further.
Once in, the advisory says the attacker can execute commands through Jpom's script features. The research does not describe what else Jpom manages or what an attacker could reach from there, so the wider impact on connected systems is unconfirmed. Assume that command execution on the Jpom host is the minimum consequence.
The advisory points to the login interceptor in the v2.11.12 source, LoginInterceptor.java, and to the project's issue 121 for reference.
Who is affected
Anyone running a Jpom server in the 2.10.0 through 2.11.12 range. Realistic exposure is highest when:
- The Jpom web interface is reachable from the public internet or a large internal network.
- Jpom is used in production, so command execution on it carries more risk.
- The installation has been left running for a long time without version tracking, which is common for internal tools.
The advisory does not say whether versions older than 2.10.0 or newer than 2.11.12 are affected. Do not assume they are safe; check the project for updates and confirm with the maintainers.
How to check your exposure
Start by finding every Jpom instance you own and noting its version. The version is normally shown in the web interface or in the name of the installed package or archive; check your deployment notes if you are unsure.
Next, see which instances can be reached from outside. From a machine outside your network, confirm whether the Jpom login page loads. The command below sends a read-only HTTP HEAD request and prints the response headers; replace the placeholder with your own address and only test systems you own:
curl -I http://YOUR-JPOM-HOST:PORT/Any HTTP response means the interface is reachable from where you ran the command. If it is reachable from the internet and runs an affected version, prioritize it.
Then review for signs of misuse. Look in Jpom's own logs, your reverse proxy logs and your system logs for unexpected logins, new or changed scripts, and commands you did not run. If a reverse proxy logs request headers, an unusual JPOM-USER-TOKEN value is worth investigating. The research gives no confirmed indicators of compromise, so absence of evidence is not proof of safety.
What to do now
Because no fixed version is listed, combine containment with close tracking of the project for a patch.
0 of 7 done
For general guidance if you suspect a compromise, see Website hacked: what to do.
Detection and monitoring afterwards
After restricting access, keep watching. Alert on logins to Jpom from unfamiliar addresses, on creation or modification of scripts, and on unexpected outbound connections from the Jpom host. Keep logs long enough to look back once a fix and more details are published.
You can also confirm from the outside that management interfaces are no longer exposed by running a Webforta Scan on sites you have verified, and track certificate, DNS and uptime changes with Webforta Monitor. These help you notice exposure and change; they do not by themselves fix or detect this specific flaw.
The broader lesson is to keep administration interfaces off the public internet wherever you can. For more on the basics, see Small business website security.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.