Malwarebytes Quarantine and False Positives: Restore, Delete or Allow?

Choose the next action by certainty, not panic

Quarantine is the holding state. It gives you time to investigate without immediately returning a suspicious item to service or destroying evidence you may need. When the detection is unfamiliar, the safe first answer is usually to leave it quarantined and save the report.

Restore, delete, report and allow solve different problems. A restore answers “I need this exact item back.” An Allow list entry answers “I accept future protection being suppressed for this defined scope.” The second decision requires more confidence because its effect persists.

Our Malwarebytes scan-types guide explains which follow-up scan fits the incident. Don't compensate for an uncertain classification by running every intensive mode and then treating a clean result as permission to restore.

Quarantine isolates the item without asking you to trust it

The current Malwarebytes quarantine documentation, updated in its API on July 29, 2026, says a quarantined file, folder, application or program can no longer harm the device. The application stores it in a controlled state rather than leaving it available at its original path.

That reversible state is useful when an antivirus catches a component used by a legitimate application. The application may stop working because its file is unavailable, but the original item remains recoverable through Detection History until you delete it from quarantine.

Quarantine isn't a verdict. Malwarebytes can correctly isolate malware, flag a potentially unwanted program whose behavior requires your judgment, or make a false-positive detection that the research team later reverses. The same holding action is appropriate while those possibilities are separated.

Quarantine doesn't rewind activity that happened before detection

If an infostealer ran before it was quarantined, isolating its file doesn't revoke browser sessions, recover copied documents or change exposed passwords. If ransomware encrypted data before removal, the quarantine event doesn't decrypt it. Treat the file state and the incident impact as separate workstreams.

A detection may also be one component of a larger installation. The report can show a file, registry item, scheduled task, browser artifact or related traces, but one isolated object doesn't prove the entire chain is gone. Use an appropriate follow-up scan and investigate the original execution path.

Malwarebytes' current infection guidance directs unresolved cases toward diagnostics and Support. Our broader malware-removal guide covers containment, backup and account recovery beyond a single product action.

The current Windows and Mac path starts in Detection History

On current Windows and Mac builds, open Malwarebytes, choose Detection History and then Quarantined items. Select the item only after matching it to the report and original context. A familiar filename in an unfamiliar folder isn't the same file you intended to restore.

Windows offers Restore and can pair restoration with Exclude this from future detections. Mac exposes Restore and allow for the persistent choice. Interface labels can shift between releases, but Detection History and the separate quarantine and Allow list concepts are current as of July 30, 2026; our Malwarebytes for Mac review covers the platform's permissions and protection limits.

If those controls are missing or the application doesn't open, don't manually dig through protected quarantine storage. Preserve reports and use our current Malwarebytes setup guide or official Support before reinstalling, because a clean removal can erase useful local context.

Restore and Restore plus Allow carry different future risk

Restore returns the item to a usable location. If the detection rule remains active, Malwarebytes can quarantine it again during a scan or real-time event. That repetition may be inconvenient, but it preserves a second chance to catch a mistaken trust decision.

Restore plus Allow creates an exception. The current desktop Allow list guide warns that an entry should be added only when the file or application is known to be harmless. An exception can suppress future blocking for the chosen scope.

Choose Restore alone when you need a trusted file back temporarily while the vendor fixes a detection or when you want the next scan to reevaluate it. Choose an Allow entry only when recurrence is expected, the identity is stable and the narrowest supported scope is documented.

Delete only after evidence and recovery needs are settled

Deleting an item from the Malwarebytes quarantine list permanently removes that quarantined copy from the device, and the app can't restore it afterward. Save the report, hash and incident notes first. A security team or software vendor may need those identifiers even when the file itself shouldn't be retained.

Don't read “permanent” as a forensic promise that every previous copy, backup, sync version or storage remnant has been securely overwritten. Malwarebytes added a separate File Shredder tool in Windows 5.5.0.237, which underscores that ordinary deletion and deliberate secure erasure are different jobs.

If the quarantined item belongs to an application you still need, obtain a clean current installer from the verified publisher after deletion. Don't download a replacement from an alert popup, search ad, forum attachment or “driver fix” site that appeared during the incident.

Export the report before changing the state

The current scan-report guide says Windows can copy or export TXT reports and that scan reports are retained for up to 30 days. Save the detection name, original path, action, scan type, database version, date and time.

Windows' newer Detection History documentation also covers scan and real-time events. A Web Protection block, real-time file event and manual scan detection are different exposures even when a screenshot crops them into the same red warning color.

Redact usernames, email addresses, license details and private paths before posting a report publicly. Keep the detection label and enough path context for analysis. If a folder name itself reveals a client, patient or unreleased project, share it only through an authorized private support route.

Read the detection label with the path and event type

A family name can indicate known malware, a generic machine-learning classification, a PUP/PUM policy category, a blocked website or a behavior rule. The label alone doesn't tell you whether the file executed, whether it arrived through a browser or whether the item is part of a program you deliberately installed.

The original path often changes the interpretation. A signed driver inside the current publisher's installation directory has a different context from the same filename under a temporary folder or a user-writable startup location. Compare the full path, not just the basename shown in a notification.

Record whether the action was Quarantined, Blocked, No action or Allowed. A website block may identify the process that attempted the connection. A scan result may identify a dormant archive. Don't claim an active infection when the report only proves a stored item was found.

Verify the exact file, not the product name printed beside it

Start with provenance: where did the file come from, who published it and why was it present? Prefer the vendor's official site or signed updater. Cracks, loaders, unofficial repacks and email attachments don't gain trust because they impersonate a recognizable product.

On Windows, inspect the digital signature and publisher, then compare the version with the vendor's current release. On Mac, check the developer signature and notarization context where available. A valid signature raises confidence in identity, but a vulnerable or abused signed component can still deserve removal.

Calculate or copy the SHA-256 hash when the report provides it. A hash identifies the exact byte sequence, unlike a filename that anyone can reuse. Search for an existing vendor advisory or analysis by hash before uploading the file itself.

If the legitimate vendor released a fixed build, update from that source and compare the new hash. Restoring an old vulnerable driver merely because it was once legitimate can recreate the risk that the detection was meant to contain.

A multi-engine result is evidence, not a vote

A low detection count can support a false-positive hypothesis when the file is current, signed, obtained from the publisher and widely used. It can't prove safety. New malware, targeted tools and modified files may have little coverage, while generic heuristics can produce isolated mistaken detections.

A high count increases concern but still needs identity and timing. Old installers, bundled offers and administrative tools can trigger mixed categories. Compare specific labels and dates rather than reducing the report to a green or red fraction.

VirusTotal's official service explanation says it combines more than 70 scanners and other signals. It also says reports and submissions contribute to a shared community and partner ecosystem, which matters before you upload anything.

Search the hash before publicly uploading a private file

Standard VirusTotal submissions aren't a private help desk. Its documentation says reports are shared with the public community and that submitted content may be available to examining partners and premium customers. Never upload confidential documents, proprietary binaries, customer data or personal records without authority.

Searching an existing SHA-256 report can provide context without transferring your copy. If no report exists and the file is shareable, confirm that you own it or have permission. If it contains secrets, use an authorized internal security team, the legitimate software vendor or a private support channel.

VirusTotal offers a separate paid Private Scanning service, but its private analyses don't include the familiar multi-antivirus verdicts. “Private mode” isn't a checkbox on the standard public upload form.

A screenshot of scanner counts can also leak a filename, username or hash tied to a private incident. Crop and redact carefully, and never paste an active malicious URL as a clickable link into a public forum.

PUP and PUM labels require a behavior decision

A potentially unwanted program can be genuine software that bundles advertising, changes browser settings, uses aggressive sales tactics or behaves differently from what the user reasonably expected. A potentially unwanted modification can be a system change with both legitimate and abusive uses.

The current Windows scan settings let users Ignore, Warn or Treat PUP/PUM detections as malware. That configurability isn't a declaration that every item is safe; it acknowledges that user intent and environment matter.

If you didn't knowingly install the bundle or want the modification, keeping it quarantined is reasonable even when the code isn't a Trojan. If browser adware or a bundled installer is the actual problem, our Malwarebytes AdwCleaner review explains the specialist cleanup tool. If a business application requires the component, verify it with the publisher and create only the exception needed for the current signed build.

A July 2026 r/Malwarebytes discussion shows a user facing many PUP traces from one VPN program. A researcher explained a current Always ignore route, but that UI answer didn't independently prove the underlying program trustworthy.

Machine-learning and heuristic names describe detection logic

Labels such as MachineLearning/Anomalous indicate that a model found patterns associated with suspicious files. Malwarebytes' own detection encyclopedia describes that family as a generic machine-learning detection and directs disputed cases to its false-positive process.

“100% anomalous” in a label isn't a mathematically proven 100% probability that the file is malicious. It's part of a vendor naming scheme. Preserve the exact label, but base the restore decision on the file's identity, origin, signature, behavior and vendor review.

Heuristic detections can be valuable for new threats precisely because they don't require an exact known signature. Disabling the whole category to fix one trusted application sacrifices that benefit. Prefer a reviewed, object-specific exception.

Rootkit-mode detections need the original path and scan settings

Rootkit scanning can inspect locked drivers and other low-level objects differently from a normal Threat Scan. A copied or temporary-looking scan path may represent how the engine accessed a locked file rather than where the original application installed it. The full report is essential.

An April 2026 community case involved a driver associated with a temperature utility and a rootkit-mode scan. The discussion turned on the original path and a newer vendor version, not on the frightening filename alone.

Don't generalize that one case into “rootkit detections are false positives.” Rootkit rules are intensive and can change whitelisting context, but a vulnerable signed driver can still be abused. Update the legitimate product and submit the exact hash for review.

Report the disputed detection before normalizing an exception

The current false-positive reporting page directs paid subscribers to Support and free users to the Malwarebytes Forum False Positives area. A vendor correction helps other users and can remove the need for a permanent local exception.

Include the product and component version, Malwarebytes version, detection database information, exact detection label, original path, SHA-256 hash, legitimate publisher source and a redacted report. Explain what the application does and when the detection began.

Don't send only “this is safe” or a cropped red alert. Researchers need the identity and reproducible context. If the item is proprietary, say so and request a private route rather than attaching it to a public topic.

A February 2026 community report also shows why a performance problem isn't automatically a false positive. Export the actual detection or protection log before deciding which team should investigate.

Desktop Allow list types have different blast radiuses

Current desktop documentation supports files, folders, applications and websites. Windows can also allow a previously detected exploit. Malwarebytes 5.6.0.256, released June 11, 2026, simplified adding files and folders, so older v4 screenshots may no longer match.

A file entry is normally the narrowest. A folder entry can exempt current and future content placed inside it. An application or web exception can affect connection or protection behavior beyond one binary. An exploit exception should be treated as an advanced exception with a documented owner.

Don't add an entire drive, Downloads folder, user profile, browser data tree or development workspace merely because many items appeared in one scan. Scope the actual trusted component and ask why the detections are numerous before suppressing them.

The best exception is specific, owned and temporary

Record the approved hash, publisher, version, path, reason, approving person and review date. If the product updates frequently, decide whether a file hash or signed application identity can remain useful. A broad path rule may silently trust unrelated future content.

Prefer a file over a folder and a specific application over a global protection change when the current interface supports it. For a website, distinguish the exact host from a shared IP or whole parent domain. A broad network allow can affect traffic unrelated to the page you meant to reach.

After creating the exception, rerun the relevant small scan and test the application. Confirm that only the intended event stopped. If other warnings disappear, remove the rule and narrow it before considering the problem solved.

Every Allow list needs an expiry and removal test

Review entries after the legitimate application updates, after Malwarebytes confirms a false-positive fix and at a regular monthly or quarterly interval. Remove the exception, update both products and retest. An old rule shouldn't survive simply because nobody remembers why it exists.

The official Allow list guide says removing an entry lets Malwarebytes detect it again. That's a useful validation step. Export the list before a major cleanup, but don't automatically restore every historical exception onto a new device.

Investigate entries you didn't create. Malware, remote support tools or another administrator can alter security exclusions. Compare the timestamp with installation and incident history, and rotate credentials if unauthorized administrative access is plausible.

Restoring an Allow list JSON replaces the current list

Malwarebytes lets current Windows and Mac users back up or restore Allow list entries as JSON. Its documentation warns that restoring a list permanently replaces the current list. Treat the file as security configuration, not a convenience bookmark collection.

Store the export with access controls because it can reveal internal paths, applications and trusted sites. Review it before import on another machine. Paths, versions and business reasons can differ even between two devices owned by the same person.

After import, inspect every entry and test protection state. A stale exclusion can be more dangerous on a new machine because users assume a clean installation started with default coverage.

Automatic unquarantine is a vendor reclassification, not your guess

Current Malwarebytes documentation says Windows has Automatically unquarantine when detected malware is a false positive enabled by default. When Malwarebytes later classifies a detection as benign, the app can restore it automatically and record the event.

That setting doesn't mean the application trusts every item a user calls a false positive. It depends on the vendor's updated classification. Keep protection and detection databases current so a correction can reach the device.

If an automatically restored item belongs to software you no longer want, remove the application normally. “Benign” and “useful to me” are separate judgments, just as PUP classification and malware classification are separate.

A restored file can be detected again because Restore changes no rule

When the same hash returns with the same label, confirm that updates have applied and that the false-positive report was accepted. A local restore doesn't force the research backend to reclassify the item. The next scan can repeat the original decision.

If the path is the same but the hash changes, an updater or another process replaced the file. Reverify the new build. Don't extend trust from one signed version to every future binary placed under the same filename.

A May 2026 r/Malwarebytes case shows users relying on exported logs and hashes to separate repeated compiler detections from a broad infection claim. Treat that discussion as a case study, not a guarantee for another hash.

A clean rescan doesn't retroactively prove a false positive

A later scan can be clean because the item remains quarantined, the definition changed, the file moved, the scan scope differed or an Allow list rule suppressed it. Confirm which condition changed before declaring the first detection mistaken.

If Malwarebytes officially reclassified the exact hash and automatically restored it, that's stronger evidence than a clean counter alone. If you restored a different build from the vendor, preserve both hashes; the newer file may simply have removed the behavior or vulnerable component that triggered the first result.

Run the smallest relevant scan without an unnecessary exception, then review Detection History rather than relying on the final green screen. Our scan-types guide explains why Quick, Threat, Custom, Deep and rootkit scopes can't be compared as if they inspected identical objects.

An exception in another antivirus is a separate trust boundary

Malwarebytes can coexist with another security product, but the two Allow lists are independent. The current coexistence guidance warns that conflicts can affect protection, connectivity and stability and suggests allowing the security applications when necessary.

Don't copy every Malwarebytes exclusion into Microsoft Defender or another antivirus. Each engine may be catching a different layer, and a broad duplicate exception can create a gap neither product covers. Document which product raised the event and which component is being trusted.

Check current roles in our Malwarebytes versus Windows Defender comparison. A compatibility exclusion for a signed security driver isn't permission to allow an unrelated file that Malwarebytes quarantined.

If quarantine broke an application, recover from a trusted source

First identify the missing component and whether the publisher offers a fixed build. Restore only the verified item or reinstall the current signed application after saving the Malwarebytes report. Don't restore every trace because one program stopped launching.

If the application is essential for work, involve its vendor or your IT owner. They can confirm expected paths, signatures and hashes and may provide a private channel for the sample. A public forum is a poor place for proprietary plugins or customer-specific executables.

If you later remove Malwarebytes while diagnosing a compatibility problem, preserve the protection handoff. Our complete uninstall guide explains normal removal, the Support Tool and the moment another security layer needs to take over.

A website block isn't a quarantined local file

Web Protection can block a domain, IP address or connection attempted by a local process. Nothing may appear under Quarantined items because the event stopped network access rather than moving a file. Read the process, direction, host, port and time from Detection History.

An outbound block from an unfamiliar process deserves more caution than a browser reaching a mistyped domain. Don't allow a shared IP or whole domain until you know what else it covers. Scan the initiating file when one is named.

The current Detection History guide confirms that website and real-time protection blocks create reports in the same history area. Use the report rather than an old v4 screenshot; our forthcoming blocking-sites spoke will handle the complete troubleshooting intent separately.

Browser Guard maintains a separate site Allow list

The current Browser Guard guide lets users allow a website and select which protection categories to disable for that site. That control belongs to the browser extension, not the desktop quarantine list.

Disable only the category breaking a verified site. Turning off scam or malware blocking to fix cosmetic ad layout is a poor trade. Remove the exception after the site or extension changes and check whether another ad blocker caused the conflict.

Our Malwarebytes Browser Guard review covers Chrome, Edge, Firefox and Safari differences, data handling and the limits of extension-based protection. A site working after allowlisting proves compatibility, not safety.

Android offers Ignore once and Always allow, not desktop quarantine steps

The current Android scan guide lists Ignore once, Always allow, Delete file and Uninstall app. Ignore once leaves the item eligible for detection in the next scan, while Always allow excludes it from future Android scans.

For an installed app, verify the Play Store or publisher source, package identity, version and requested permissions. A sideloaded APK with a familiar icon isn't the same artifact as the store build. Delete or uninstall when provenance is weak.

The Malwarebytes mobile review explains current Android scanning and the absence of an iOS malware scanner. Don't follow a Windows registry or quarantine-folder tutorial on a phone.

iOS Web Allow list controls Safari sites, not files

Malwarebytes can't run a cross-app malware scan on iPhone or iPad, so desktop-style file quarantine doesn't exist there. The current iOS Web Allow list lets Safari access a trusted site that Web Protection would otherwise block.

Adding a domain doesn't certify every page, download or account prompt on that site. Verify the exact URL and remove the entry after a temporary compatibility issue. A phishing page on a compromised trusted domain can still be dangerous.

Use the iPhone security guide for platform controls that are technically possible. Any website promising to recover a Malwarebytes “quarantine file” from iOS is using desktop language where it doesn't apply.

Separate file recovery from account and identity response

If the original item could steal credentials, restore is the least urgent decision. From a clean device, revoke sessions, change important passwords, rotate API keys and contact financial institutions when relevant. Preserve the incident timeline before deleting local evidence.

Malwarebytes identity products can monitor some later misuse, but monitoring doesn't reverse an active session theft. Our identity protection review explains plan, family and policy boundaries without treating monitoring as malware cleanup.

For a suspicious message or link rather than a local file, use the Scam Guard review and platform-appropriate reporting. Don't paste private conversations or recovery codes into a public false-positive thread.

Practical quarantine decisions by scenario

These recommendations start with evidence quality, not how badly the user wants the file. Convenience is relevant after identity and risk are understood. A production dependency may justify fast private escalation, not a blind permanent exception.

For product-level protection and lab context, use our current Malwarebytes review. For feature and entitlement questions, compare Malwarebytes Free versus Premium rather than assuming a paid tier changes whether an unknown file is trustworthy.

Final decision: quarantine first, allow last

Leave an uncertain item quarantined, export the report and verify the exact identity. Restore only when the item is independently trusted and needed. Delete when it's confirmed unwanted and no longer needed for analysis. Report disputed detections so the vendor can correct protection for everyone.

An Allow list entry is the last step, not the shortcut. Keep it specific, record its owner and reason, retest after updates and remove it when the conflict is fixed. Never trade an entire folder, drive or protection category for one unverified file.

Keep platform boundaries intact: desktop quarantine, Android scan actions, Browser Guard site exceptions and the iOS Web Allow list are different controls. The most reassuring action isn't the most aggressive click; it's the decision that matches the evidence.