CSF will continue under cPanel: what this means for cPanel and WHM servers

What changed and why it matters

ConfigServer Security and Firewall, better known as CSF, has long been one of the most common firewall tools on Linux servers running cPanel and WHM. After the original company behind CSF shut down, the code was released as open-source but without ongoing vendor maintenance. For VPS and dedicated server admins, that creates an obvious problem: the firewall may keep running, but without an active patch source it becomes harder to trust over time.

cPanel has now confirmed it will maintain a public fork of CSF focused on critical security and stability fixes. This is not a feature roadmap. It is a continuity move. For MioriticHost readers using cPanel, the practical takeaway is simple: CSF remains viable, and future fixes can come from a maintained source instead of an update infrastructure that no longer exists.

Which servers will receive the automatic update source change

• The server runs cPanel and WHM and uses the original CSF plugin, not a separate fork or custom build.
• CSF is still configured to use the old vendor update source.
• The installed release is CSF 14.0 or newer.
• The AUTO_UPDATES setting is enabled.
• If all conditions are met, cPanel will repoint the update mechanism to its new mirrors on February 18, 2026.
• If even one condition is not met, nothing will be changed automatically and the setup should be reviewed manually.

What an admin should check in practice

Start with the basics in WHM or directly in the CSF configuration: confirm the installed version, verify that AUTO_UPDATES is enabled, and check whether the server is still trying to reach the old update host. If you see cron errors, failed outbound checks, or recurring update warnings, treat them as operational issues, not cosmetic noise. They often mean the firewall has been left on a dead update path.

Two practical recommendations are worth doing before and after any change. First, save a copy of your CSF and LFD configuration, including allow and deny lists, so you can roll back quickly if a manual adjustment behaves differently than expected. Second, test access to critical ports right after any firewall-related change, including SSH, HTTP, HTTPS, SMTP, and the cPanel interface, preferably from an external connection that is not already trusted. On many production servers, the real issue is not the update itself but an older rule that quietly blocks valid traffic.

If you also host WordPress sites, add a side check: make sure off-site backups are actually completing and that system email alerts are reaching a monitored mailbox instead of sitting on the local server. During a security event, missed notifications and untested backups usually create more downtime than the firewall update process.

The cPanel change does not rewrite your firewall rules. It only replaces the path CSF uses to receive future security and stability fixes.