Block cPanel and WHM Ports 2083 and 2087 to Mitigate CVE-2026-41940 on Linux

What the cPanel and WHM port block Worklet does

This Automox Worklet™ blocks inbound traffic to the cPanel and WebHost Manager (WHM) SSL ports as a temporary workaround for CVE-2026-41940. It adds drop rules for TCP port 2083 (cPanel) and TCP port 2087 (WHM).

Before it touches the firewall, the Worklet reads the installed build from /usr/local/cpanel/version and logs it. It exits 0 as not applicable on endpoints without that file, so you can target a broad Linux server group. It also skips builds below 11.40. The same goes for builds at or above their branch's fixed release, such as 11.134.0.20 on the 11.134 branch or 11.136.0.5 on the 11.136 branch.

The Worklet then picks one firewall stack in priority order. It checks for active firewalld, then active ufw, then an nftables inet filter table with an input chain. If none match, it falls back to the iptables binary. It logs the stack it picks.

Why block cPanel and WHM ports for CVE-2026-41940

CVE-2026-41940 is an authentication bypass rated 9.8 Critical under CVSS 3.1. It hands an attacker the control your administrators have through the WHM and cPanel interfaces. WHM on port 2087 is the server-level administration console. cPanel on port 2083 is where each account owner manages that account's domains, mailboxes, and databases.

The Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-41940 to the Known Exploited Vulnerabilities catalog on April 30, 2026. Updating cPanel and WHM to the fixed build for your branch is the permanent fix. Servers with updates disabled or pinned to a version don't update on their own. On those servers, the Worklet closes both ports now, while you schedule the update.

The Activity Log records when each server received the block. If your PCI DSS or SOC 2 controls set a deadline for critical vulnerabilities, you can cite those entries as supporting evidence for a temporary compensating control.

How the port 2083 and 2087 block works

1. Evaluation phase: Checks the build first, treating an unreadable version file as affected. It then detects the firewall stack. For ufw, either a successful systemctl is-active ufw or Status: active in the ufw status output counts as active.

   On firewalld, it looks for ipv4 rich rules that drop TCP ports 2083 and 2087, plus matching ipv6 rules when IPv6 is enabled (/proc/net/if_inet6 exists). On ufw, it looks for DENY entries for 2083/tcp and 2087/tcp.

   On nftables and iptables, it matches rules tagged automox-CVE-2026-41940-2083 and automox-CVE-2026-41940-2087. On iptables, it also checks ip6tables when IPv6 is enabled and ip6tables is available. Evaluation exits 0 (compliant) when every expected rule for both ports is present, and exits 1 (non-compliant) when any is missing.

2. Remediation phase: Runs the same build and stack checks first and exits 0 without changes when both ports are already blocked. Otherwise, it adds the drop rules through the detected stack and logs each one.

   Before it changes anything, it creates the backup directory /var/lib/automox/workletcache/8735cba1-7ad3-5811-8b75-7bac25d239f9 and records the detected stack in firewall-stack.bak there. It also saves a text snapshot of the current rules to firewall-rules.bak. The snapshot comes from firewall-cmd --list-all, ufw status verbose, nft list ruleset, or iptables -S INPUT plus ip6tables -S INPUT. Later runs never overwrite either file, so both keep the state from before the first change.

   On firewalld, it adds permanent rich rules such as rule family="ipv4" port port="2083" protocol="tcp" drop, plus matching ipv6 rules when IPv6 is enabled. It then runs firewall-cmd --reload, which applies the permanent configuration. On ufw, it runs ufw deny 2083/tcp and ufw deny 2087/tcp.

   On nftables and iptables, it inserts the tagged drop rules at the top of the input chain so they match before any existing accept rule. The nftables rules sit in the inet family, which covers IPv4 and IPv6. The iptables path repeats both rules in ip6tables when IPv6 is enabled and ip6tables is available.

   A final check reads the rules back and logs the result. If the block holds, remediation exits 0. If it doesn't, remediation exits 1 for manual review.

cPanel and WHM firewall workaround requirements

• A Linux server running cPanel and WHM on RHEL, CentOS, Rocky Linux, AlmaLinux, or CloudLinux 7 or later, or Ubuntu 18.04 or later

• Root privileges through the Automox agent to change firewall rules and write backups under /var/lib/automox

• One supported host firewall (firewalld, ufw, nftables, or iptables), installed and enabled beforehand on servers that have none

• On ufw servers, an active ufw with rules that already allow SSH and your hosting ports. When /etc/default/ufw sets IPV6=yes, ufw applies the deny rules to IPv6 as well.

• A tested SSH or other out-of-band path you can use to manage the server once ports 2083 and 2087 are blocked

• A recurring policy schedule. Permanent firewalld and ufw rules persist across reboots, but the nftables and iptables rules don't. On every stack, the next scheduled run reapplies rules that evaluation finds missing.

• Optional dryrun=yes to log each change the Worklet would make without modifying the server

• Optional rollback=yes to remove the port 2083 and 2087 drop rules. Rollback reads firewall-stack.bak to pick the stack and leaves firewall-rules.bak in place for reference and manual recovery. On firewalld, it removes the rich rules. On ufw, it runs ufw delete deny for both ports. On nftables, it deletes the tagged rules by handle. On iptables, it deletes the tagged iptables and ip6tables rules.

• Runtime-only firewalld rules saved to the permanent configuration before you run the Worklet, since remediation reloads firewalld. Rollback reloads firewalld or the active nftables service, so save runtime-only rules on either stack first.

• A manual run for rollback, since scheduled runs skip remediation on servers that report compliant. Create a separate policy with rollback=yes and pause the blocking policy for the target server. Then run the rollback policy on demand so it goes straight to remediation.

Expected cPanel and WHM access after remediation

On an affected cPanel server, the host firewall drops inbound TCP traffic on ports 2083 and 2087. The rules drop packets rather than reject them, so direct connections to both ports time out, for your administrators too.

Endpoints without cPanel or on an unaffected build report compliant as not applicable. To reopen ports 2083 and 2087, run the rollback=yes policy during your update window, before the update itself.