PrestaShop Quarantine: Human Decision-Making, Restoration and Handling False Positives

Purpose of the article

This guide explains how to use the quarantine feature of the Securantis module for PrestaShop: when to isolate a file or item, how to restore it safely, how to manage and correct false positives, and what precautions to take to avoid disrupting a production store.

Target audience and prerequisites

• PrestaShop store administrator (back-office access with sufficient rights to manage the Securantis module).
• Securantis module installed and enabled on PrestaShop 1.7 to 9.
• Active Securantis license and cloud synchronization operational (to receive alerts and reports).
• Recent backup available (files and database) — quarantine and restoration are irreversible operations without a reliable backup.

When to use quarantine

• Detection of a file identified as malicious or altered abnormally (e.g. unknown code in an override, executable in uploads).
• Immediate risk to integrity or confidentiality (e.g. rootkit, webshell) and need for rapid isolation to limit impact.
• Ongoing analysis where responsible parties want to isolate the item while awaiting a human decision.

Important: quarantining isolates the file but does not permanently delete it. Any permanent deletion must be decided by a human after analysis.

Recommended procedure — quarantine (steps)

1. Check the alert in the Securantis interface in the PrestaShop back office: read the provided context (alert type, affected file or item, severity, timestamp).
2. Export or copy the alert and the provided hash to your investigation folder (do not send passwords by email).
3. Confirm that a recent backup covers the file and the database. If not, make a backup before any modification.
4. If the decision is to isolate, enable manual quarantine from the Securantis action panel for the targeted item. The operation moves the item to a secure non-executable location and logs the event.
5. Document the decision: reason, person who authorized the quarantine and measures taken.
6. Monitor the store operation and logs after quarantine (to detect any side effects on the site or triggered rules).

Expected result

• The file or item is moved to quarantine and made non-executable.
• An audit record is generated with the reason, the actor and the hash.
• The store remains accessible if the module is configured in fail-open mode; only functionalities directly related to the isolated item may be affected.

Caution about settings

• Quarantine permissions: you can restrict quarantine to desired item types (files, modules, themes). Limit automatic operations on core critical elements or payment modules.
• Fail-open mode: ensure the fallback configuration is active to prevent an internal error from blocking the store.
• Keep the manual quarantine feature enabled only for trusted administrator accounts.

Handling a false positive — detailed procedure

1. When the alert appears legitimate (e.g. new module, developer override), retrieve the full message and the recorded hash.
2. Compare the isolated file to the legitimate source repository (theme, module or code provided by the developer) and to backups.
3. If the file is expected and clean:
   • Restore from quarantine to its original location via the module's restore action.
   • Update the exclusion list or mark the alert as "legitimate" to avoid further quarantines for the same reason.
   • Document the reason for the false positive and the justification (developer log, known hash, module version).
4. If the alert is ambiguous:
   • Take a copy of the quarantined item for analysis (via audit export) and send it to your internal security team or a vendor for in-depth review (without sharing passwords).
   • Leave the file in quarantine until a clear decision is made.

Restoration — steps and checks

1. Verify that the restoration path is safe and that the original directory tree has not been maliciously modified since isolation.
2. Restore from the module's quarantine manager.
3. After restoration: clear PrestaShop cache, rebuild necessary indexes (if applicable) and check error logs.
4. Test related functionalities (order flow, payment, back office) to ensure no adverse effects appear.
5. If the restored file was indeed problematic, immediately re-quarantine it and proceed with deletion or manual correction after analysis.

Common errors and how to fix them

• "Quarantine folder not writable": check filesystem permissions of the quarantine folder and the PHP user running PrestaShop. Do not grant excessive permissions (avoid 777).
• "Quarantine disabled": explicitly enable quarantine in Securantis settings, then retry.
• Restoration impossible because the original path changed: restore the copy offline manually, compare, then replace the item using a safe deployment procedure.
• Impact on the store after quarantine: check whether the isolated item was used at runtime (payment module, front override). If so, restore temporarily and schedule a maintenance window.

Advanced troubleshooting

• Check Securantis logs and PrestaShop/PHP logs for any errors related to quarantine or file access.
• Confirm that the Securantis module has access to disk space and to the quarantine folder (free space, SELinux/AppArmor, quotas).
• If quarantine ran automatically and seems abusive, export the full alert (timestamp, triggered rule, hash) and add the entry to exclusions after verification.
• For repeated failed restorations, perform a manual restore from backup and compare file permissions and owners.

Legal and operational precautions

• Never permanently delete a suspicious file without archiving and documenting it.
• If customer data may be compromised, follow your regulatory obligations and internal processes before any public communication.
• Any sharing of access with vendors must be done through the secure client area after commercial agreement; never send passwords by email or chat.

When to contact Securantis support

Contact support if:

• Quarantine does not work and shows blocking error messages after basic checks.
• You suspect an advanced compromise (confirmed webshell presence, persistent behaviors after restoration).
• You have difficulties configuring scan exclusions or rules to avoid mass false positives without endangering the store.

What support may ask for

• Detailed description of the alert, timestamp, severity level and hash of the isolated file.
• Controlled and temporary access (provided only via the secure client area after commercial agreement if a paid intervention is required).
• Application logs and screenshots of the Securantis interface showing the alert (never passwords).

Conclusion

Quarantine is a powerful tool to quickly isolate suspicious items while retaining human control over sensitive decisions. Always prioritize backups before any action, document every intervention, and use restoration and exclusions only after verification. If in doubt about the nature of a file or its operational impact, keep the item isolated and seek expertise before permanent deletion.