About
About Shelltrap and Panomity
We did not set out to write a malware scanner. We set out to keep our own CyberPanel servers clean, ran out of options we were willing to pay for, and built the thing we needed.
Who builds this
Panomity GmbH is a small company in Markt Schwaben, in the district of Ebersberg, about twenty minutes east of Munich by S-Bahn. We have been running hosting, web projects and immersive media work from here for years. The commercial details — register court, VAT number, managing director, insurance — are all in the imprint , where they belong.
The relevant part for you is this: we are a hosting operator before we are a software vendor. Shelltrap runs on our own production machines, with our own customers’ files on them, before it runs on yours. When the changelog says a bug produced a restart loop, that loop happened to us.
Why we built it
CyberPanel is a good panel. It is also a panel with no first-party malware scanner, and its documented route to one — Imunify360 — requires converting the host operating system to CloudLinux OS (CyberPanel knowledge base , checked 4 September 2026). That is a second commercial licence and a migration on top of the first, and for a stock AlmaLinux or Ubuntu host it is a lot to ask.
The tool that used to fill that gap for operators our size, ConfigServer eXploit Scanner, is no longer sold. The free tools — ClamAV, maldet — are useful and honest about what they are, but on a stock CyberPanel host they are a manual install with no on-write scanning and no panel integration.
So there was a real hole: no supported, low-friction, real-time malware scanning for a normal CyberPanel server. We had that hole on our own estate. We built for it.
What “made in Bavaria” commits us to
It is on the badge in the footer, so it should mean something specific:
The scanner runs where your files are. There is no upload of samples, no cloud analysis queue, no “we only send hashes, trust us”. Scanning happens in a worker process on your machine with no network access at all. The only two outbound connections in the whole product are the licence check and the download of signed rule generations.
Those two connections terminate in Germany. Our licence and feed services run on our own infrastructure here. There is no third-country transfer in the default configuration, which is the answer to the question every German and Austrian hosting customer asks in their data processing questionnaire.
We minimise what those connections carry. The licence check sends the key prefix — never
the key — a hash of /etc/machine-id, the hostname, the product version and the operating
system. It does not send file names, hashes of customer files, or counts of what was found.
Telemetry code is not merely switched off, it is not loaded without an explicit opt-in. That distinction matters: a switch can be flipped by a future default, an unloaded code path cannot.
Quarantined files are evidence. They are not deleted on package removal, they are not deleted on purge, and they only disappear behind an explicit environment gate that a human has to type. We would rather leave you with files you do not want than remove the one file your incident report needed.
The GDPR view, briefly
For the customer data on your servers, you are the controller and we are not a processor at all: we never receive it. Shelltrap is software you run, not a service that ingests your data. That is the cleanest possible position under the GDPR, and it is a consequence of the architecture rather than a contractual patch over it.
For the data the product does send us — the licence check and the feed request — we are the controller of a very small data set with an obvious purpose: proving a licence and delivering the rules you paid for. The privacy statement sets out each field, its legal basis and how long it is kept.
Where you need a data processing agreement for the hosting side of our relationship, we have one. Where you need one for Shelltrap-the-software, the honest answer is usually that you do not, and we will say so rather than sell you a document.
How we write about security
The articles on this site are written against a sourced dossier. The rules the editorial side works to are not decorative:
- Every number, date, quotation and vendor claim carries a link to a primary source.
- Where something could not be verified, it is either left out or explicitly marked unverified.
- We do not disparage other vendors, including the one whose product we are replacing. A planned wind-down is a planned wind-down, not an abandonment.
- Where a competitor’s data protection posture is discussed, only their own published documents are quoted, with the URL and the date it was read.
- Real incidents with real victims are written up as retrospectives, never as a scare-sell.
If you find a claim on this site that does not meet that standard, tell us and we will fix or remove it. Contact us .
The state of the product
Shelltrap is not shipping to customers yet. It is in an internal test stage on Panomity hosts, in report-only mode, and release 1.0 will carry the full scope: every platform tier, the panel UI with roles, the FTP enqueuer, profile measurement, the full CyberPanel platform matrix in CI and the repair path after a panel upgrade.
We would rather tell you that here than have you find it out after an invoice.