Moving from CXS to Shelltrap

What actually changed

ConfigServer eXploit Scanner was, for a long time, the pragmatic answer for operators who wanted server-side malware scanning without a per-account enterprise licence. Its vendor, Way to the Web, has discontinued sales. It was sold as a one-time licence per server (configserver.org , checked 4 September 2026), which is exactly why so many hosts still have it installed and running.

Nothing breaks the day sales stop. That is the trap. A scanner that no longer receives new signatures does not go red — it goes on reporting clean, with steadily less right to. The decay is invisible until the day somebody else finds the shell for you.

So the migration is not urgent in the “the site is down” sense. It is urgent in the “you are carrying an undocumented risk on every server” sense, which is the kind that shows up in an audit, a customer questionnaire or an incident report.

Capability mapping

We are not going to convert your old configuration file for you, and you should be suspicious of anyone who offers to. Shelltrap is a clean-room product with its own terms, options and formats. Carrying an old rule set across engines carries its blind spots with it.

Cutover checklist

The order below is the one we use on our own production hosts. It has exactly one rule: nothing moves a customer file until you have watched the scanner be right for a while.

1. Install in report-only, without the PHP adapter. Set the environment variable that skips the adapter during package installation, so no site is touched and LiteSpeed is not restarted. Then set the global policy so that signature, hash and heuristic hits all report and the upload gate stays off.
2. Give it resource limits before you start it. A systemd drop-in with CPUQuota, IOWeight, Nice and MemoryHigh costs two minutes and saves an angry ticket. A first start plans a full reconciliation crawl, and on a busy host that backlog is real work.
3. Check the capability probe, not the kernel version. Run shelltrapd --check and read both tier and diagnostic.tier. Confirm the worker count, that Landlock is active, and that the site index matches the number of sites in your CyberPanel database.
4. Watch for at least seven days. Queue age, overflow count, verdict distribution, worker restarts, worker RSS, clamd availability, feed age. Verify every malicious finding by hand and write down the false-positive rate. This is the number that earns the right to switch on an action.
5. Enable the upload gate on one domain. Re-run the package configuration without the skip variable, then switch upload.enabled on for a single, low-risk site. Keep upload.on_error = open. Confirm a clean upload still works before you look at anything else.
6. Switch actions on, domain by domain. Signature and hash hits to quarantine first; leave heuristics.action on report until your own false-positive number says otherwise.
7. Only then remove the old scanner. Keep its quarantine directory until you are sure you will not need it. Evidence is cheap to keep and impossible to recreate.

# start in report-only: record everything, move nothing
$ shelltrap policy set global signature.action=report hash.action=report heuristics.action=report upload.enabled=false
policy generation 18
$ shelltrap --json findings list --verdict malicious --page-size 1
{"items":[{"id":"f_01J9…","path":"…/wp-content/uploads/2026/03/thumb-cache.php",
  "verdict":"malicious","confidence":0.97,"action":"report",
  "signals":[{"engine":"heuristics","id":"php.dynamic_eval","score":45},
             {"engine":"yara","name":"WEBSHELL_PHP_Generic","author":"…","license":"DRL-1.1"}]}],
 "total":1,"page":1,"page_size":1}
# nothing was quarantined: the policy said report, so the policy won

Steps 1 and 4 on one screen: the policy that records everything and moves nothing, and the finding it produced.

What this will cost

Shelltrap is licensed per server. Domains, accounts and resellers on that server are covered without a per-site count, so the arithmetic is short.

Where the honesty lives

Three things a migration guide should say and usually does not:

• This is a subscription replacing a one-time purchase. If the entire value of the old product to you was “paid once in 2019”, Shelltrap is a different deal, not a cheaper one. What you are buying is a maintained signature feed, a maintained package on six distributions and someone to call.
• Detection is not identical, in both directions. A different engine set finds different things and misses different things. The report-only phase exists so you can measure that on your own hosts instead of taking anyone’s word for it.
• Shelltrap is younger. It is in its internal test stage on Panomity production hosts right now, and the changelog shows exactly what has been found and fixed there, including the unflattering parts. If you want a product with a decade of scars, you already had one and it is being retired. If you want to see the scars of this one, they are published.

Next

• How real-time detection works — the watcher, the tiers and what happens when the queue overflows
• The installation guide — signed packages, capability probe, profiles
• Pricing — one server, unlimited domains