False Positive – Norton Safe Web Still Flagging Clean Website After Dispute Submitted

Hello Norton Community,

I am posting here on behalf of the owner of roysreport . com in hopes that a Norton staff member can help escalate our case, as the automated dispute process has not resolved our issue.

Situation Summary:
Our website was previously compromised but has since been fully remediated, cleaned, and secured. We have submitted a dispute through the Norton Submission Portal and via Norton Safe Web, but the warning flag remains active.

Key Evidence:
• Google Safe Browsing confirms the site is clean
• The majority of security vendors on VirusTotal have cleared the site
• Sucuri SiteCheck confirms no malicious content is present

Submit a file or URL to Norton for review

Note: after submitting dispute and waiting 48 business hours with no change.
Please contact official Norton Support and advise support that you’ve submitted dispute and waited 48 business hours. My understanding is…once you state that you have already submitted False Positive over the submission portal and waited 48 business hours…support agent shall take the URL and detection screenshot and advance the case.

Submission Portal: Norton Submission Portal. This system is used for tracking false positive reports.
Site Ownership: Ensure you have officially “claimed” your website within the Safe Web portal. Verified owners generally have access to a dashboard where they can see the status of their site and any pending disputes without relying solely on email notifications.
48 hours: Community suggests waiting 48 business hours. If the status of your site has not changed on the Safe Web public lookup after this time, it likely means the dispute is still in the queue or was not processed.
Norton Support: If you haven’t received an email or a status change after 48 hours, contact official Norton Support directly. Explicitly tell the agent: “I have already submitted a site dispute via the Safe Web portal more than 48 hours ago and have received no email notification or status update.” This often prompts support to escalate the ticket manually.

https://roysreport.com

Threat name: URL:Phishing
URL: roysreport.com
Detected by: Web Shield | URL scanning
Alert ID: cfc39f36bb45


39f06addc8d9/2026-05-08T21:08:53.949Z


39f06addc8d9/2026-05-08T21:08:53.949Z


@user13403 Have all the plugins you use ( if listed below ), have they also been updated? Thanks in advance.

AI Overview

WordPress 6.9.4, released on March 11, 2026, is a critical security update designed to fix vulnerabilities that were not fully addressed in versions 6.9.2 and 6.9.3. While this update addresses core security flaws, it was released amidst a high volume of plugin vulnerabilities in the broader WordPress ecosystem. [1, 2, 3, 4]

Key Plugin Vulnerabilities Reported (March/April 2026)

As of the 6.9.4 release, multiple widely used plugins had severe, unpatched vulnerabilities: [1, 2]

  • Smart Slider 3 (<= 3.5.1.33): A critical arbitrary file read vulnerability allows subscriber-level users to read sensitive files like wp-config.php, potentially leading to full site takeover.
  • MW WP Form (<= 5.1.0): An arbitrary file move vulnerability, affecting over 200,000 sites, allows unauthenticated attackers to move files, potentially enabling remote code execution.
  • Ninja Forms – File Upload: A vulnerability allowing unauthenticated attackers to upload arbitrary files, leading to remote code execution.
  • WP Visitor Statistics (Real Time Traffic) (<= 6.9.4): Vulnerable to unauthenticated sensitive information exposure via log files.
  • LearnPress – WordPress LMS (<= 4.2.6.9.3): Contributor-level users can exploit a time-based SQL Injection.
  • Revive Old Post (<= 6.9.4): Privilege escalation flaw, allowing attackers to update site options and gain administrative access. [1, 2, 3, 4, 5, 6, 7]

WordPress 6.9.4 Core Fixes

The 6.9.4 update specifically patches three core vulnerabilities that were improperly fixed in the preceding 6.9.2 update: [1, 2]

  1. PclZip Path Traversal: A critical vulnerability.
  2. Authorization Bypass: Found in the new “Notes” feature (introduced in 6.9).
  3. XXE (XML External Entity) Injection: Found in the bundled getID3 library. [1, 2, 3]

Action Required

  • Update Immediately: Update to WordPress 6.9.4 to ensure your core files are secure.
  • Audit Plugins: Check if you are running the affected versions of Smart Slider 3, MW WP Form, or Ninja Forms and update them.
  • Use Security Tools: Use plugins like Wordfence or Patchstack to scan for vulnerabilities, as 187 plugin vulnerabilities were reported in the April 2026 reporting period. [1, 2, 3, 4, 5]

SA

~ fwiw ~

The Sucuri result is probably accurate. It is not absolute proof.
“CMS: WordPress 6.9.4” from Sucuri is likely credible.

Sucuri reports: exact CMS, exact version, CDN, server/IP — then it usually found multiple indicators matching that version.

Common indicators include: asset version strings, generator tags, RSS metadata, known file fingerprints, JavaScript/CSS hashes

Remote scanners can misidentify versions occasionally.
Caching/CDNs like Cloudflare can sometimes confuse detection.
Some sites intentionally spoof version numbers.
Sucuri has had false positives and occasional incorrect warnings reported by WordPress users.

AI sourced content may make mistakes

Threat name: URL:Phishing
URL: roysreport.com
Detected by: Web Shield | URL scanning
Alert ID: 14bb943c86e5

https://roysreport.com/


de3c5d4c2b0c/2026-05-09T18:28:40.227Z


de3c5d4c2b0c/2026-05-09T18:28:40.227Z

Any thoughts on what else we can do? We have updated everything on the website that we can. Plugins are up to date. Malware is gone.

1 Like

Norton Support: If you haven’t received an email or a status change after 48 hours, contact official Norton Support directly. Explicitly tell the agent: “I have already submitted a site dispute via the Safe Web portal more than 48 hours ago and have received no email notification or status update.” This often prompts support to escalate the ticket manually.

Everyone: When visiting the site earlier today, I poked around with the alert that it presented. It suggested that the website cannot correctly negotiate a secure connection. I think that is the area needing attention. Another note is checking for your CURL libraries being updated and open SSL is present on the server hosting the website.

Edited: I also found this information that suggests “Global Conclusion: No DNSSEC records found at the domain level”.

https://www.ip-tracker.org/lookup.php?ip=Roysreport.com

SA

https://roysreport.com/


Looking at the report from earlier its stating their SSL certificate was renewed May 9th, 2026 and is now valid. The site still sets off security stating its a phishing site my side.

SA

Hello @user13403
https://roysreport.com/ — review requested — Norton support — case number 10nnnnn23

https://www.abuseipdb.com/
We resolved the domain roysreport.com to IP address 104.21.25.81
IP Abuse Reports for 104.21.25.81
This IP address has been reported a total of 1 time from 1 distinct source. It was most recently reported 3 years ago.
Old Reports: The most recent abuse report for this IP address is from 3 years >ago . It is possible that this IP is no longer involved in abusive activities.

==============================================

AI sourced content may make mistakes

According to the report listed here, and as I suggested earlier, the domains DNSSEC records are “unsigned” per this link. Please scroll to the bottom of the page to review. My professional suggestion is discussing this issue with the provider and CloudFlare as CloudFlare is the TLD ( top level domain ) registrar.

AI Overview

DNSSEC (Domain Name System Security Extensions) records are cryptographic signatures added to DNS data to ensure its integrity and authenticity, preventing attackers from redirecting users to malicious websites. They protect against cache poisoning and man-in-the-middle attacks by verifying that DNS responses come from the legitimate server and were not altered in transit. [1, 2, 3, 4]

Key DNSSEC record types include: [1, 2]

  • RRSIG (Resource Record Signature): Contains the actual digital signature for a DNS record set, validating its authenticity.
  • DNSKEY (DNS Key): Stores the public cryptographic key used to verify the RRSIG signature.
  • DS (Delegation Signer): Connects a child zone to a parent zone by holding the hash of a child’s DNSKEY, creating a “chain of trust”.
  • NSEC/NSEC3 (Next Secure): Used to provide authenticated proof that a DNS record does not exist. [1, 2, 3]

Key Aspects of DNSSEC

  • Data Integrity: DNSSEC ensures the data received is exactly what the domain owner published, preventing unauthorized modifications.
  • Origin Authentication: It confirms the data originated from the authorized DNS zone.
  • No Confidentiality: DNSSEC does not encrypt DNS queries or responses; it only signs them to prove authenticity.
  • Chain of Trust: It validates records by chaining signatures from the root zone down to the specific domain. [1, 2, 3, 4, 5]

DNSSEC is implemented by signing zones, which creates these records to validate that traffic reaches the correct destination, protecting against threats similar to the 2011 “Operation Ghost Click”. [1, 2]

SA

Hi @user13403

Thank you for reporting the issue on Norton Community. The url is listed as False Positive now. Please check from your side.

Thanks!

1 Like