Reporting a false positive

Before you send anything

A finding is not a verdict you have to accept in silence — every finding carries the signals that produced it, with engine, rule name and score, so you can read the argument before you argue with it:

shelltrap findings show <finding-id> --json

Two things worth checking first, because they resolve most reports without an email:

• Is the file actually yours? A plugin update that dropped an obfuscated loader into wp-content is a real finding, not a false positive, even when the plugin is one you paid for.
• Is it a heuristic hit? Heuristics only report by default; if the file was quarantined, it was a signature or hash match, which is a different conversation.

If it still looks wrong, send it. Getting a false positive is not an embarrassment for either side — leaving it in the feed would be.

What to send, and where

Send one mail to falsepositive@shelltrap.com .

It must come from the email address registered in your client area . That is how the pipeline recognises a licensed customer. Mail from any other address is not processed and receives no review — not as a policy about you, but because an automated allowlist that accepts files from strangers is an attack surface, not a support channel.

Include all four of these:

Without the file there is no automatic review. A hash alone cannot be re-scanned against the current rule generation and cannot be analysed, so a mail without the file falls back to the slow, human path.

If the file is in quarantine it is still on your machine — quarantine is evidence and nothing deletes it behind your back. shelltrap quarantine list gives you the object ID, and a restore puts the file back where it was, with owner, mode, times, ACLs, extended attributes and the SELinux context intact, so you can zip it up from there:

shelltrap quarantine list
shelltrap quarantine restore <object-id>

What happens next

1. Re-scan against the current generation. Rules move. The first thing the pipeline does is check whether the file still triggers anything at all under the rule generation published today, which by itself resolves a share of reports.
2. Automatic analysis. The file is analysed by an AI model running on Panomity’s own GPU hardware in Munich. It is handled as untrusted data and is never executed — no sandbox detonation, no interpreter, no third-party service, no external model provider. The file does not leave our infrastructure.
3. Hard rules the automation cannot override. A ClamAV signature match or a known-bad hash match is never released automatically. Those cases are routed to a human. An automatic allowlist entry over an exact malware hash is exactly the mistake a pipeline must not be able to make on its own.
4. The answer. Usually within an hour, from sentinel@shelltrap.com — the same address your findings come from, so it is already on your allowlist.

What a confirmed false positive changes

• Your file is cleared by SHA-256 in the allowlist of the next signed feed generation.
• That generation is published immediately. It does not wait for a release, a sprint or a maintenance window.
• Every licensed server picks it up at its next feed refresh. Other customers carrying the same file — a plugin, a theme, a vendored library — stop seeing the finding without ever having to report it.
• The rule itself is tightened in a later generation. Rule changes go through the known-good and known-bad corpus gate before activation, which takes longer than an allowlist entry and should. The allowlist unblocks you today; the rule fix stops the class of finding later.

On your own host you can then mark the finding as handled:

shelltrap findings resolve <finding-id> false_positive

A finding that is rejected, or that the pipeline will not decide on its own, becomes a ticket: open one in the client area and a human takes it. The automated answer is the fast path, not the last word.

What happens to your file

• It is stored only for the review, on Panomity infrastructure in Munich.
• It is deleted when the case is closed.
• What stays in the record is the SHA-256, the rule and the result — not the content of the file, and not its path on your server.
• It is never executed, and it is never passed to a third-party service or model provider.

The general statement about what the product itself sends us — which is a licence check and a signed feed download, and nothing else — is in the privacy statement .

The addresses, in one place

Why the defaults make this rare

The product is built so that a false positive costs you a mail rather than a customer:

• Only signature and hash hits quarantine by default. Heuristics only report, and PUA signatures are off.
• A known-good allowlist built from published distribution checksums — WordPress core and widely used plugins and themes, Laravel, Joomla — answers the most common cases before they become findings.
• Weak statistical signals never stand alone. Entropy or one long line will not produce a suspicious verdict by itself; minified bundles and caches stay clean.
• A rule generation that causes a quarantine storm across several accounts is rolled back automatically.

More on that reasoning: the heuristics engine and the Webshell Signal Explorer , which walks through six cases including the false positive that must never trigger an action.

Questions people ask