A suspected false positive needs evidence and review. Keep the warning visible while you establish what the file does and whether it matches a trusted release. A filename that looks familiar is not enough to establish that its contents are harmless.
01 Build a review request
- Open the affected site's scan details and note the scan time, path, classification and reported action. Distinguish Suspicious Files from confirmed malicious files.
- Preserve the result and relevant logs. Avoid running a suspicious file or pasting its code into a public forum.
- Ask the application maintainer to compare the file against the exact official release or your approved source repository. Record whether a recent deployment, generated cache or legitimate integration explains the change.
- Send us or the authorised SiteLock support route the finding reference, application version, expected purpose and comparison evidence. Use the approved secure method if an actual sample is requested.
- Keep any temporary mitigation narrow. Do not exclude an entire website, file extension or uploads tree merely to remove one alert.
- After review, apply the recommended correction or specific exception, then scan again and verify the application still functions.
Common questions
Can I restore a file that cleanup changed?
Preserve both versions and obtain a developer review first. Restoring the original blindly can reintroduce the same malicious code. If essential functionality broke, explain the affected action and its urgency in the support request.
Does a suspicious classification mean I can ignore it?
No. It means the finding needs interpretation rather than an unsupported conclusion. Check its source, behaviour and review status.
Should I turn off automatic cleanup during the review?
Only make that choice with the person responsible for the incident and after understanding the exposure. Record the change and the condition for restoring normal protection. An exception must not become an undocumented permanent gap.