Migrating a cPanel server to the cPanel CSF fork and verifying auto-updates

How to move a cPanel or WHM server from the abandoned ConfigServer CSF to cPanel's maintained fork, confirm the RPM is installed, make sure updates flow through upcp, and keep your existing rules and allow lists intact.

Published 29 Sep 2026Updated 3 Oct 2026 6 min read By srvScripts team

Most cPanel servers were moved to the cPanel CSF fork without anyone touching them: on 18 February 2026 the old update endpoint began redirecting, and any install of CSF 14 or later with AUTO_UPDATES = "1" picked up the new packaging. The servers that need attention are the ones where auto-updates were off, where CSF was installed from a tarball into a non-standard path, or where a hosting provider’s own automation pinned the version. This guide gets any of them onto the fork and proves the update channel works.

Applies to cPanel CSF fork 16.30 and 16.31 on cPanel & WHM; replaces ConfigServer CSF 15.00 and older

Short answer: Back up /etc/csf, run /scripts/autorepair cpanel_csf_install to replace the legacy tarball install with the cpanel-csf RPM, then confirm with rpm -q cpanel-csf and csf -v that a 16.x build is present. Set AUTO_UPDATES = "1" in csf.conf, make sure WHM’s Update Preferences apply package updates automatically, and run csf -c to prove the server can reach the update endpoint.

Find out where the server stands

Run these before changing anything. The combination tells you whether the fork is present, what version it is, and whether updates were ever enabled:

csf -v
rpm -q cpanel-csf
grep -E '^AUTO_UPDATES' /etc/csf/csf.conf
ls -la /etc/cron.d/csf* /etc/cron.d/csf-cron 2>/dev/null

If rpm -q cpanel-csf returns a package name and csf -v shows 16.30 or newer, you are already migrated and can jump to the verification section. If csf -v shows 15.00 or older and the RPM query says the package is not installed, carry on.

Back up the configuration

The fork keeps /etc/csf/ as the configuration directory, and the installer preserves existing files, but a copy costs nothing:

tar czf /root/csf-backup-$(date +%F).tgz /etc/csf
csf -l > /root/csf-rules-before.txt

The rule dump is useful later for a before-and-after comparison, particularly if you have custom entries in csfpre.sh or csfpost.sh.

Install the fork

cPanel wraps the installation in an autorepair task so it runs the same way whether triggered by hand or by upcp:

/scripts/autorepair cpanel_csf_install

This removes the legacy tarball install, adds the cpanel-csf RPM from cPanel’s repository and restarts csf and lfd. If your server uses a local mirror or a restrictive outbound firewall, make sure the cPanel package mirror is reachable first; a failed download leaves the old install in place, which is safe but not what you wanted. On a server where CSF was never installed, the same command performs a fresh install with cPanel’s default csf.conf.

Once it finishes, confirm the package and version:

rpm -q cpanel-csf
csf -v

You should see a 16.x version. As of late September 2026 the current builds are 16.30 and 16.31; 16.31 is the one that closed CVE-2026-67402, so anything older should update on the next upcp run.

Make sure updates actually flow

With the fork, CSF updates arrive two ways: through AUTO_UPDATES in csf.conf, which now points at cPanel’s endpoint, and through the normal package update run. Enable both:

sed -i 's/^AUTO_UPDATES = .*/AUTO_UPDATES = "1"/' /etc/csf/csf.conf
csf -ra
dnf clean all && /scripts/update-packages

Then check the WHM update preferences. In WHM go to Server Configuration, then Update Preferences, and confirm the operating system package updates are set to automatic. If they are set to manual, the RPM will sit in the repository until someone runs /scripts/update-packages by hand, which defeats the point of the migration.

A quick way to see whether the update path is healthy is to ask CSF itself:

csf -c

It compares the installed version to the fork’s published version and reports whether an update is available. If it reports a network error, the server cannot reach the update host, and you need to fix outbound access before anything else.

Review settings the fork changed

The cPanel fork ships with security-conscious defaults and the 16.30 release changed a few behaviours in response to the August CVEs. Check these lines in /etc/csf/csf.conf after the migration:

grep -E '^(MESSENGER|MESSENGERV3|URLGET|LF_INTEGRITY|RESTRICT_SYSLOG) ' /etc/csf/csf.conf

MESSENGER should be "0" unless you have read the Messenger and URLGET CVE guide and decided you need it. RESTRICT_SYSLOG should be "3" on any shared server. The CSF hardening guide walks through the rest.

Common pitfall: the old cron jobs

Tarball installs of CSF placed cron entries in /etc/cron.d/csf-cron and /etc/cron.d/csf_update. The RPM manages its own. If both exist you can end up with two update attempts a night, one of which fails noisily in root’s mailbox. After migration, list /etc/cron.d/ and remove any CSF entries that the RPM does not own:

rpm -qf /etc/cron.d/csf* 2>&1 | grep -v 'cpanel-csf'

Anything that prints “not owned by any package” is a leftover and can be deleted.

Verify

Compare your saved rule dump with the live rules, confirm the daemons are up and check that WHM’s ConfigServer plugin page loads and shows the new version:

csf -l > /root/csf-rules-after.txt
diff /root/csf-rules-before.txt /root/csf-rules-after.txt | head
systemctl is-active csf lfd
tail -20 /var/log/lfd.log

Small differences in rule ordering are normal; missing custom allow entries are not, and you would restore them from the backup tarball. Finally, put a monthly reminder in place to run csf -v across the fleet, or fold it into the server security audit script, so a server that silently falls behind is noticed before the next CVE, not after.

CPanel CSF fork at a glance

Migrating a cPanel server to the cPanel CSF fork and verifyi summary card: Back up /etc/csf, run /scripts/autorepair cpanel_csf_install to replace the legacy tarball install with the cpanel-csf… — In short: Back up /etc/csf, run /scripts/autorepair cpanel_csf_install to replace the legacy tarball install with the cpanel-csf RPM, then confirm with rpm -q cpanel-csf and csf -v that a 16.x build is present.

Official documentation: cPanel & WHM documentation, Linux man pages.

Frequently asked questions

Does the cPanel CSF fork keep my existing csf.allow, csf.deny and custom rules?

Yes. The fork uses the same /etc/csf/ directory and the installer preserves existing files, including csf.allow, csf.deny, csfpre.sh and csfpost.sh. Compare a csf -l dump from before and after to confirm nothing was lost.

Is the cPanel CSF fork free on a licensed cPanel server?

Yes. The fork ships as the cpanel-csf package from cPanel’s own repository and is covered by the cPanel licence, with updates delivered through the normal upcp and package update cycle.

Can I install the cPanel CSF fork on a DirectAdmin or plain AlmaLinux server?

No. The cpanel-csf RPM depends on cPanel’s repositories and scripts. Non-cPanel servers need one of the community forks or a replacement such as firewalld with fail2ban, covered in the guide on replacing CSF on AlmaLinux.

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by: srvScripts editorial team
Supported versions: cPanel CSF fork 16.30 and 16.31 on cPanel & WHM; replaces ConfigServer CSF 15.00 and older
Last full review: 3 Oct 2026
Next review: 1 Apr 2027
Sources: docs.cpanel.net