Linux Malware Detect (maldet) vs Shelltrap

Linux Malware Detect — maldet — is the default free answer to server-side malware scanning on Linux, and it deserves a fair hearing rather than a sales comparison. This article is mostly about the thing both products depend on and only one of them can control: the signature feed.

maldet, fairly described

The project is alive. It is GPL-2.0, the repository is not archived, version 2.0.1 was released on 29 April 2026 with the last commit three days earlier, and the release notes claim a “43x faster native scan engine” — a vendor claim, quoted as such.

It watches files in real time through inotify, batching events with an inotify_sleep default of 15 seconds. Compared with a periodic scan measured in days, that is a genuinely fast detection interval, and it is why maldet remains the sensible free choice. It also quarantines and offers limited cleanup.

If you run one server, have shell access, read your own logs and enjoy the work, maldet plus ClamAV is a defensible stack. What follows is not an argument that it is bad software. It is an argument about what you are responsible for when you choose it.

The dependency that decides your coverage

A signature-based scanner is only as current as its feed. maldet’s documented model is automatic daily signature updates. Measured from the vendor’s own CDN on 4 September 2026:

The infrastructure serves normally, and no end-of-life notice is published anywhere — so this is a maintenance gap, not a shutdown, and one push would change it. Check it yourself rather than trusting a date in an article:

curl -s  https://cdn.rfxn.com/downloads/maldet.sigs.ver
curl -sI https://cdn.rfxn.com/downloads/rfxn.yara | grep -i last-modified

For a fair control group we measured a paid ClamAV signature feed in the same category in the same pass — Malware Expert , €50 per month for unlimited servers — and it had been updated on 3 September 2026, the day before. So feed staleness here is a property of this particular free feed, not of signature feeds generally — which is exactly why the honest conclusion is narrow.

Two things follow. First, coverage lives in the feed, not in the scanner, and that is doubly true when ClamAV is the engine: ClamAV’s own documentation says it “is not a traditional anti-virus or endpoint security suite”, and there is no official claim of PHP webshell coverage anywhere on clamav.net. Second, nothing tells you when a feed stops. A scanner running against four-month-old signatures looks identical to a healthy one, right up until an incident.

That is the failure mode we designed against: every Shelltrap generation carries an expiry that must still be in the future when it is verified, feed state is a field in shelltrap health, and a missing active generation puts the daemon into degraded instead of quiet confidence. The full mechanism — signing, provenance, gating, rollback — is in signed signature feeds explained .

Architecture: inotify against fanotify

maldet watches with inotify. The kernel documents the consequences, verbatim :

Inotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional watches must be created.

On a hosting box that means a watch per directory, a per-user ceiling in /proc/sys/fs/inotify/max_user_watches, a documented race when new subdirectories appear, and a queue that can overflow. inotify is also notification-only: there is no permission-event mechanism, so nothing can be refused.

fanotify watches a whole mount “in a race-free manner” — the kernel’s own words — and supports permission events where “the recipient must write a response which decides whether access is granted or not”. It also needs CAP_SYS_ADMIN, and the man page warns about the risk of that capability being held by a process that receives file descriptors, which is why the privileged part should be small. The full comparison is in fanotify vs inotify .

Neither API gives you certainty. Both queues can overflow, so a periodic full sweep is not optional in either design.

What differs, axis by axis

Where a cell says “not claimed”, it means the project’s own material does not claim it. That is not a test result, and we have not run one.

Speed of detection is the wrong axis to argue about

Fifteen seconds versus a few seconds is not the difference that matters. Patchstack’s measured weighted median time to first exploitation is five hours ; both designs are far inside that window, and both are far ahead of any periodic scanner.

The differences that matter on a hosting platform are the ones above the detection loop: whether the rules you run can be attributed and rolled back, whether the tool can be operated per customer, and whether the record it leaves will support an incident report.

When maldet is the right choice

• One or a few servers you administer personally.
• You will actually monitor feed freshness — and now you have the two commands to do it.
• You do not need per-domain policy, delegated panel access, or an audit trail for a regulator.
• Budget is the binding constraint, and a free tool that you supervise beats a paid tool you cannot afford.

When it is not

• Multi-tenant hosting where policy has to differ per customer and support staff need a UI that is not the shell.
• Any obligation to document detection and produce incident evidence — see quarantine or delete .
• Environments where an upload-time control is worth having in front of PHP.
• Situations where “who maintains these rules, under what licence, and how would I roll one back” needs an answer.

What this means for CyberPanel operators

1. If you run maldet, add a feed-age check to your monitoring today. Two curl calls, one alert, and the biggest silent failure mode in the free stack becomes visible.
2. Separate the two questions before you compare products: is the scanner maintained, and is the feed maintained. They have different answers here.
3. Do not switch on the basis of detection intervals; switch on the basis of policy, evidence and supply-chain assurance, or stay where you are.
4. If you evaluate a replacement, run it in report-only mode next to your current scanner for a week and compare findings; the procedure is in the report-only first week , and the installation path is in the installation docs .

Shelltrap ships signed, provenance-tracked signatures and tells you when they are stale — because a quiet scanner is the expensive kind. See what it does .