Verified Site Owner – Norton Safe Web False Positive for gearcustoms.com

[nguyendungbkc]

Issue abstract:
Norton Safe Web incorrectly rates gearcustoms as “Warning” and Norton is blocking customers from accessing the website.

Detailed description:
I am the verified site owner of gearcustoms, a legitimate WooCommerce e-commerce store.

Norton Safe Web currently rates the domain as Warning, and we have received a report from a customer that Norton is blocking access to our website as dangerous.

I have already submitted a False Positive / Safe Web re-evaluation request today through the Norton Submission Portal. I am posting here in parallel because the warning is currently affecting real customers and preventing them from accessing our store.

The Norton Safe Web report currently does not provide a specific threat, affected URL, malicious file, script, or redirect that we can investigate.

Could a Norton employee please help review or escalate the Safe Web rating for gearcustoms?

If Norton is detecting a specific security issue, please provide the detection name, affected URL, Alert ID, or other technical indicator so that we can investigate and remediate it immediately.

Domain: gearcustoms(dot)com
Norton Safe Web rating: Warning
Site ownership: Verified
False-positive re-evaluation: Submitted today

Thank you for your assistance.

Product & version number:
Norton Safe Web

OS details:
N/A – this issue concerns the Safe Web reputation of the website/domain.

What is the error message you are seeing?
Norton Safe Web rates gearcustoms as “Warning”, and a customer has reported that Norton blocks the website as dangerous.

Supporting screenshots:
Attached screenshots show:

1. Norton Safe Web displaying Warning while the site’s ownership is verified.

2. A customer reporting that Norton blocked access to the website.

[bjm]

@nguyendungbkc

Norton Safe Web incorrectly rates gearcustoms as “Warning” […]

Hello @nguyendungbkc
We’ll try to call attention:
https://gearcustoms.com/

Threat name: URL:Phishing
URL: gearcustoms.com
Detected by: Web Shield | URL scanning
Alert ID: 99ba18b9429d

48f56d220a4c/2026-09-08T19:56:12.455Z

48f56d220a4c/2026-09-08T19:56:12.455Z

[bjm]

https://gearcustoms.com/

AbuseIPDB » 104.21.20.43
We resolved the domain gearcustoms.com to IP address 104.21.20.43
IP Abuse Reports for 104.21.20.43:
This IP address has been reported a total of 3 times from 3 distinct sources. 104.21.20.43 was first reported on September 21st 2025, and the most recent report was 5 days ago.
Recent Reports: We have received reports of abusive activity from this IP address within the last week. It is potentially still actively engaged in abusive activities.

[nguyendungbkc]

Thank you very much for looking into this and submitting the detection for review.

I also noticed that the IP address shown in the AbuseIPDB result is a Cloudflare IP, as gearcustoms is proxied through Cloudflare.

I’ll wait for the Norton technical analysis and the review result within the next 48 business hours.

If Norton identifies a specific malicious URL, script, file, or other indicator on the site, please let me know so I can investigate and remediate it immediately.

Thank you again for your help.

[Selvakumar.S]

Hi @nguyendungbkc

Thank You for reporting the issue on Norton Community. The reported url is now resolved as False Positive. Could you please check now?

Thanks !

[nguyendungbkc]

Hi Selvakumar,

I’ve checked again and can confirm that gearcustoms is now showing as Safe.

Thank you very much for your help and for resolving the false positive. I really appreciate the assistance from you and the Norton Community team.

Thanks again!

[bjm]

[nguyendungbkc]

Hi @Selvakumar.S @bjm

Unfortunately, the issue has returned.

After the previous false-positive detection was resolved, gearcustoms was restored to Safe. However, today I received a Norton Safe Web notification stating that the rating has changed again from Safe to Unsafe after a recent re-evaluation.

I also checked my verified Site Details dashboard, and gearcustoms is now showing Warning again, even though the previous detection was confirmed as a false positive and the site had already been restored to Safe.

Since the notification specifically says the rating changed “after a recent re-evaluation,” could you please check whether this new Warning was triggered by the re-evaluation request from the previous false-positive case?

Could you also please check whether this is a recurrence of the previous false-positive detection or if Norton is detecting a new security issue?

If Norton is detecting something again, could you please provide the specific URL, script, file, threat name, or heuristic causing the automated re-evaluation to flag the domain? I would like to investigate and address the underlying cause so that the site does not get incorrectly flagged again after being cleared.

I have attached screenshots showing the Safe → Unsafe notification and the current Warning status in my verified Site Details dashboard.

Thank you very much for your continued help.

[bjm]

@nguyendungbkc

Unfortunately, the issue has returned.
After the previous false-positive detection was resolved, gearcustoms was restored to Safe. However, today I received a Norton Safe Web notification stating that the rating has changed again from Safe to Unsafe after a recent re-evaluation.

We’ll try to call attention:
https://gearcustoms.com/

Threat name: URL:EshopScam
URL: gearcustoms.com
Detected by: Web Shield | URL scanning
Alert ID: 7e79a0148b3d

000cf371a60b/2026-09-14T16:32:12.858Z

[bjm]

https://gearcustoms.com

[nguyendungbkc]

Hi @bjm ,

Thank you very much for checking and for submitting the false detection report. I’ve checked again as well, and I can confirm that gearcustoms is now showing as Safe.

Since the site was previously cleared as a false positive and then automatically flagged again a few days later as URL:EshopScam / URL:FakeShop, I’m concerned that the same issue could recur during a future automated re-evaluation.

Do you know if the URL:EshopScam / URL:FakeShop detection itself has now been corrected, or was the site rating simply changed back to Safe?

I’d like to make sure there isn’t an underlying signal that could cause the site to be incorrectly flagged again.

Thank you again for your help and for bringing this to Norton’s attention.

[bjm]

@nguyendungbkc

Since the site was previously cleared as a false positive and then automatically flagged again a few days later as URL:EshopScam / URL:FakeShop, I’m concerned that the same issue could recur during a future automated re-evaluation.

Do you know if the URL:EshopScam / URL:FakeShop detection itself has now been corrected, or was the site rating simply changed back to Safe?

I’d like to make sure there isn’t an underlying signal that could cause the site to be incorrectly flagged again.

Hello @nguyendungbkc
Sorry, I’m not privy as to why the detection occurred/reoccurred.
I imagine detection engines are dynamic.

1. Continuous Learning (AI Models)

• Constant Training: AI models do not just get built once. Security companies constantly feed them new data, like freshly discovered scams and safe websites.
• Brain Updates: This new data changes how the AI “thinks.” It helps the AI recognize tricky new patterns that it has never seen before.
• Adaptive Scoring: When a website changes its behavior, the AI instantly changes the site’s safety score up or down.

2. Live Cloud Updates (Detection Engines)

• Real-Time Sharing: In the past, antivirus software only updated once a week. Today, detection engines live in the cloud.
• Instant Fixes: The moment a security company finds a new threat, every computer using that cloud engine is protected a second later.
• Global Network: If a user in Europe blocks a new scam site, the detection engine instantly updates to protect a user in America.

3. Smart Behavior Monitoring

• Watching Actions: Dynamic engines do not just look at a website’s name. They watch what the website does.
• Spotting Traps: If a safe website suddenly starts acting strangely—like trying to steal a password or download a sneaky file—the engine will step in and block it immediately.

When a site gets flagged, cleared, and then re-flagged, it is likely caused by the dynamic nature of the AI models. The AI is reacting to something it still sees—or newly sees—on the website.

Here are the most common reasons why this “rubber-band” blocking happens:

1. Incomplete Clean-up (Hidden Leftovers)

• The Problem: The owner might have deleted the main malware file, but missed a hidden piece of code deep in the website’s database or files.
• Why it loops: A human analyst or a simple scan might clear the site initially. But hours later, a dynamic background scanner crawls the site again, finds the leftover code, and re-flags it.

2. Ongoing “Scam-Like” Behavior

• The Problem: E-commerce AI models look at things like pricing, return policies, and domain age.
• Why it loops: If an online shop sells items at prices that look “too good to be true” (like a $1,000 laptop for $50), or uses template text shared by thousands of known scam shops, the AI’s adaptive scoring will automatically flag the site again—even if a human just marked it safe.

3. A Re-Infection (The Door Was Left Open)

• The Problem: The owner fixed the website but did not fix how the hackers got in.
• Why it loops: If the site has an outdated plugin or a weak password, hackers can re-infect the site with scam pages or malware just minutes after it gets cleared. The detection engine is simply catching the brand-new infection.

4. Shared Server “Bad Neighbors”

• The Problem: Many small websites share a computer server with hundreds of other websites to save money.
• Why it loops: If one of those neighbor websites is running a massive scam operation, the security engine might temporarily block the entire computer’s address (IP address). This accidentally blocks the clean website too.

5. Aggressive AI Thresholds

• The Problem: Security companies constantly tweak their AI models to be more aggressive when new global scam waves hit.
• Why it loops: A website that passed a security check yesterday might fail today because the AI model was updated last night with strict new rules about what looks suspicious.

Flagged ➔ Cleared ➔ Flagged Again ➔ Cleared Again—is the classic fingerprint of an AI algorithmic loop, not an actual human security officer picking on their business.

Because the site is innocent, the site owner is getting caught in a battle between automated security rules and manual human corrections. Here is why this happens to clean websites:

1. The Dynamic Rules Changed Overnight
   AI security models do not use a fixed checklist. Security companies continuously push out updates to catch new waves of global e-commerce fraud.

• The First Flag: An algorithm update went live. It may have contained a rule stating: “Flag any shop that has X layout, uses Y payment phrases, and is hosted on provider Z.” The innocent site accidentally matched that strict pattern and got automatedly blacklisted.
• The First Clear: The owner submitted a dispute. A human analyst or a deeper verification scan looked at the site, realized it was totally legitimate, and manually clicked “Safe”.

2. The AI “Forgot” the Human Override
   This is the most common reason for the reoccurring flag.

• The Re-Flag: A few days or weeks later, the security backend rolled out a brand-new version of its AI model. If the backend system did not perfectly carry over the human “whitelist” exception into the new model’s brain, the new AI crawled the web, saw the same design patterns again, and re-flagged it. The automated brain overrode the past human decision
• The Second Clear: The owner complained again, forcing the system to re-verify the site and permanently hardcode a “do not flag this URL” exception into the core database.

3. A Third-Party Tool Flapped
   Most modern websites rely on external building blocks—like a chat widget, a review plugin, a font style script, or an ad network.

• If one of those third-party services had a momentary technical glitch, changed its web server, or was briefly compromised, the AI would immediately flag the owner’s site by association.
• Once that external tool fixed its own problem, or the security engine realized it was a false alarm, the site magically went back to “Safe.”

4. Overlapping “Risk Triggers”
   Even if a site isn’t a scam, it might share traits that scammers frequently use. This is called a false positive. If the site has a brand-new domain name, offers high-percentage discounts, or uses a common e-commerce theme that actual scammers like to copy, the automated engine will remain highly suspicious of it until it gains long-term domain authority.

Is the site safe now?
Since it is cleared again, the owner has likely broken out of the loop. The system’s master database has now logged multiple manual approvals, meaning the AI has finally “learned” that this specific domain is safe, making a third flag highly unlikely.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

When you look up the domain on the public Norton Safe Web Portal, seeing a Warning classification happens because the public portal uses a broader, consumer-facing rating system.

The public Norton Safe Web Portal rolls up the highly technical local alerts (URL:EshopScam / URL:FakeShop) into a simplified, user-friendly tier. Norton uses a color-coded hierarchy for the public:

• Safe (Green): Trusted site with no threats found.
• Caution (Yellow): The site has minor issues or annoying behavior, but isn’t explicitly malicious.
• Warning (Red): The site is known to be dangerous.

When the Safe Web Portal gives a domain a Warning classification, it is acting as the consumer-facing label for the backend threats.

When a website previously categorized under scam tags like URL:EshopScam or URL:FakeShop is cleared and rated as Safe, the backend system for Norton Safe Web triggers a specific, automated workflow.

The technical process flow executing behind the scenes involves the following stages:

1. Triggering Event (The Re-Evaluation)
   The process always starts with a reason to re-scan. This is usually an automated aging algorithm (rechecking old blocks) or a false positive dispute submitted by the site owner through the Norton Submission Portal

2. Backend Analysis & Verification Pipeline
   Once triggered, the backend initiates its multi-layered analysis:

• AI Code and Content Scanning: The Norton backend utilizes advanced AI to scan the site’s text, hidden code, and payment gateway layout. It checks against 120,000 known e-shop scam patterns to verify that malicious traits (like fake checkout pages or stolen brand logos) have been removed.
• Human Analyst Oversight: If the ticket came from a user dispute, a tier-2 security researcher manually reviews the AI findings to confirm the e-commerce shop is now legitimate.

3. Database State Update (The “Verdict Changer”)

• Once the system decides the site is safe, the Central Master Database (often powered by the WebPulse engine cloud) updates the global category identifier for that URL.
• The system strips the URL:EshopScam and URL:FakeShop flags and overwrites the status to “Safe” (Green rating).

4. Global Sync and Cache Flushing

This is where the fix rolls out to users worldwide:

• Cloud API Update: Live cloud lookups from the Norton Safe Web extension immediately begin receiving the new “Safe” classification.
• Local Cache Expiry: Endpoint security clients and corporate network proxies pull down the database updates. Old block listings stored locally on users’ machines expire and clear.
• Ecosystem Propagation: The safe status syncs across the broader security ecosystem, updating companion tools like the Genie Scam Assistant and Safe SMS protection filters.

AI sourced content may make mistakes

[nguyendungbkc]

Thank you, @bjm I really appreciate the detailed explanation and all your help with this issue.

I’ll continue monitoring the Norton rating and hopefully the false-positive detection will not recur.

Thanks again for your time and assistance!