CVE-2025-62712: Unauthorized Access to Connection Tokens in JumpServer PAM

Affected Product

JumpServer is an open-source Privileged Access Management (PAM) solution that helps organizations secure and manage access to their IT infrastructure. It provides centralized authentication, authorization, and auditing capabilities for SSH, RDP, and other remote access protocols.

Vulnerability Overview

The /api/v1/authentication/super-connection-token/ API endpoint was not properly checking permissions of the calling user. A user with minimal privileges could query this endpoint and retrieve all existing connection tokens, including those belonging to other users. This behavior allowed an attacker to intercept and use valid tokens, potentially gaining unauthorized access to all systems that are managed via JumpServer PAM.

Steps to Reproduce

1. Log in as any user with the permissions listed below
2. Send a GET request to: /api/v1/authentication/super-connection-token/?limit=100
3. Observe that the API response contains active connection tokens for multiple users

Figure 1: API request and response showing visible connection tokens from other users

Figure 2: Minimal permissions required to reproduce the vulnerability

The vulnerability can be exploited by any user with the authentication.view_connectiontoken permission.

In a typical JumpServer deployment, this permission is granted to regular PAM operators. A standard operator role typically includes the following permissions:

• authentication.add_accesskey
• authentication.add_connectiontoken
• authentication.add_passkey
• authentication.add_temptoken
• authentication.change_accesskey
• authentication.change_passkey
• authentication.change_temptoken
• authentication.delete_accesskey
• authentication.delete_passkey
• authentication.expire_connectiontoken
• authentication.reuse_сonnectiontoken
• authentication.view_accesskey
• authentication.view_connectiontoken
• authentication.view_passkey
• authentication.view_temptoken
• perms.view_myassets
• rbac.view_filemanager
• rbac.view_webterminal
• rbac.view_workbench

Expected Behavior

Low-privilege users should not have access to other users' connection tokens. The endpoint /api/v1/authentication/super-connection-token/ should be restricted to administrative roles only, with explicit permission checks for the "list" and "retrieve" actions.

Impact Analysis

An authenticated, non-privileged user can retrieve connection tokens belonging to other users and use them to initiate connections to managed assets on behalf of the original token owners, resulting in unauthorized access and privilege escalation across sensitive systems.

When a user operator accesses an asset published via JumpServer PAM, a one-time use connection token is generated. This token is then used legitimately to authenticate to the target service. Because of the flawed access control in the super-connection-token API endpoint, an attacker can retrieve access tokens of other users. If the attacker intercepts a token before it is used by the legitimate user, they can use it to gain unauthorized access to the victim's session and connected systems. This issue is particularly exploitable with the ssh_guide connection type, which introduces a delay while the legitimate user enters their SSH credentials. This time window provides attackers with additional opportunities to intercept and abuse tokens. That said, by repeatedly calling the vulnerable API it is possible to intercept tokens generated for other connection types as well.

Root Cause Analysis

The vulnerability stems from an architectural flaw in how permissions are inherited and applied in the JumpServer codebase:

Permission Inheritance Chain

The SuperConnectionTokenViewSet class (GitHub source) handles requests to the super-connection-token/ API endpoint. This class inherits from ConnectionTokenViewSet, which in turn inherits from multiple mixins including AuthFaceMixin, ExtraActionApiMixin, RootOrgViewMixin, and JMSModelViewSet. Both classes use the RBACPermission (GitHub source) as their permission model class.

The SuperConnectionTokenViewSet defines the following RBAC permissions that are specific to the API endpoint (note the 'superconnectiontoken' in the permission names):

rbac_perms = {
    'create': 'authentication.add_superconnectiontoken',
    'renewal': 'authentication.add_superconnectiontoken',
    'check': 'authentication.view_superconnectiontoken',
    'get_secret_detail': 'authentication.view_superconnectiontokensecret',
    'get_applet_info': 'authentication.view_superconnectiontoken',
    'release_applet_account': 'authentication.view_superconnectiontoken',
    'get_virtual_app_info': 'authentication.view_superconnectiontoken',
}

The permissions listed above are administrative and are not usually available for regular PAM operators.

The cause of the vulnerability

Notice that the rbac_perms dictionary lacks definitions for the "list" and "retrieve" verbs. The RBACPermission class has a default permission template (GitHub source) that fills in these missing permissions:

('list', '%(app_label)s.view_%(model_name)s'),
('retrieve', '%(app_label)s.view_%(model_name)s')

These default permissions are merged into the list of permissions defined by the view class in the get_rbac_perms method (GitHub source):

default_perms = self.get_default_action_perms(model_cls)
if '*' not in perms:
    for k, v in default_perms.items():
        perms.setdefault(k, v)

The model_name placeholder in the template is substituted by the name of the model_cls, which is determined in the get_model_cls method (GitHub source):

try:
    queryset = self._queryset(view)
    if isinstance(queryset, list) and queryset:
        model_cls = queryset[0].__class__
    else:
        model_cls = queryset.model

The SuperConnectionTokenViewSet class defines its queryset as follows (GitHub source):

def get_queryset(self):
    return ConnectionToken.objects.all()

As we can see, the model class name is ConnectionToken (not SuperConnectionToken) which makes sense - the API method indeed returns connection tokens, similar to the ConnectionTokenViewSet class, the only difference is that the SuperConnectionTokenViewSet is designed to return all available tokens, whereas the ConnectionTokenViewSet will only return tokens of the calling user.

Thus, when the default permissions are created, their names are resolved to authentication.view_connectiontoken instead of authentication.view_superconnectiontoken. As a result, any user with the authentication.view_connectiontoken privilege can execute the list and retrieve actions on the SuperConnectionTokenViewSet, bypassing the intended access controls.

Remediation Recommendations

Immediate Actions

1. Upgrade Immediately: Update to v3.10.20-lts or v4.10.11-lts to receive the official patch
2. Review Access Logs: Audit connection token access logs for suspicious activity or unauthorized token usage
3. Assess User Permissions: Review all users with authentication.view_connectiontoken permission and assess potential exposure
4. Implement Monitoring: Set up audit logging to detect potential exploitation attempts

Temporary Workaround (If Immediate Patching is Not Possible)

Modify your Nginx configuration to block GET requests on the super-connection API endpoints:

location = /api/v1/authentication/super-connection-token/ {
    if ($request_method = GET) { return 405; }  # Block GET explicitly
    proxy_pass http://jumpserver_backend;
}
location = /api/v1/resources/super-connection-tokens/ {
    if ($request_method = GET) { return 405; }  # Block GET explicitly
    proxy_pass http://jumpserver_backend;
}

Disclosure Timeline

• 20 Oct 2025: Vulnerability discovered and preliminary vulnerability report submitted
• 21 Oct 2025: Additional technical details provided, JumpServer development team releases fixed versions
• 30 Oct 2025: Public disclosure of GitHub Security Advisory and CVE record

Conclusion

This vulnerability demonstrates the importance of explicit permission definitions and thorough security audits of inheritance chains in complex applications. The subtle nature of this flaw—stemming from default permission templates and model name resolution—highlights how security issues can arise from seemingly innocuous architectural decisions.

Organizations using JumpServer should immediately assess their exposure to this vulnerability and work with the JumpServer team to implement appropriate fixes. At SolidPoint, we are committed to responsible disclosure and have worked with the JumpServer maintainers to disclose and address this issue.

We want to thank the JumpServer development team for their professional response and swift remediation of this vulnerability. Their collaborative approach and quick release of patches exemplifies the importance of defenders working together to improve the security of critical infrastructure.