“Harmful downloads” means your site is handing visitors software Google considers dangerous.

“Harmful downloads” is a judgement about the software itself: Safe Browsing has classified a file your site serves, or a file on another site your pages link to, as malware or as unwanted software that misleads users or changes their system without consent. Browsers that use Safe Browsing may block the download or warn visitors before they reach the site.

“Uncommon downloads” is a judgement about reputation rather than proven harm. It means visitors are being offered downloadable software that Safe Browsing has not seen often enough to vouch for. If the files are genuinely yours — a desktop app, a plugin you sell, an installer — the issue is about distribution and signing, not about a compromise.

The sample URLs in the report tell you which one applies. A download link you recognise that is flagged as uncommon is a release question. An installer, an Android package or a script you have never seen, or a link to a file host you never used, is evidence of a compromise.

$ find wp-content/uploads -type f \( -iname '*.exe' -o -iname '*.msi' -o -iname '*.apk' -o -iname '*.zip' \) -ls
-rw-r--r-- 1 acct acct 4718592 Oct 14 03:12 wp-content/uploads/2026/10/Setup_Update.exe
-rw-r--r-- 1 acct acct 6291456 Oct 14 03:12 wp-content/uploads/2026/10/viewer.apk
-rw-r--r-- 1 acct acct  208311 Mar  2  2025 wp-content/uploads/2025/03/brochure-pdfs.zip
$ grep -c 'Setup_Update.exe' /path/to/access.log
1873
# the 2025 archive is yours; both installers were written at 03:12, and one was requested 1,873 times

1. 01

   Start from the sample URLs

   Search Console’s Security Issues report lists the issue and, where Google provides them, sample URLs. Note whether each sample is a file on your site or a page that links elsewhere.

2. 02

   List executables and archives in uploads

   Media folders should hold images, documents and video. Anything that installs or runs deserves an explanation:

   shell

   $ find wp-content/uploads -type f \( -iname '*.exe' -o -iname '*.msi' -o -iname '*.apk' -o -iname '*.dmg' -o -iname '*.scr' -o -iname '*.bat' -o -iname '*.vbs' -o -iname '*.js' -o -iname '*.zip' -o -iname '*.rar' -o -iname '*.7z' \) -ls 2>/dev/null

   Legitimate archives you uploaded will appear too. Compare dates: files written together, at an odd hour, in a folder for a month you did not publish in, are the ones to examine.

3. 03

   Find download links in the content

   Injected links live in posts, widgets and options. A read-only query lists posts that mention installer or package extensions:

   WP-CLI

   $ wp db query "SELECT ID, post_type, post_status, post_title FROM wp_posts WHERE post_content LIKE '%.exe%' OR post_content LIKE '%.msi%' OR post_content LIKE '%.apk%' OR post_content LIKE '%.dmg%' OR post_content LIKE '%.scr%'"

   Adjust the wp_ prefix to your own. Check widget and theme options the same way, and read the menus in Appearance → Menus.

4. 04

   See what visitors actually downloaded

   The access log shows which files were requested and how often, which tells you how far the exposure went:

   shell

   $ grep -E '\.(exe|msi|apk|dmg|scr|zip|rar)( |\?)' /path/to/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

5. 05

   Check for prompts that only some visitors see

   Fake update overlays and redirect chains are conditional. Open the site in a private window on a phone, arriving from a search result, and use URL Inspection’s live test to see what Google receives.

1. 01

   Preserve before deleting

   Copy the flagged files with their timestamps and hashes into a folder outside the web root, export the database, and keep the access logs. The download counts in the logs tell you who may have been affected.

2. 02

   Remove the files and every link to them

   Delete planted files, remove injected links from posts, widgets, menus and options, and replace any legitimate download that was swapped with a copy from your own trusted source.

3. 03

   Remove the mechanism

   Whatever wrote the files or injected the links is still there: an uploader backdoor, a rogue administrator, a compromised plugin, a startup directive or a scheduled task. Cleaning the output without it brings the files back.

4. 04

   Stop PHP and scripts running from uploads

   Uploads should never execute code. Blocking script execution in that folder at the web-server level closes a common route for planted tools.

5. 05

   Rotate credentials and verify

   Change control-panel, SFTP, database and WordPress credentials from a clean device; then check that every sample URL returns 404 or clean content to every kind of visitor.

6. 06

   Request the review

   From the Security Issues report, describe what was found (which files, which links), what was removed, and how the entry path was closed.

The access log shows how many times each malicious file was downloaded. If the number is more than zero, visitors may have installed it. Depending on who your visitors are — customers, staff, members — consider telling them what was served, when, and what to do, and take advice on any notification obligations.

Keep watching Search Console, the uploads folder and the logs for several weeks. A new executable appearing in uploads after the cleanup is not a coincidence; it means something that can write there survived.