Important Notice: JumpServer Vulnerability Advisory and Remediation (JS-2026.09.09)
In August 2026, the JumpServer open-source project team received a vulnerability report from a security researcher. Upon verification, the following vulnerability was identified:
- JumpServer Access Key exposure caused by improper API query filtering — GHSA-6rp5-ff2m-qfrm. Details: GHSA-6rp5-ff2m-qfrm. Rated High, CVSS v3.1 base score 8.8 (
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). No CVE ID has been assigned at the time of publication.
Vulnerability Details
An improper access control issue exists in the API filtering and serializer selection logic of JumpServer.
- JumpServer previously applied a generic filtering backend to common API list views. Under certain query conditions, that backend could negate the entire queryset condition rather than only the client-supplied filtering expression. Authorization and ownership constraints already applied to the queryset were affected as a result.
- Separately, serializer selection could be influenced by a client-controlled query parameter. An API request could therefore be served by a serializer intended for a different operation, exposing fields that are not normally included in list responses.
Combined, these behaviors allow an authenticated user with limited privileges to reach AccessKey records outside their authorization scope. In some cases the returned data includes AccessKey secrets belonging to other users or to internal JumpServer components.
Exploitation Conditions
Any logged-in ordinary user can append a specific query parameter to an API request and retrieve administrator Access Keys beyond their authorization scope. No additional privileges or user interaction are required.
Because Access Keys are long-lived credentials, an exposed key may grant ongoing access to JumpServer APIs with the permissions of its owner. If the exposed key belongs to an account or internal component that carries additional permissions, the impact scales accordingly.
Affected Versions
| Version Line | Affected Versions | Safe Versions |
|---|---|---|
| JumpServer V3 | >= v3.7.0 and < v3.10.23 LTS | >= v3.10.23 LTS |
| JumpServer V4 | >= v4.0.0 and < v4.10.19 LTS | >= v4.10.19 LTS |
Remediation
Users are strongly advised to upgrade JumpServer (both Community Edition and Enterprise Edition) to a safe version as soon as possible.
In the safe versions, JumpServer has implemented the following fixes:
- Removed the generic
_rel=or/notqueryset manipulation backend from common API views. - Removed support for client-controlled serializer action selection. Serializer selection now relies on the server-side view action.
Temporary Workaround: Disable the Filtering Parameter in Nginx
If an immediate upgrade is not possible, disable the relevant filtering parameter in the Nginx configuration:
- If HTTPS is enabled, edit
/opt/jumpserver/config/nginx/lb_http_server.conf. - If HTTPS is not enabled, edit
/etc/nginx/conf.d/http_server.confinside thejms_webcontainer, then commit the container to persist the change.
Restart the jms_web container after the update. Add the following rule to the existing location / block:
location / {
if ($args ~* "(^|&)(_|%5f)(r|%72)(e|%65)(l|%6c)=") {
return 400;
}
.....
}
The rule matches both the literal _rel= parameter and its URL-encoded form %5Frel=, so requests cannot bypass it through encoding.
Note: This workaround rejects any request carrying the
_relquery parameter and may affect functionality that legitimately relies on this filter. Treat it as a temporary measure and plan the upgrade.
Verify the Workaround
After the change takes effect, run the following commands against your JumpServer address:
curl -sk -o /dev/null -w '%{http_code}\n' 'http://<JumpServer address>/api/v1/users/users/?_rel=not' # expect 400
curl -sk -o /dev/null -w '%{http_code}\n' 'http://<JumpServer address>/api/v1/users/users/?%5Frel=not' # expect 400
curl -sk -o /dev/null -w '%{http_code}\n' 'http://<JumpServer address>/api/v1/users/users/' # expect 401/403
The first two requests must return 400. The third confirms that normal API access still behaves as expected.
If Immediate Upgrade Is Not Possible
- Restrict access to JumpServer APIs to trusted users and networks.
- Review API access logs for requests containing
_relor%5Frelquery parameters. - Rotate user Access Keys and internal component Access Keys if unauthorized access is suspected. See JumpServer API Authentication: A Complete Guide for how Access Keys are issued and rotated.
Acknowledgments
We would like to thank GitHub user @sajjadhaqi from Smart Oasis for promptly reporting this vulnerability to the JumpServer open-source community.
We extend our gratitude to all security researchers for their continued contributions to the security of the JumpServer open-source project.