Scanner false positives: verify, allow a fingerprint and never ignore without analysis

Goal of the article

The Securantis scanner detects anomalies in files, the CMS core, plugins/modules and media. A “false positive” is a legitimate detection of unusual behavior or an uncommon signature that is not malicious. This article explains how to verify an alert, add a reversible fingerprint (allowlist) and why you should never “ignore” a signal without full analysis.

Prerequisites

• Administrator access to the Securantis interface (WordPress plugin or PrestaShop module) or to the SaaS customer area depending on your installation.
• For WordPress/WooCommerce: FTP/shell access to the site to inspect the detected files and the ability to start or continue a scan from the interface.
• For PrestaShop: FTP/shell access and access to the PrestaShop back office where the Securantis module displays alerts.
• Recent full site backup (files + database) before any modification.
• Never transmit passwords via email or chat; if a paid intervention is required, accesses are provided only through the secure customer area after payment.

Overview of the process

1. Review the alert: read the description, the level (info/alert/critical), the files and the grouped fingerprint.
2. Reproduce the context: open the file locally, check the theme/plugin author, modification date, and compare with official sources.
3. Decide: confirm it is clean, add an allowlisted fingerprint, or isolate / manually quarantine if suspicious.
4. Document the justification and keep the backup before any deletion.

Detailed verification (tasks to perform)

• Read the complete information provided by the alert: file location, type of detection (heuristic signature, obfuscated code, execution in uploads), score and context (progressive scan or history).
• Compare the file with a clean version: retrieve the original version of the theme/plugin from the official repository or the archive provided by the vendor.
• Search for legitimate changes: known customizations, business plugin generated by an internal developer, or site-specific features.
• Check the timeline: modification date/time, user who modified it, deployment logs or CI/CD system records.
• Perform a local static analysis: open the file in an editor, look for unexpected external URLs, dynamic execution functions (eval, base64_decode), inline HTML/JS injections.
• If the alert concerns the uploads folder (executable files in media), verify whether uploads analysis is enabled. If not, enable it temporarily to investigate rather than ignoring the rule.

Allowlisting a fingerprint — best practices

• Principle: explicitly allow a fingerprint only after full verification and documentation. Allowlisting must be the last action, reserved for detections that are clearly non-malicious.
• Steps:
  1. Backup the file and the database before any modification.
  2. Document the reason (e.g.: “function X added by integrator Y on DD/MM/YYYY — plugin Z version”).
  3. Add the fingerprint to the allowlist from the Securantis interface (corresponding option in the module) specifying the scope (single site, specific path, limited duration if possible).
  4. Restart a progressive scan to verify the fingerprint is recognized and that the alert does not reappear.
  5. Keep the justification in your security notes or internal ticket.
• Caution rules: never allowlist globally for high-risk signatures (e.g. dynamic execution code); restrict it to the exact path or the specific version.

Platform-specific behaviors

WordPress / WooCommerce

• The scanner performs a progressive analysis and may flag modified files, themes, plugins and executable media. If the alert originates from a WooCommerce plugin (check the WooCommerce security tag), systematically compare with the official version.
• If the alert concerns the uploads folder, note that uploads analysis can be disabled in settings. Enable it to investigate, but be aware: a full scan of uploads can be long on large libraries.
• Use version control (if available) to compare changes. If you must allowlist a fingerprint, document it and limit the scope (e.g.: specific URL or folder).

PrestaShop (1.7 to 9)

• The PrestaShop module displays alerts in the back office with status and history. The same principles apply: compare the module/theme with the official archive, check modifications and installation logs.
• The module offers manual isolation of elements. Prefer manual quarantine when the origin is uncertain and only restore after thorough human analysis.
• Do not transpose WordPress interface labels: look for the equivalent action in your PrestaShop back office (activate/quarantine/allow) and follow the module’s local documentation.

Expected outcome after allowlisting

• The validated alert should no longer generate repeated alerts for the same fingerprint and scope, and your scan should display the justification.
• Site functionality remains intact and logs show no network activity or suspicious executions related to the allowed file.
• Any allowlist entry must be reversible: keep the backup copy and the justification so you can remove the allowlist if necessary.

Common mistakes and pitfalls

• Globally allowlisting an obfuscated signature: risk of exposing the site if the signature becomes malicious via update.
• Ignoring an alert out of habit without investigation: a threat can evolve and bypass controls if its origin is not analyzed.
• Assuming a “customized” file is safe without verifying the author and history: injected files can be renamed to appear legitimate.
• Not enabling uploads analysis when necessary: some malware stores webshells in that folder.

Troubleshooting

• If the alert persists after allowlisting: verify that the added fingerprint exactly matches (content fingerprint, path) and that the scanner cache was invalidated; restart a progressive scan and observe the phases (discovery, analysis, finalization).
• If you cannot retrieve a clean version: restore from a known clean backup before allowlisting the fingerprint.
• If the scan stops or fails: check the module (or agent) logs for timeout errors, PHP limits or file permission issues; temporarily increase the limit if the server allows and restart the phase.

Additional precautions

• Do not automatically delete detected files: deletion or quarantine must be a human decision and documented.
• Limit the duration of temporary allowlist entries and schedule periodic review.
• Keep offsite backups and regularly test restoration.

When to contact Securantis support

Contact support if:

• You doubt the legitimacy of a detection after your checks.
• The scan reports traces of network execution or active behavior (callbacks, scheduled executions) you cannot explain.
• You observe repeated scanner errors (job failures, “failed” phase) despite retries and resource checks on the server.
• You need an in-depth intervention (paid intervention): accesses will be requested via the secure customer area after confirmation and payment.

Conclusion

Verifying a scanner alert requires method and caution: analyze the content, compare with official sources, document the decision and restrict any allowlisting. Never ignore an alert without complete investigation. If uncertain, isolate the file and contact Securantis support for assistance.