CVE-2025-27095: Jumpserver Privilege Escalation Vulnerability

CVE-2025-27095 Overview

CVE-2025-27095 affects JumpServer, an open source bastion host and operations security audit system developed by Fit2cloud. The vulnerability allows a low-privileged authenticated user to abuse the Kubernetes session feature by manipulating the kubeconfig file. An attacker can redirect Kubernetes API requests to an external server under their control and capture the Kubernetes cluster token in transit. The captured token can then be reused to access the target cluster outside the audited JumpServer session. The issue is resolved in JumpServer versions 4.8.0 and 3.10.18.

Critical Impact
An authenticated low-privileged JumpServer user can exfiltrate Kubernetes cluster tokens by redirecting API traffic to an attacker-controlled endpoint, resulting in unauthorized cluster access.

Affected Products

Fit2cloud JumpServer versions prior to 3.10.18 (3.x branch)
Fit2cloud JumpServer versions prior to 4.8.0 (4.x branch)
Deployments exposing the Kubernetes session (K8s connect) feature to non-admin accounts

Discovery Timeline

2025-03-31 - CVE-2025-27095 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-27095

Vulnerability Analysis

JumpServer provides a Kubernetes session capability that brokers kubectl traffic between an authenticated user and a target cluster. The session relies on a server-side kubeconfig file that embeds the cluster API server URL and the authentication token used to reach it. Prior to the fixed releases, the platform did not sufficiently restrict user-supplied modifications to the kubeconfig used within the session context. This falls under [CWE-266: Incorrect Privilege Assignment], because a low-privileged role gains the ability to influence configuration used with elevated cluster credentials. The result is a credential disclosure primitive that undermines the audit and isolation guarantees a bastion host is meant to provide.

Root Cause

The underlying flaw is improper enforcement of trust boundaries around the kubeconfig used by the Kubernetes session feature. A low-privileged JumpServer user can alter the server field or related endpoint parameters so that the embedded cluster token is transmitted to an attacker-controlled destination rather than the legitimate Kubernetes API server. JumpServer treated the modified configuration as valid session state instead of restricting it to administrator-defined values.

Attack Vector

Exploitation requires network access to the JumpServer web interface and a valid low-privileged account that can launch a Kubernetes session. The attacker configures the session so the kubeconfig points at an HTTPS listener they operate. When JumpServer or the user's client issues API requests, the bearer token is delivered to the attacker's server in the Authorization header. The attacker then replays the token directly against the real Kubernetes API server, bypassing JumpServer audit logging. No specialized exploitation tooling is required, and no user interaction beyond the attacker's own session is needed.

No public proof-of-concept code is available. See the JumpServer GitHub Security Advisory GHSA-5q9w-f4wh-f535 for vendor technical details.

Detection Methods for CVE-2025-27095

Indicators of Compromise

Outbound HTTPS connections from JumpServer hosts to Kubernetes API endpoints that are not part of the sanctioned cluster inventory.
Kubernetes audit log entries showing API calls authenticated with a valid service account token but originating from source IP addresses outside the JumpServer network range.
JumpServer session records referencing Kubernetes assets where the effective server URL differs from the asset's registered API endpoint.

Detection Strategies

Baseline the set of Kubernetes API server hostnames JumpServer is expected to contact and alert on any deviation from that allow-list.
Correlate JumpServer session start events for Kubernetes assets with the destination IPs of subsequent egress traffic from the JumpServer host.
Review Kubernetes audit.k8s.io logs for token reuse patterns where the same bearer token is presented from multiple unrelated source IPs within a short window.

Monitoring Recommendations

Forward JumpServer application and session logs, along with Kubernetes API server audit logs, to a centralized analytics platform for cross-source correlation.
Monitor low-privileged user accounts for unexpected use of the Kubernetes connect feature, especially against production clusters.
Alert on new or rotated service account tokens observed authenticating from previously unseen network locations.

How to Mitigate CVE-2025-27095

Immediate Actions Required

Upgrade JumpServer to version 3.10.18 on the 3.x branch or 4.8.0 on the 4.x branch as documented in the vendor advisory.
Rotate all Kubernetes cluster tokens and service account credentials that were reachable through JumpServer sessions prior to patching.
Audit the JumpServer role assignments and remove Kubernetes asset access from users that do not require it.

Patch Information

Fit2cloud addressed the vulnerability in JumpServer 4.8.0 and 3.10.18. Both releases restrict user manipulation of the kubeconfig used in Kubernetes sessions so the API server destination cannot be redirected by a low-privileged account. Refer to the GitHub Security Advisory GHSA-5q9w-f4wh-f535 for the full remediation details and upgrade guidance.

Workarounds

Restrict access to the Kubernetes session feature to trusted administrator accounts until the upgrade is completed.
Place network egress controls on JumpServer hosts so they can only reach the approved Kubernetes API server endpoints.
Enforce short-lived, scoped service account tokens for clusters accessed through JumpServer to limit the value of any captured credential.

bash

# Example egress allow-list enforced with iptables on the JumpServer host.
# Replace the placeholder addresses with the real Kubernetes API endpoints.
iptables -A OUTPUT -p tcp -d 10.0.10.5 --dport 6443 -j ACCEPT
iptables -A OUTPUT -p tcp -d 10.0.20.5 --dport 6443 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 6443 -j REJECT