How to Rollback a cPanel Update: Complete Step-by-Step Guide to Downgrade cPanel/WHM Version Safely in 2026

---

Introduction: When and Why You Might Need to Rollback a cPanel Update

cPanel and WHM updates are, in the vast majority of cases, improvements — they bring security patches, bug fixes, new features, and performance enhancements. However, no software update process is perfect. There are real-world scenarios where a cPanel update introduces a regression, breaks a compatibility dependency, or triggers unexpected behavior on your specific server configuration. When that happens, knowing how to rollback a cPanel update or downgrade cPanel to a specific version becomes an urgent operational skill.

Before proceeding, it’s critical to understand one fundamental rule: cPanel supports downgrading within minor versions only. You cannot roll back to a previous major version. For example:

• ✅ Allowed: Downgrading from 11.136.0.9 back to 11.136.0.5 (same minor version, earlier build)
• ✅ Allowed: Downgrading from 11.136.x.x back to 11.134.x.x (earlier minor version within the same major)
• ❌ Not supported: Downgrading from major version 11.136 to a completely different major version architecture

This limitation is by design. cPanel’s update system, database migrations, and configuration changes are written to be forward-compatible only. Attempting a major version downgrade would leave your server in an unsupported, potentially broken state.

2026 Security Note: With multiple high-severity CVEs actively exploited in the wild in 2026 — including CVE-2026-41940 (CVSS 9.8, authentication bypass, exploited as a zero-day for two months before a patch was released) — downgrading cPanel means deliberately removing security patches from your server. This must only be done as a last resort, for the shortest time possible, with compensating security controls in place.

---

Before You Downgrade: The Checklist

Do not skip this section. Running through this checklist before initiating any downgrade will save you from making a recoverable problem into an unrecoverable one.

✅ Pre-Downgrade Checklist

• [ ] Take a full server backup — Use WHM’s Backup Configuration, your server provider’s snapshot feature (Proxmox, cPanel backup to remote storage, etc.), or rsync to a remote location. This is non-negotiable.
• [ ] Document your current version — Run /usr/local/cpanel/cpanel -V and save the output. You need to know exactly what you’re running now.
• [ ] Identify the target version — Know the exact version string you want to roll back to (e.g., 11.136.0.5). Guessing is not acceptable here.
• [ ] Check cPanel’s changelog — Verify that the version you’re targeting does not contain a known, actively exploited vulnerability. Visit https://docs.cpanel.net/changelog/ to review patch notes.
• [ ] Exhaust alternative solutions first — Have you contacted cPanel support? Have you checked cPanel’s community forums? Has your hosting provider been consulted? Downgrade is a last resort.
• [ ] Notify your users or clients — Inform anyone using the server that maintenance is underway. Downgrading cPanel restarts services, which causes brief interruptions.
• [ ] Confirm the downgrade window — Choose a low-traffic period for the downgrade, ideally during a formal maintenance window.
• [ ] Verify SSH access — Confirm you have stable root SSH access to the server before starting.

---

Understanding the /etc/cpupdate.conf File

The entire cPanel downgrade process revolves around one configuration file:

/etc/cpupdate.conf

This file controls how, when, and to what version cPanel updates itself. It is a plain-text key=value configuration file that the /scripts/upcp update script reads every time it runs — whether triggered automatically by cPanel’s scheduled updater or manually by you.

Viewing Your Current Configuration

cat /etc/cpupdate.conf

A typical output looks like:

CPANEL=current
RPMUP=daily
STAGING_DIR=/usr/local/cpanel
UPDATES=daily

Key Parameters Explained

Parameter	Description	Common Values
CPANEL=	Defines the target cPanel version or update tier	current, release, edge, stable, lts, or a specific version like 11.136.0.5
RPMUP=	Controls RPM package update frequency	daily, manual, never
UPDATES=	Controls how often cPanel checks for updates	daily, manual, never
STAGING_DIR=	Directory where cPanel is installed	/usr/local/cpanel (default, do not change)

Understanding Tier Values vs. Version Pinning

When CPANEL= is set to a tier name (e.g., release, current, edge), cPanel automatically updates to the latest version available on that tier.

When CPANEL= is set to a specific version string (e.g., 11.136.0.5), cPanel is pinned to that exact version and will not update beyond it until you change the value. This is the mechanism used for both downgrading and version-locking.

---

Step-by-Step: How to Rollback / Downgrade cPanel to a Specific Version

Step 1: Log In via SSH as Root

Connect to your server using your SSH client:

ssh root@your-server-ip-or-hostname

If you’re using an SSH key:

ssh -i /path/to/private-key root@your-server-ip

Verify you are the root user:

whoami

Expected output: root

If you are not root, switch with: sudo su -

---

Step 2: Record Your Current cPanel Version

Before making any changes, document exactly what version you are currently running:

/usr/local/cpanel/cpanel -V

Save this output. If anything goes wrong during the downgrade, you will need this information to restore or escalate to support.

Also note your current /etc/cpupdate.conf state:

cat /etc/cpupdate.conf

Save this entire output as well.

---

Step 3: Identify the Target Downgrade Version

You need the exact version string of the cPanel version you want to roll back to. The format is:

11.MINOR.PATCH.BUILD

For example: 11.136.0.5, 11.134.0.25, 11.130.0.18

How to find available older versions:

• Check the official cPanel changelog: https://docs.cpanel.net/changelog/
• Review your server’s update logs for previously installed versions:

  grep "cPanel" /var/log/cpanel-install.log | tail -50
  

• Check the cPanel update history:

  cat /var/cpanel/updatelogs/update.*.log | grep "Updating from" | tail -20
  

Important: Only target a version that existed and was publicly released. Specifying a non-existent version string will cause the update script to fail or behave unpredictably.

---

Step 4: Edit /etc/cpupdate.conf to Pin the Target Version

Open the configuration file with your preferred text editor. nano is recommended for beginners; vi/vim for experienced administrators.

Using nano:

nano /etc/cpupdate.conf

Using vi:

vi /etc/cpupdate.conf

Using sed (non-interactive, ideal for scripts):

# Replace whatever is after CPANEL= with your target version
sed -i 's/^CPANEL=.*/CPANEL=11.136.0.5/' /etc/cpupdate.conf

Replace 11.136.0.5 with your actual target version.

What to change:

Find the line that begins with CPANEL= and change it to your target version:

Before:

CPANEL=release

After:

CPANEL=11.136.0.5

Save and exit:

• In nano: Press Ctrl+X, then Y, then Enter
• In vi: Press Esc, type :wq, press Enter

Verify the change was saved:

grep "CPANEL=" /etc/cpupdate.conf

Expected output:

CPANEL=11.136.0.5

---

Step 5: Run the Forced Downgrade Command

With the target version pinned in the config file, initiate the downgrade:

/scripts/upcp --force

What the --force flag does:

Without --force, the upcp script checks whether your currently installed version is already at or above the configured target, and skips the update if so. Since you are intentionally specifying an older version, --force overrides this safety check and instructs the script to install the specified version regardless of whether it is older than what is currently installed.

What happens during execution:

The downgrade process will:

1. Download the specified cPanel version package from cPanel’s distribution servers
2. Uninstall or overwrite the current cPanel binaries
3. Apply the older version’s configuration baseline
4. Restart cPanel-managed services (Apache/LiteSpeed, cPanel service daemon, etc.)
5. Update relevant configuration files

This process typically takes 5 to 20 minutes depending on server speed and network connection to cPanel’s distribution servers.

Watch the live output:

The upcp script outputs progress in real time. You will see lines like:

Updating cPanel & WHM...
Downloading: cpanel-scripts-11.136.0.5.tar.gz
Installing version 11.136.0.5
Restarting cPanel services...
Done.

Do not interrupt this process. Closing your SSH session or pressing Ctrl+C mid-downgrade can leave cPanel in a partial/broken state. If you are concerned about SSH disconnection, run the command inside a screen or tmux session:

screen -S cpanel-downgrade
/scripts/upcp --force

Then detach with Ctrl+A + D if needed. Reattach with screen -r cpanel-downgrade.

---

Step 6: Verify the Downgrade Was Successful

Once the process completes, immediately verify the installed version:

/usr/local/cpanel/cpanel -V

Confirm the output matches your target version. For example:

11.136.0.5 (build 5)

Also restart the cPanel service daemon to ensure all components are running the downgraded code:

/scripts/restartsrv_cpsrvd

Check the service status:

systemctl status cpanel

Look for Active: active (running).

---

Step 7: Test Your Server Thoroughly

After the downgrade, immediately run through a post-downgrade verification checklist:

• [ ] Can you log into WHM? (https://yourserver:2087)
• [ ] Can you log into a cPanel account? (https://yourserver:2083)
• [ ] Are websites loading correctly?
• [ ] Is email sending and receiving?
• [ ] Are MySQL/MariaDB connections working?
• [ ] Do any previously broken scripts or applications now function as expected?
• [ ] Check the cPanel error log: tail -100 /usr/local/cpanel/logs/error_log
• [ ] Check the Apache/LiteSpeed error log: tail -100 /var/log/apache2/error_log or /usr/local/apache/logs/error_log

---

Preventing Auto-Updates After a Downgrade (Version Pinning)

After a successful downgrade, your server will attempt to auto-update back to a newer version on its next scheduled update cycle — which could be as soon as the next day. To prevent this until you’re ready to re-upgrade:

Option 1: Keep the Version Pinned

As long as CPANEL=11.136.0.5 (your specific version) remains in /etc/cpupdate.conf, cPanel will not update beyond that version automatically. It will only update to exactly that version if it somehow gets changed.

Option 2: Set Updates to Manual

To prevent any automatic updates entirely:

sed -i 's/^UPDATES=.*/UPDATES=manual/' /etc/cpupdate.conf
sed -i 's/^RPMUP=.*/RPMUP=manual/' /etc/cpupdate.conf

This puts you in full control — no updates happen until you explicitly run /scripts/upcp.

Option 3: Use WHM Update Preferences

In WHM, navigate to WHM → Server Configuration → Update Preferences and set the update frequency to Manual from the graphical interface.

⚠️ Critical Warning: Running with manual updates or version-pinned at an older build means you will not automatically receive security patches. In 2026, where critical CVEs for cPanel have been exploited in the wild, this is a significant risk. Set a calendar reminder to re-evaluate and re-upgrade as soon as the compatibility issue is resolved.

---

How to Re-Upgrade After the Downgrade Issue Is Resolved

Once you’ve resolved the underlying issue that required the downgrade (compatibility fix, application update, configuration correction), you should upgrade back to the latest patched version as soon as possible.

Step 1: Restore the Update Tier in /etc/cpupdate.conf

nano /etc/cpupdate.conf

Change CPANEL=11.136.0.5 back to your desired tier:

CPANEL=release

Step 2: Force the Update to the Latest Version

/scripts/upcp --force

Step 3: Verify the Updated Version

/usr/local/cpanel/cpanel -V

Step 4: Restart cPanel Services

/scripts/restartsrv_cpsrvd

---

Security Hardening While Running a Downgraded cPanel Version

If you must remain on a downgraded, potentially unpatched version temporarily, implement these compensating controls immediately:

1. Restrict WHM and cPanel Port Access

Limit access to cPanel/WHM management ports to trusted IP addresses only using your firewall (CSF, iptables, or firewalld):

# Using CSF (ConfigServer Firewall) — add trusted IPs to csf.allow
echo "YOUR.TRUSTED.IP.HERE" >> /etc/csf/csf.allow
csf -r

# Block cPanel ports (2082, 2083, 2086, 2087, 2095, 2096) from untrusted IPs
# Add to csf.conf: TCP_IN = "... your allowed ports ..."

2. Enable Two-Factor Authentication in WHM

Navigate to WHM → Security Center → Two-Factor Authentication and enable 2FA for all WHM and cPanel accounts. This mitigates authentication-based exploits.

3. Implement IP Whitelisting for WHM Access

WHM → Security Center → Host Access Control — Restrict access to WHM (port 2087) to your office or VPN IP range only.

4. Monitor Authentication Logs

# Watch for suspicious login attempts
tail -f /var/log/cpanel-login.log

# Check for unusual root logins
last | head -30

# Monitor failed SSH attempts
grep "Failed password" /var/log/secure | tail -30

5. Keep All Other Server Software Updated

While cPanel is pinned, ensure that everything else is still receiving updates:

# Update OS packages (excluding cPanel packages)
yum update --exclude=cpanel* --exclude=ea-* -y

6. Enable Imunify360 or CSF Firewall

If not already active, enable Imunify360 or ConfigServer Security & Firewall (CSF) to provide real-time threat blocking while the underlying cPanel version is not fully patched.

---

Alternatives to Downgrading cPanel

Before committing to a downgrade, consider these alternatives — many of which solve the problem without the security trade-off:

Alternative 1: Contact cPanel Support

cPanel’s official support (available to license holders at https://cpanel.net/support/) can often provide hotfixes, workarounds, or configuration adjustments that resolve post-update issues without a full rollback. This should always be your first call.

Alternative 2: Contact Your Hosting Provider

If you are on a managed server or a hosting plan, your hosting provider’s technical support team may have encountered the same issue with other clients and already have a resolution ready.

Alternative 3: Isolate and Fix the Affected Application

In many cases, the issue after a cPanel update is not with cPanel itself but with a third-party application (WordPress plugin, WHMCS module, custom PHP script) that has not been updated to support the new cPanel version. Check for:

• Plugin/module updates from the third-party vendor
• PHP version compatibility changes
• Apache/Nginx configuration changes introduced by the update

Alternative 4: Upgrade to the Latest Stable Release

If your current version is significantly outdated and causing issues, upgrading forward (rather than rolling back) to the latest stable RELEASE tier may resolve the problem, since newer versions often include fixes for bugs that appeared in intermediate versions.

Alternative 5: Restore from Backup

If the post-update state is severely broken and a downgrade is too complex, restoring from a pre-update server snapshot (VM snapshot, Proxmox backup, R1Soft backup, JetBackup restore) may be faster and safer than a manual downgrade process.

---

Troubleshooting Common Downgrade Issues

Issue: upcp --force Downloads the Wrong Version

Symptom: After editing cpupdate.conf, the update script installs a different version than specified.

Solution:

# Verify the config file change was actually saved
cat /etc/cpupdate.conf | grep CPANEL

# Ensure no whitespace or formatting issues in the version string
# Correct:  CPANEL=11.136.0.5
# Wrong:    CPANEL= 11.136.0.5  (note the space)
# Wrong:    CPANEL=11.136.0.5.  (note the trailing period)

Issue: upcp --force Fails with a Network Error

Symptom: The download fails mid-process.

Solution:

• Check your server’s internet connectivity: curl -I https://httpupdate.cpanel.net/
• If your server is behind a firewall, ensure outbound access to cPanel’s update servers is allowed
• Re-run the command: /scripts/upcp --force — it will resume from where it can

Issue: WHM Is Inaccessible After Downgrade

Symptom: Cannot log into WHM on port 2087 after the downgrade completes.

Solution:

# Restart the cPanel service daemon
/scripts/restartsrv_cpsrvd

# Check if cPanel services are running
/scripts/restartsrv_httpd
/scripts/restartsrv_mysql

# Check for errors in the cPanel log
tail -100 /usr/local/cpanel/logs/error_log

Issue: The Target Version Is No Longer Available

Symptom: The specified version cannot be downloaded from cPanel’s servers.

Cause: cPanel periodically removes very old version packages from its distribution servers, especially versions with known critical vulnerabilities.

Solution: Choose a more recent target version within the supported range. Check https://docs.cpanel.net/changelog/ for the currently available builds.

Issue: Downgrade Breaks MySQL/MariaDB

Symptom: Database connections fail after the downgrade.

Solution:

# Restart MySQL/MariaDB
/scripts/restartsrv_mysql

# Check MySQL error log
tail -50 /var/lib/mysql/hostname.err

# If schema changes were made during the update, a full restore may be required

---

Frequently Asked Questions

Q: Can I downgrade cPanel to a completely different major version? No. cPanel does not support major version downgrade. You can only roll back within minor versions of the same major release. Once a major version upgrade has been applied, the only supported path is forward.

Q: How long does a cPanel downgrade take? Typically 5 to 20 minutes, depending on your server’s processing speed, RAM, and connection speed to cPanel’s distribution servers. Shared/VPS servers may take longer than dedicated servers.

Q: Will downgrading cPanel affect my websites or emails? The downgrade process restarts cPanel-managed services, causing a brief interruption (usually 1–3 minutes). Website files, databases, email accounts, and configurations are not deleted or altered. However, any features or settings introduced by the newer version may become unavailable.

Q: Can I automate the rollback process for multiple servers? Yes. The sed command to edit cpupdate.conf and the /scripts/upcp --force command can both be run via Ansible, a shell loop over SSH, or any configuration management tool. Ensure you test on one server before running across a fleet.

Q: What if my downgrade makes the server vulnerable to a known exploit? Implement the compensating security controls described in the hardening section above immediately: restrict port access, enable 2FA, whitelist IPs, monitor logs, and keep other software updated. Then prioritize resolving the underlying issue and re-upgrading as quickly as possible.

Q: Is there an official cPanel tool for rollbacks? No. cPanel does not provide a dedicated rollback or snapshot tool. The cpupdate.conf + upcp --force method is the official documented approach for version pinning and minor version downgrading.

---

Quick Reference: The Complete Downgrade Command Sequence

Copy and paste this entire block for a clean, documented downgrade workflow:

# 1. Document current version (save this output)
/usr/local/cpanel/cpanel -V

# 2. Backup current cpupdate.conf
cp /etc/cpupdate.conf /etc/cpupdate.conf.bak.$(date +%Y%m%d)

# 3. Pin target version (replace 11.136.0.5 with your target)
sed -i 's/^CPANEL=.*/CPANEL=11.136.0.5/' /etc/cpupdate.conf

# 4. Verify the change
grep "CPANEL=" /etc/cpupdate.conf

# 5. Run the forced downgrade (inside screen to protect against disconnection)
screen -S cpanel-downgrade -dm /scripts/upcp --force

# 6. Attach to watch progress
screen -r cpanel-downgrade

# 7. Verify new version after completion
/usr/local/cpanel/cpanel -V

# 8. Restart cPanel service daemon
/scripts/restartsrv_cpsrvd

---

Conclusion: Downgrade as a Last Resort, Security as the Priority

Rolling back a cPanel update is a viable and sometimes necessary emergency procedure — but it is one that carries real security risk and must be treated accordingly. In 2026, with cPanel servers actively targeted by sophisticated attackers exploiting zero-days, running an older, unpatched version even for a short window represents meaningful exposure.

Use the process outlined in this guide only when necessary, implement all recommended compensating security controls while the downgrade is active, and make re-upgrading to the latest patched version your top server priority. The cpupdate.conf version pinning mechanism and /scripts/upcp --force command give you precise control — use that control responsibly.