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
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.
@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]
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.
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]
PclZip Path Traversal: A critical vulnerability.
Authorization Bypass: Found in the new “Notes” feature (introduced in 6.9).
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]
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.
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”.
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.
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.
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]
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]