CVE-2026-71965: CyberPanel 2.4.3 RCE Vulnerability

CVE-2026-71965 Overview

CVE-2026-71965 is an authenticated remote code execution vulnerability in CyberPanel 2.4.3. The flaw resides in the remote backup feature, which fails to verify SSH public keys retrieved from an attacker-supplied remote server address. Authenticated attackers can exploit this weakness to write an attacker-controlled public key directly to /root/.ssh/authorized_keys. This action grants persistent root-level SSH access to the host system. The vulnerability is tracked under [CWE-345: Insufficient Verification of Data Authenticity]. It was fixed in commit eca0c3c of the CyberPanel repository.

Critical Impact
Authenticated attackers can obtain persistent root SSH access to the CyberPanel host by supplying a malicious remote backup server address.

Affected Products

CyberPanel 2.4.3 (prior to commit eca0c3c)
CyberPanel remote backup feature (plogical/remoteBackup.py)
CyberPanel file manager component (filemanager/views.py)

Discovery Timeline

2026-08-10 - CVE-2026-71965 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-71965

Vulnerability Analysis

The vulnerability exists in the CyberPanel remote backup workflow. When a user configures a remote backup destination, the application connects to the specified remote server to establish an SSH trust relationship. During this exchange, CyberPanel retrieves an SSH public key from the remote endpoint without validating its authenticity or origin.

Because the remote server address is user-controllable, an authenticated attacker can point the backup feature at a server they control. That server returns an attacker-chosen public key, which CyberPanel then appends to /root/.ssh/authorized_keys on the host. The attacker can subsequently SSH into the host as root using the corresponding private key.

The issue falls under [CWE-345: Insufficient Verification of Data Authenticity]. The remote backup logic trusts data received from an unauthenticated network peer to modify a security-critical file on the local system.

Root Cause

The root cause is missing verification of the SSH public key returned by the remote backup server. plogical/remoteBackup.py accepts key material from an arbitrary network location and writes it to authorized_keys without confirming that the key belongs to a trusted backup endpoint. There is no cryptographic binding between the configured server identity and the key material used to authorize SSH sessions.

Attack Vector

An attacker with authenticated access to the CyberPanel web interface configures a remote backup destination pointing to a server under their control. The malicious server responds to CyberPanel's key exchange with an attacker-generated public key. CyberPanel writes this key into /root/.ssh/authorized_keys. The attacker then connects to the CyberPanel host over SSH as root using the matching private key, achieving persistent code execution outside the web application context.

python

# Security patch in plogical/remoteBackup.py (commit eca0c3c)
from plogical import CyberCPLogFileWriter as logging
import os
+import re
import requests
import json
import time

Source: GitHub Commit eca0c3c

The patch introduces the re module in remoteBackup.py and adds os to filemanager/views.py, supporting input validation routines that reject malformed or attacker-controlled key material before it reaches the filesystem.

Detection Methods for CVE-2026-71965

Indicators of Compromise

Unexpected new entries appended to /root/.ssh/authorized_keys on CyberPanel hosts.
Outbound connections from the CyberPanel server to unknown remote hosts during backup configuration events.
Successful SSH root logins from IP addresses not associated with legitimate administrators.
Modifications to /root/.ssh/ timestamps that correlate with remote backup configuration activity in CyberPanel logs.

Detection Strategies

Monitor /root/.ssh/authorized_keys for additions using file integrity monitoring and alert on any change.
Correlate CyberPanel audit logs of remote backup configuration with subsequent SSH authentication events as root.
Baseline expected remote backup destinations and alert when CyberPanel connects to an unapproved server.
Inspect process telemetry for python processes spawned by CyberPanel that write to files under /root/.ssh/.

Monitoring Recommendations

Enable verbose SSH logging (LogLevel VERBOSE in sshd_config) to capture public key fingerprints used at authentication.
Ship CyberPanel application logs and /var/log/auth.log to a centralized log platform for correlation.
Alert on any successful root SSH session originating from an IP outside a documented administrator allowlist.
Track EPSS score changes for CVE-2026-71965 to gauge shifting exploitation likelihood.

How to Mitigate CVE-2026-71965

Immediate Actions Required

Upgrade CyberPanel to a build that includes commit eca0c3c or later.
Audit /root/.ssh/authorized_keys on all CyberPanel hosts and remove any keys that were not manually installed by administrators.
Rotate SSH host keys and administrator credentials on any CyberPanel host suspected of exposure.
Restrict CyberPanel administrator accounts to trusted users and enforce multi-factor authentication on the web console.

Patch Information

The vulnerability is fixed in CyberPanel commit eca0c3c (GitHub Commit eca0c3c). The patch updates plogical/remoteBackup.py and filemanager/views.py to introduce validation logic around remote key material and filesystem operations. Additional context is available in the VulnCheck Security Advisory and the Mcsam CyberPanel 2.4.3 Vulnerabilities write-up.

Workarounds

Disable the remote backup feature until the patched build is deployed.
Restrict outbound SSH from the CyberPanel host to a hardcoded allowlist of trusted backup destinations using host firewall rules.
Configure sshd to disallow root login by setting PermitRootLogin no where operationally feasible.
Limit access to the CyberPanel administrator interface with network-level controls such as VPN or IP allowlists.

bash

# Restrict root SSH login and limit backup egress
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

# Example egress restriction: only allow SSH to a known backup host
sudo iptables -A OUTPUT -p tcp --dport 22 -d backup.example.com -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 22 -j REJECT