Webroot false positives: restore and allow safely

When uncertain, leave the file in quarantine

Webroot says quarantined items are disabled and can't harm the computer while contained. That makes quarantine the right place to investigate from. It preserves the option to restore a legitimate file later without creating an immediate exception in scanning or shielding.

Don't choose Restore because an app stopped opening, and don't choose Delete because the alert looks frightening. A required component can be either legitimate or malicious. Permanent deletion removes recovery and diagnostic value; restoration can suppress future detection.

The same filename appearing on many computers isn't proof of safety. A legitimate application update can trigger a shared false positive, but a compromised update can spread just as widely. Community reports increase the urgency of vendor confirmation; they don't replace it.

Use this sequence before changing the rule.

1. Leave the detected file in quarantine

   Don't restore or allow the file while its classification is uncertain. Quarantine disables the item and preserves it for verification, vendor review or later recovery.

2. Record the detection and original path

   Save the detection name, filename, original path, timestamp, Webroot edition, operating system and scan log before changing a detection rule.

3. Verify the official source and expected location

   Confirm the file came from the publisher's real download or updater and that its directory matches the legitimate application. A familiar filename in an unexpected path isn't reassuring.

4. Check the digital signature and cryptographic hash

   Validate the publisher signature and compare the file hash with an official release value when one exists. Treat a missing, invalid or unexpected signature as unresolved evidence.

5. Seek publisher and Webroot confirmation

   Check the software vendor's advisory and submit the file to Webroot as False Positive detection. Community agreement and a clean result from one scanner are signals, not proof.

6. Choose the narrowest verified local action

   In SecureAnywhere use Restore, Allow or Monitor only for the exact verified executable. In Total Protection use Restore or Exclude & Restore with full awareness that an exclusion is being created.

7. Remove the temporary exception after reclassification

   When Webroot confirms or corrects the classification, remove the local Allow, Ignore or exclusion so future versions are evaluated normally.

8. Update, rescan and verify the application

   Install the publisher's current clean build, run the appropriate Webroot scan and confirm the application works without a broad folder exception or repeated quarantine.

Separate supporting signals from actual proof

A likely false positive often appears immediately after a signed application update, lives in the publisher's expected directory, carries a valid signature and matches an official release hash. The software vendor may acknowledge the issue, and Webroot may confirm a classification correction. Confidence comes from several independent signals agreeing.

A true or unresolved detection deserves containment when the file came from a mirror, email attachment, mod bundle, cracked installer or temporary directory; has no valid signature; runs from an unexpected user profile; requests persistence, credential or script-injection access; or returns with different hashes. A familiar product name doesn't cancel those warning signs.

A clean result from one other scanner is another signal, not a guarantee. Detection engines use different telemetry and timing. New malware may be missed, while a newly compiled legitimate file may not yet have reputation.

Preserve evidence before restoring or allowlisting

Record the detection name, exact filename, original path, file size, event time, Webroot product and operating system. Save the scan log and a screenshot of the report. If the application updated, record the old and new version.

Obtain the file's SHA-256 hash without moving it out of quarantine through an unsafe workaround. Use a clean copy from the official publisher when the quarantined copy is inaccessible, and make sure the version is identical. Compare only with a hash published or supplied through a trusted vendor channel.

Check the digital signature in the operating system. The certificate must be valid and name the expected publisher; a signed file isn't automatically safe if the signer is unrelated or the certificate is compromised. Note any timestamp and revocation warning.

Keep this evidence with the Webroot case. It lets Threat Researchers distinguish a specific build from every file sharing its name and helps explain why a local rule fails when the updater later produces a new hash.

SecureAnywhere Restore changes future detection behavior

Open SecureAnywhere, select the gear beside PC Security and open Quarantine. Highlight the exact item and choose Restore only when the file is verified. Webroot's quarantine guidance says the file returns to its original location.

The important consequence is easy to miss: SecureAnywhere says it will no longer detect a restored item during scans unless the detection rules are changed. Restore is therefore not a temporary peek. It alters how that item is treated and can return an unsafe file to service.

If the program is urgently needed but verification is incomplete, use another known-clean device or an official web version rather than restoring under pressure. A deadline doesn't improve the evidence.

After restoration, run the application only when its expected network and file behavior can be observed. Save a clean installer before changing more rules. If the detection returns, stop the restore loop and submit the new current file.

Understand SecureAnywhere Allow, Block and Monitor

SecureAnywhere's Block/Allow Files controls specific executable files. Open PC Security, Block/Allow Files, select an existing item or add the exact executable, then choose the required radio button.

Allow tells scanning and shielding to ignore that file. Block prevents it from executing or being written. Monitor watches the program while Webroot determines whether it's legitimate or related to malware. These choices override default scanning and shielding behavior.

Allow is the narrowest operational fix only after verification; it isn't a request to change Webroot's cloud determination. Monitor is useful when Webroot or support directs it, but it isn't a promise that every risky action will be harmless. Block remains appropriate when identity is unresolved.

Add only the exact EXE, DLL, SYS, DRV or COM that was reviewed. Never allow a whole download, game, mod or development folder. A directory exception gives future files a path around normal evaluation.

Don't press Remove all merely to “reset” the pane. That can erase deliberate Block or Monitor decisions along with a temporary Allow. Record the old state and remove one obsolete exception at a time.

Total Protection Restore and Exclude & Restore aren't identical

In Total Protection, open Virus Protection and Quarantine or inspect Report Details. The current scan/report guide documents Restore for a suspected false positive and a separate Exclude & Restore from Quarantine action.

Restore returns the file. Exclude & Restore also creates an exclusion, so the scanner no longer evaluates it normally. Use that combined action only when the exact current file is verified and immediate operation is necessary. Preserve the report and plan to remove the exception.

Manage Exclusions opens the Allow/Block Files area for excluded items. The detailed scanner reference also notes that Scan Options defaults to Recommended; don't weaken global automatic-removal behavior to rescue one file.

Webroot doesn't recommend Delete from Quarantine without support guidance. Deletion and exclusion solve opposite problems and neither establishes whether the original classification was correct.

Mac controls differ by Webroot edition

Classic SecureAnywhere for Mac exposes Mac Security and its Quarantine or Block/Allow views. Total Protection for Mac has a simplified interface and an Ignore List for applications the scanner ignores. Don't copy a Windows path and assume the same tabs exist.

An Ignore entry is still a local exception. Verify the exact application bundle and publisher, and remove the entry after correction. A broad application or folder exemption can hide a replaced helper inside an otherwise legitimate bundle.

If the file can't be restored because macOS permissions are incomplete, first confirm Full Disk Access for the official Total Protection app. Don't grant terminal commands or third-party cleanup tools system-wide access to work around quarantine.

When Webroot blocks a signed updater, obtain the latest installer directly from the publisher and compare the signature. A fresh clean install can be safer than restoring one internal component whose provenance is unclear.

Submit the current file to Webroot Threat Researchers

Webroot's consumer false-positive route says to restore only when certain the file is safe, submit the affected file and choose False Positive detection. If uncertain, contact support instead of restoring first.

In SecureAnywhere, open Utilities, Reports and Submit a File. The submission guide opens a browser form where the reason can be Malicious file, False positive detection, Monitored file or Safe file. Choose the reason that describes the dispute rather than labelling every inconvenience “safe.”

Submit the exact build and hash that Webroot detected. Include product version, operating system, original path, detection name, signature and publisher URL. If the updater recreated the file, the replacement may not be byte-for-byte identical to the first quarantined copy.

When the form fails or the file can't be recovered safely, use the official support message route and categorize the case as Threat Found - False Positive. Send from the affected computer when possible, as Webroot requests, but don't expose account credentials in a public forum.

Don't upload sensitive files to public multi-engine services

A multi-engine scanner can help with an ordinary public installer, but uploaded samples may be shared with security vendors and researchers. Never submit private keys, password databases, customer documents, proprietary source builds, medical/legal records or regulated data merely to collect a row of green results.

For a sensitive file, contact the software owner and Webroot through official support. Describe the hash, signature, detection and business impact first, then agree on an approved protected transfer method. The hash itself can identify the build without exposing its contents.

Even for a public file, scanner consensus isn't proof. Engines can share signatures, lag behind a corrected release or miss a new compromise. Combine it with source, signature, expected behavior and vendor confirmation.

Don't disable automatic Webroot threat-research submission globally as a reflex. Privacy requirements differ; if the device handles protected data, review the product's submission setting and organizational policy deliberately rather than changing it during an incident.

A blocked website needs a BrightCloud review, not file allowlisting

If Web Threat Shield blocks a URL but no executable was quarantined, use Webroot's website review process. BrightCloud handles the URL reputation determination and exposes a Request a change form below the lookup result.

Submit the exact URL, including subdomain and path when relevant, plus site ownership and remediation context. A home page can be clean while one download or redirected path remains risky. Don't request the highest reputation solely to bypass the warning.

OpenText also documents a separate URL determination change request. A screenshot of the block page is supporting evidence; it isn't the sample file used for malware reclassification.

Keep the site blocked while the determination is unresolved. Adding a broad browser or Web Threat Shield exclusion can expose other users and future pages on the same compromised host.

Software vendors should dispute the release, not train customers to bypass it

Webroot's vendor false-positive guidance allows a developer to submit the file or use a vendor dispute form. The form provides an email channel for questions and completion updates.

Send product name, affected version, exact hashes, signing certificate, clean download URL and a technical contact. Stable code signing and reproducible release hashes make it easier to distinguish a legitimate update from a modified copy.

Publish a temporary advisory only after the affected hash is known. Tell customers to leave the file quarantined or use the narrow exact-file workaround confirmed by Webroot. Don't recommend disabling shields or excluding the installation directory.

When many customers are affected, a vendor correction is more durable than hundreds of local Allow entries. It also reduces the risk that users allow an unrelated malicious file with the same familiar name.

If Webroot keeps deleting the file, stop repeating Restore

The updater may create a new version with a different hash, place the file in a different path or replace a helper process. A local exception tied to the old item won't necessarily match it. The cloud classification may also remain unchanged because no vendor review has completed.

Record the new hash and path. Compare them with the submitted sample and publisher release. If they differ, submit the current file rather than assuming the previous case covers it. Repeatedly restoring each version creates a chain of exceptions without solving classification.

A malicious process can also recreate a file after quarantine. Run the broader scan described in the Webroot scans and quarantine guide, preserve logs and check startup/persistence evidence with support. Don't add the parent folder to stop the alerts.

If the application install is now incomplete, use the official publisher repair or reinstall package after the file is classified. The Webroot uninstall guide is for a damaged security installation itself, not for removing Webroot merely because it found a disputed third-party component.

Remove the local exception after Webroot corrects the classification

A temporary Allow, Ignore or exclusion can outlive the original incident. When Webroot and the publisher confirm correction, remove that exact local rule so future versions and replacements return to normal evaluation.

In SecureAnywhere, revisit PC Security and Block/Allow Files. Remove or change the exact entry rather than using Remove all. In Total Protection, open Manage Exclusions or Allow/Block Files. On Mac, review the Ignore List.

Update the application from its official channel after removing the exception. The new build may have a different hash and may already carry the corrected reputation. Keep the case response and release version with your records.

A corrected cloud classification and a removed local exception are separate evidence. Confirm both. Otherwise the app may work only because the device still ignores it, hiding whether the vendor fix reached the endpoint.

Rescan and verify application integrity without a broad bypass

Run a Custom scan of the verified application folder, then the edition's normal broader scan when the original detection involved persistence, scripts or multiple paths. Check Quarantine and Reports for the old and new hashes.

Launch the application and verify its expected functions, updater and signature. Watch for a new detection at startup or update time. A clean launch with no local exception is stronger evidence than a one-time run under Allow.

If Webroot continues to flag the exact hash after a confirmed correction, save the fresh scan log and reopen the case. Don't create wider exclusions to silence an inconsistent endpoint.

If reinstalling Webroot is genuinely necessary, preserve the account and keycode details and use the verified setup guide. A reinstallation shouldn't erase the evidence or substitute for file reclassification.

Business-managed devices need the console administrator

OpenText Core Endpoint Protection has management-console overrides and agent commands that don't belong in a consumer guide. A business administrator can create global good overrides and restore files across endpoints, but that changes policy for more than one device.

If SecureAnywhere reports that it's managed by the Web Console, preserve the detection and contact the organization or service provider. Don't try to defeat the console with local registry edits or a personal Allow rule.

Give the administrator the same evidence: exact hash, path, signature, product version, detection time and vendor response. A global override should be as narrow and temporary as the consumer exception, with a documented removal point after cloud correction.

For a personal machine inherited from an organization, resolve management ownership before restoring files. The current Webroot review and plan comparison cover consumer products; they aren't business-console instructions.