Shelltrap for cPanel

What it does on a cPanel host

A webshell dropped into public_html through a vulnerable plugin is not a slow problem. It is used within minutes, and a scanner that runs nightly documents the incident rather than preventing it. Shelltrap watches the write itself:

• Real-time detection through fanotify. Every write, move, creation, deletion and attribute change under your customer roots is an event. A later chmod or setuid bit counts too.
• A parser-free root broker and an unprivileged worker. The part that opens attacker-chosen bytes runs as its own user, in its own mount and PID namespace, with seccomp, Landlock, rlimits and cgroup limits, and no network at all.
• All engines. ClamAV over the clamd socket, YARA 4.5 precompiled per rule generation, hash sets with a known-good allowlist, and heuristics that need several independent signals before they say anything.
• Quarantine you can undo. A crash-safe transaction; restore puts back owner, mode, times, ACLs, extended attributes and the SELinux context, and never overwrites an existing file.
• Policies per domain. Global, account and domain layers with visible inheritance, so one site can be strict while the rest of the box is not.
• Nothing leaves the machine. Scanning is local because the scanner is local. Only the licence check and the signed feed download talk to Germany.

That list is not a cPanel-specific product. It is the same daemon, the same engines and the same five verdicts described on the product page — which is the point.

How it finds your sites

On start-up the daemon works out which panel it is sitting on. On a cPanel host it builds its document-root index from the cPanel userdata, and it covers the four shapes a cPanel account can have:

fanotify events are mapped to an account and a domain by the longest matching document-root prefix, exactly as on CyberPanel. Files outside every document root — mail, backups, the home root — fall under the account policy rather than being ignored.

Check what it found before you rely on it:

shelltrapd --config /etc/shelltrap/shelltrap.toml --check
shelltrap status

status prints the number of indexed sites. If it does not match the accounts and domains you expect from WHM, stop and tell us: a site index that is quietly incomplete is worse than one that fails loudly.

What “beta” means, precisely

Marketing uses the word to mean “new”. We use it to mean something narrower and more useful:

The cPanel platform support is implemented against the cPanel file format and tested against fixtures. It has not yet accumulated long-term operation on live cPanel hosts.

What follows from that:

• The scanner itself is not new. Engines, verdict model, quarantine transaction, feed verification, policy model and licensing are the same code that runs on CyberPanel hosts.
• What is new is the platform layer: platform detection and site discovery from the cPanel userdata. That is where a surprise would come from, and that is why it carries a label.
• Run it in report-only for longer than you otherwise would. Record everything, move nothing, and switch actions on domain by domain once you have watched it be right.

Two capabilities are deliberately not the same as on CyberPanel:

1. There is no WHM plugin. It is on the roadmap and we are not giving it a date. Today the CLI and the local API are the interface — the same interface the CyberPanel plugin talks to, so nothing is out of reach, it is just not in a browser.
2. The PHP upload gate is optional and off by default on EasyApache 4 with PHP-FPM. With it off, the real-time watcher covers those files a moment after the write instead of synchronously before the request completes. That difference is stated in the finding, not glossed over.

Everything else — real-time watching, every engine, quarantine, per-domain policies, the CLI, the local API, mail alerts, signed feeds, one licence per server — is identical to CyberPanel.

Installation in five steps

1. Get the core package. Packages are served by the licence service against a valid licence or trial key from the download page . There is no shelltrap-cyberpanel package on a cPanel host.

   sudo dnf install ./shelltrap-<version>-1.x86_64.rpm     # AlmaLinux 8 / 9
   sudo apt-get install ./shelltrap_<version>_amd64.deb    # Ubuntu 22.04 / 24.04
   

2. Activate the licence. One licence per server; the panel on it makes no difference. A trial key is activated with the same command and behaves the same way, except that nothing is quarantined automatically while the trial runs.

   sudo shelltrap license activate STL-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
   

3. Let it detect the platform. No flag to set: the daemon recognises cPanel by itself and builds the site index from the userdata.

   shelltrapd --config /etc/shelltrap/shelltrap.toml --check
   shelltrap status
   

4. Run the first scan in report-only. Record everything, move nothing, and read what it says before you give it permission to act.

   shelltrap policy set global signature.action=report hash.action=report \
     heuristics.action=report upload.enabled=false
   shelltrap scan --path /home/<account>/public_html
   shelltrap findings list --json
   

5. Point the alerts somewhere you read. Findings are mailed from sentinel@shelltrap.com . Put that address on the allowlist of whatever filters your admin mailbox — the first malicious verdict is the one mail you must not lose. Replies to it are read, but it is not a support channel.

The long version, including the profile decision and the systemd drop-ins, is in installation and first run .

Coming from cxs

ConfigServer eXploit Scanner is no longer sold (checked 4 September 2026). Nothing breaks the day sales stop — that is the trap. An unmaintained scanner keeps running and keeps reporting clean, with steadily less right to, while its signature feed falls behind what is being uploaded this month.

The migration path is the same on cPanel as it is on CyberPanel, and it starts in report-only with both scanners running:

• CXS → Shelltrap migration — capability mapping and the cutover checklist
• CXS alternatives in 2026 — the field, with sources

How it compares

Two figures, both taken from the vendors’ own pages, both checked on 4 September 2026. We do not publish comparison tables built from numbers we cannot cite, and we do not publish detection rates — ours or anybody else’s.

Three things about Shelltrap that a price table does not show:

• Files never leave your server. There is no sample upload and no cloud analysis queue. That is an architectural property, not a policy we could change in a release note.
• Account count does not change the price. A reseller host with four hundred sites costs the same as a host with four.
• No operating system conversion. It runs on the AlmaLinux or Ubuntu that is already under your cPanel install.

And three things we are not claiming: that it detects more than any other product, that it is feature-for-feature equivalent to a suite that also does WAF, patching and firewalling, and that the cPanel platform layer has the operating history the CyberPanel one has. It does not, yet. That is the beta.

What it is not

• Not a WAF and not a firewall. It looks at files, not requests.
• Not kernel-level execution prevention. Blocking a file open before the fact is a 1.x prototype and is deliberately not promised today.
• Not a claim to catch everything. No scanner does. It claims to tell you what it scanned, what it could not scan, and why it decided what it decided.
• No help against an attacker who already has root. Nothing running on that machine is.

Next

• Try 14 days free — report-only, the same trial on cPanel and CyberPanel
• Pricing — one licence per server, same price on cPanel and CyberPanel
• Download — packages against a licence key
• Shelltrap on cPanel: what works today, what is beta
• Reporting a false positive — automated, answered in about an hour
• Talk to us — before you install on a host with customers on it

Questions people ask