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

Source: https://srvscripts.com/guides/cpanel-csf-fork-migrate/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

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.

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.

**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](/guides/csf-cve-2026-65638-patch/) and decided you need it. `RESTRICT_SYSLOG` should be `"3"` on any shared server. The [CSF hardening guide](/guides/hardening-csf-messenger-remote-lists/) 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](/scripts/server-security-audit/), so a server that silently falls behind is noticed before the next CVE, not after.

## CPanel CSF fork at a glance

**Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [Locking down WHM: 2FA, cPHulk, Host Access Control and scoped API tokens](https://srvscripts.com/guides/lock-down-whm-2fa-cphulk-api-tokens/) · [Fix WordPress “cURL error 28: Failed to connect” caused by Imunify360 or CSF](https://srvscripts.com/guides/wordpress-curl-error-28-imunify360-csf/) · [CVE-2026-65638, 65639 and 67402 explained: patching the CSF Messenger and URLGET remote-code flaws](https://srvscripts.com/guides/csf-cve-2026-65638-patch/).

## 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](/guides/replace-csf-with-firewalld-fail2ban-almalinux/).