DEV Community: Bug Circuit

Host Suspended Your Site for Malware? Do This

Bug Circuit — Fri, 31 Jul 2026 02:35:33 +0000

Originally published on the Bug Circuit blog.

If your host suspended your site for malware, the fastest way back online is: get the exact scan report from your host, remove the malicious files (not just disable the infected plugin), rotate every password and secret key, update everything, run a clean third-party scan, and send your host proof of all of it before you ask for reinstatement. Skipping the "proof" step is the single biggest reason sites get re-suspended within days.

This is for site owners staring at a "suspended due to malicious content" email from GoDaddy, Bluehost, SiteGround, Hostinger, WP Engine, or a similar host, with no idea what to do next. By the end you'll have a step-by-step process to identify the infection, clean it properly, and get your host to turn the site back on — plus what to do so it doesn't happen again.

What "suspended for malware" actually means

Hosts don't suspend sites to be difficult. Malware on your site can spam other customers' shared servers, get the host's whole IP range blocked by email providers, or trigger Google Safe Browsing warnings that make the host's network look untrustworthy. Suspension is the host protecting its own infrastructure — your reinstatement path exists, but you have to do the cleanup, and you usually have to prove it.

Common triggers: a hidden backdoor script uploaded through an outdated plugin, injected spam links or redirects, a cryptomining script, or your site being used to host a phishing page. All of these get caught the same way — by a scanner (the host's own, or Google's) flagging known malicious patterns.

Step 1: Get the exact reason from your host

Don't start deleting files yet. Open a support ticket and ask specifically for:

The scan report or list of flagged files and paths
The date/time the infection was detected
Whether they've already quarantined or restored anything
Their exact reinstatement requirements (some hosts want a signed statement, some want a specific scanner's clean report, some will rescan themselves)

Many hosts (GoDaddy, Bluehost/EIG-family brands, SiteGround) run automated malware scanners on shared hosting and will hand you a file list on request — this saves you hours of guessing.

Step 2: Check how bad it looks from the outside

Before touching code, check what the internet already knows:

Search site:yourdomain.com in Google — spammy titles or foreign-language pages you didn't write are a strong signal of injected content.
Check your domain's status at Google's Safe Browsing site status tool.
Log into Google Search Console and check the Security Issues report if the site is verified — it often names the exact malware type (e.g., "injected content," "harmful downloads").

If you're not sure whether the site is actually compromised or just misflagged, our free website security check can give you a quick read before you spend hours digging.

Step 3: Find and remove the malicious code

This is the part people rush and get wrong. Disabling the plugin the malware came in through does not remove a backdoor the attacker already planted elsewhere.

If you have a clean backup from before the infection date, restoring it is usually faster and safer than manual cleanup — as long as you also patch the entry point (Step 5) before putting it back online.

If you don't have a clean backup, look for:

Obfuscated PHP: eval(base64_decode(...)), gzinflate(...), str_rot13(...) inside theme or plugin files that shouldn't contain them
Files with recent modified dates you don't recognize, especially in /wp-content/uploads/ (uploads folders shouldn't contain .php files at all)
Extra admin accounts you didn't create (check Users in your CMS admin, or the database wp_users table directly)
Unfamiliar entries in .htaccess, especially RewriteCond/RewriteRule blocks that redirect mobile visitors or search-engine bots to a different site
Scheduled tasks (cron jobs) you didn't set up, in your hosting control panel or via a plugin like WP Crontrol

Compare core CMS files against a fresh download of the same version — any core file that differs from the official release is suspect. Google's own "Clean up your hacked site" guide walks through this file-by-file comparison process in more detail.

Step 4: Lock the doors — rotate every credential

Attackers who got in once often leave themselves a way back in. Before you reopen the site:

Change your hosting/cPanel password, database password, FTP/SFTP password, and every admin account password
Regenerate WordPress secret keys via api.wordpress.org/secret-key/1.1/salt/ and paste them into wp-config.php
Delete any admin user you don't recognize
Revoke and reissue API keys for any connected services (payment processors, email senders, CDNs)

Step 5: Update everything before you reopen

Outdated, unpatched software is how most of these infections start — it's consistently one of the top causes tracked in the OWASP Top 10 under vulnerable and outdated components. Update your CMS core, every theme, and every plugin to their latest versions, and remove anything inactive you're not using — an unused plugin can still be exploited even if it's switched off.

Step 6: Get a clean scan your host will accept

Most hosts won't take your word for it. Run one (ideally two) of these before you file for reinstatement:

Scanner	Good for	Notes
Sucuri SiteCheck (free)	Quick outside-in check	Scans the live site remotely, no login needed
Wordfence / MalCare (WordPress)	Full file-system scan	Checks every file against known-malware signatures
Host's own scanner	Reinstatement requirement	Some hosts only accept their own rescan as proof

Keep a screenshot or exported report of the clean result — you'll attach it to your reinstatement request.

Step 7: Ask for reinstatement — and prove it's clean

Reply to your original support ticket with:

What the infection was and where it was (referencing their scan report)
What you removed and what you patched (be specific: "deleted wp-content/uploads/2024/xx.php, updated Plugin X from 4.1 to 4.9")
Your clean scan report or screenshot
Confirmation that passwords and keys were rotated

After reinstatement, if Search Console showed a Security Issues warning, submit a review request there too — that's a separate step from your host unsuspending you, and it's what actually clears the browser warning for visitors.

DIY cleanup vs. professional help

	DIY	Host's paid cleanup	Manual audit ($49)
Speed	Hours to days, depends on skill	Usually 24–72 hrs	2–4 business days
Finds the root cause, not just the file	Sometimes — easy to miss backdoors	Varies by host	Yes, plus a written report of every issue found, with fixes
Ongoing protection	You're on your own	Ends after cleanup	Can pair with Signal for 3 months of cover + fixes to critical issues
Cost	Free (your time)	Often $100–$300+	$49 one-time

If you cleaned it yourself and just want a second set of eyes to confirm nothing was missed before you tell your host it's fixed, that's exactly the kind of check a manual audit is good for — it's not a substitute for the cleanup itself, but it catches what automated scanners and a rushed manual pass often miss. Compare that to a full penetration test cost if you're weighing options, and see how manual review differs from automated scanning if you're deciding which route fits.

How to stop this from happening again

Turn on automatic updates for your CMS core and plugins where your host supports it
Set up basic security headers — they won't stop every attack, but they close off easy wins like clickjacking and some injection vectors
Keep offsite backups on a schedule your host doesn't control, so a future infection doesn't wipe your only clean copy
Run a free security check periodically, and read how to tell if your site is hackable before the next scare

For background on the general categories of attacks hosts are scanning for, CISA's malware, phishing, and ransomware overview is a solid plain-English primer if you want to understand the bigger picture beyond your own incident.

Key takeaways

Get the host's exact scan report first — don't guess at what's infected
A clean backup restore plus patching the entry point beats manual file-by-file removal when you have one
Rotate every password and secret key, not just the CMS admin password
Run a clean third-party scan and attach the report to your reinstatement request — hosts rarely reinstate on your word alone
Fix the update/backup habits that let it happen, or expect a repeat

If you'd rather have a person confirm the infection is fully gone (and check for anything else an attacker could come back through) before you go back to your host, a Circuit audit is a $49 manual review with a written report — a second, human set of eyes on exactly this kind of situation.

Website Redirecting to Spam? How to Stop It

Bug Circuit — Fri, 31 Jul 2026 02:29:37 +0000

Originally published on the Bug Circuit blog.

If your website sends visitors to a spam, scam, or gambling site, you've almost certainly been hacked — and the redirect is hiding in one of four places: your .htaccess file, injected JavaScript, your WordPress database or a rogue plugin, or your DNS records. The fix depends entirely on which one it is, so guessing (or just reinstalling your theme) usually doesn't work.

This is for site owners — WordPress, Shopify, or a hand-built site — who've noticed weird redirects, gotten a "this site may be hacked" warning in Google, or had a customer say "your link took me somewhere sketchy." You'll get a step-by-step way to find exactly where the redirect is firing from, plus how to close it, including the sneaky version that only redirects mobile visitors or people coming from Google.

Why "website redirecting to another site" is almost always a hack, not a bug

A legitimate site doesn't randomly start sending people to pill ads, fake tech-support pages, or spam text in another language. When that happens, it's almost always malware planted after your site, a plugin, or your hosting account got compromised — commonly through a stolen FTP/hosting password, an outdated plugin with a known vulnerability, or a compromised admin account. Google's own guidance on hacked sites confirms this pattern and calls out redirect hacks specifically as a common attack type (Google Search Central: hacked sites overview).

The attacker's goal is usually SEO spam or ad fraud: they want your site's existing traffic and search ranking to funnel visitors to their pages, without you noticing for as long as possible. That's why these redirects are almost never "always on" — they're built to hide from you, the owner, while still firing for real visitors and search engines.

The 4 hiding spots, compared

Where it hides	How it usually triggers	Who notices it first
`.htaccess` (Apache config file)	Rewrite rules that check the visitor's User-Agent or Referer	Google Search Console, mobile users
Injected JavaScript	Obfuscated `<script>` in a theme file or footer that runs on page load	Desktop visitors, browser warnings
WordPress database / rogue plugin	Malicious `siteurl`/`home` value, or a fake plugin registering a redirect hook	Everyone, all the time (often the noisiest one)
DNS records	A/CNAME record repointed to attacker infrastructure	Everyone, but looks like the "whole site is down or moved"

Step 1: Rule out DNS first — it's the fastest check

Before you touch any files, confirm your domain is actually pointing at your own server. If your DNS was hijacked (usually via a compromised domain registrar or DNS provider account, not your website itself), no amount of file cleanup will fix it.

dig example.com A +short
dig example.com NS +short
whois example.com

Compare the A record IP against the IP your host gives you in your hosting control panel. If it doesn't match, or the nameservers (NS records) aren't the ones your registrar or DNS host assigned you, your DNS has been changed — go straight to your registrar, reset that account's password, and revert the records. This is a domain-account problem, not a website problem, so cleaning WordPress won't help.

Step 2: Check if the redirect is conditional (mobile-only or Google-only)

This is the step people miss. Many redirect hacks are deliberately conditional — they only fire for mobile users or for visitors arriving from a search engine, so the site owner checking it on a desktop browser sees nothing wrong. Test it the way an attacker built it to be tested:

# Simulate a normal visit
curl -I https://example.com

# Simulate Googlebot
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I https://example.com

# Simulate someone clicking through from a Google search on mobile
curl -e "https://www.google.com/search?q=example" -A "Mozilla/5.0 (Linux; Android 10; Mobile)" -I https://example.com

Look at the response headers. If the Googlebot or Google-referrer request returns a 301 or 302 with a Location: header pointing somewhere unfamiliar, but your plain request doesn't, you've confirmed a conditional redirect — and you now know it's checking User-Agent and/or Referer, which narrows the search to .htaccess or JavaScript (the next two steps).

Also check Google Search Console's Security Issues report (Search Console → Security & Manual Actions) — Google flags this exact "cloaked redirect" pattern when it crawls your site, per their hacked-site cleanup guide.

Step 3: Search .htaccess for User-Agent or Referer rules

Open .htaccess in your site's root directory (via FTP/SFTP or your host's file manager) and look for RewriteCond lines referencing HTTP_USER_AGENT or HTTP_REFERER, especially ones mentioning "google," "bing," "yahoo," or "mobile." A legitimate rule rarely needs to check for search engine names. A malicious block often looks like this:

RewriteCond %{HTTP_REFERER} google\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Mobile
RewriteRule ^(.*)$ http://spam-domain.example/landing.php [R=302,L]

Delete any block you don't recognize, save, and re-run the curl tests from Step 2 to confirm it's gone. Keep a backup copy of the file before editing, in case you need to compare it later.

Step 4: Search for injected JavaScript

If .htaccess is clean but the redirect still fires (especially only on desktop, or only after a delay), the payload is likely JavaScript stuffed into a theme file, a widget, or a compromised plugin's assets. Search your theme folder for obvious obfuscation:

grep -rl "eval(" wp-content/themes/
grep -rl "base64_decode\|gzinflate\|String.fromCharCode" wp-content/themes/ wp-content/plugins/

Real theme code almost never uses eval() combined with base64_decode — that combination is a near-universal signature of injected malware, because it lets the attacker hide the real payload from casual inspection. Also check footer.php and header.php for <script> tags you didn't add. OWASP's guidance on unvalidated redirects and forwards is a good primer on why these injections work so well (OWASP Top Ten): browsers and users trust redirects that appear to come from a site they already trust.

Step 5: Check the WordPress database and plugins

If you're on WordPress, the hack often lives in the database itself, not the files. Two places to check, using WP-CLI:

Site URL hijack — run wp option get siteurl and wp option get home. If either points to a domain that isn't yours, that's your redirect source.
A rogue or disguised plugin — run wp plugin list and look for anything you don't recognize, or a "legit-looking" plugin name you never installed. Also compare your core files against the official versions with wp core verify-checksums, a built-in WP-CLI command that flags any modified core file.

Malicious code also frequently gets planted directly in the wp_posts or wp_options table as a serialized PHP snippet that runs on init. This is harder to spot by eye than a file, which is one reason a manual, human-led review tends to catch what a quick automated scan misses.

Fix checklist, in order

[ ] Confirm DNS A/NS records match your actual host (Step 1)
[ ] Test with curl using Googlebot and mobile User-Agents to catch conditional redirects (Step 2)
[ ] Remove suspicious RewriteCond/RewriteRule blocks from .htaccess (Step 3)
[ ] Grep theme/plugin files for eval(, base64_decode, and obfuscated <script> blocks (Step 4)
[ ] Check wp option get siteurl/home and run wp core verify-checksums (Step 5)
[ ] Change all passwords — hosting, FTP, WordPress admin, registrar — since redirects usually mean broader access was gained, not just one file
[ ] Update every plugin, theme, and WordPress core to the latest version
[ ] Re-check Search Console's Security Issues report after cleanup and request a review

Run our free website security check after cleanup to confirm the redirect and any related malware are actually gone, not just hidden again.

When to stop DIY-ing it

If you've been through all four checks and the redirect keeps coming back, or you're not comfortable editing .htaccess and database values on a live production site, that's the point to bring in a second pair of eyes. Automated scanners are good at flagging known malware signatures but routinely miss custom, hand-placed redirects like the ones above — that gap is exactly why manual review exists; see our comparison of manual vs. automated penetration testing for why it matters here. It's also worth reading is my website hackable to understand what let the attacker in, so you're not just cleaning the symptom and leaving the door open.

Key takeaways

A spam redirect almost always means compromise, not a bug — and it hides in .htaccess, injected JavaScript, your WordPress database/plugins, or DNS.
Test with curl using a Googlebot User-Agent and a Google referrer before assuming your site is clean — many redirects are deliberately conditional and invisible on a normal desktop visit.
Rule out DNS first with dig — if the A or NS records are wrong, no file cleanup will fix it.
eval() combined with base64_decode in theme or plugin files is a near-certain sign of injected malware.
After cleaning up, change every password tied to the site (hosting, FTP, WordPress, registrar) — the redirect was a symptom of broader access, not an isolated glitch.

If you've gone through this checklist and still aren't fully sure it's clean — or you'd rather have someone find the exact injection point for you — Bug Circuit's Circuit audit is $49 for a human security engineer to manually trace it, document exactly what was changed and where, and hand you the precise fix. No card needed to start with the free check first.

Fix the 'Not Secure' Warning on Your Website

Bug Circuit — Fri, 31 Jul 2026 02:29:21 +0000

Originally published on the Bug Circuit blog.

The "Not Secure" warning means your site either has no SSL certificate, an expired one, or is loading some content over an insecure http:// connection — and you fix it by installing (or renewing) a certificate, forcing every page to load over https://, and cleaning up any leftover http:// links.

This is for any small business owner, blogger, or shop owner who opened their site and saw "Not Secure" next to the address bar — and now customers are asking about it (or worse, leaving). You don't need to be technical. Below is the exact sequence: diagnose, fix, verify, in about 20-40 minutes depending on your platform.

What "Not Secure" actually means

Every browser checks whether your site is using HTTPS — the encrypted version of the web address protocol. HTTPS relies on an SSL/TLS certificate, a small file that proves your domain is who it says it is and encrypts the connection between your visitor's browser and your server. Chrome explains its address-bar security indicators directly here: Chrome's "Not secure" warning explained.

You'll see the warning for one of three reasons:

No certificate at all — your site is still served over plain http://.
A broken certificate — expired, self-signed, or issued for the wrong domain (e.g., it covers example.com but not www.example.com).
Mixed content — the page itself loads over HTTPS, but it's pulling in an image, script, or stylesheet from an http:// address, so the browser can't call the whole page secure.

All three are fixable without touching code. Here's the order to work through them.

Step 1: Diagnose which one you have

Before fixing anything, find out exactly what's broken:

Click the padlock or "i" icon in your browser's address bar and choose Certificate is not valid or Connection is not secure to see the reason.
Run your domain through Qualys SSL Labs' free SSL Test — it grades your certificate and flags expired, mismatched, or misconfigured setups in plain terms.
If the padlock looks fine but you still see a warning or a "not fully secure" icon, open your browser's developer console (F12 → Console tab) and look for lines mentioning "Mixed Content" — that confirms issue #3 above.

Write down which case you're in; it determines which step below actually applies to you.

Step 2: Install or renew the SSL certificate

If you have no certificate or an expired one, get a new one. Most hosts now offer this for free:

Platform	How to get/renew the certificate
WordPress (shared hosting)	Host's control panel → SSL/TLS → "Enable free SSL" (usually powered by Let's Encrypt)
Shopify	Settings → Domains — SSL is automatic and free; if it's missing, remove and re-add the domain
Squarespace / Wix	Settings → Domains → SSL — toggle on; provisioning can take up to 24-48 hours
Cloudflare (in front of any site)	SSL/TLS tab → set mode to "Full" or "Full (strict)", not "Flexible"
Custom server / VPS	Install Certbot for free Let's Encrypt certificates, set to auto-renew every 90 days

Let's Encrypt certificates expire every 90 days by design, specifically so renewal gets automated rather than forgotten — that's the single most common cause of a site suddenly going "Not Secure" after working fine for months. Confirm your host has auto-renewal turned on, not a manual reminder on someone's calendar.

One more gotcha: make sure the certificate covers every version of your domain you actually use — example.com, www.example.com, and any subdomains. A certificate issued for only one of those will show "Not Secure" on the others.

Step 3: Force every visitor onto HTTPS

Having a certificate isn't enough if your site still lets people load the http:// version. You need a redirect that automatically bumps every visitor to https://.

WordPress: install the free plugin Really Simple SSL — it detects your certificate and forces the redirect with one click, no code.
Cloudflare: SSL/TLS → Edge Certificates → turn on "Always Use HTTPS."
Apache (.htaccess): add this to the top of your .htaccess file:

  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx: in your server block:

  server {
      listen 80;
      server_name example.com www.example.com;
      return 301 https://$host$request_uri;
  }

Once the redirect works, add one more header to tell browsers to always use HTTPS for your domain from now on, even if someone types http:// again later: Strict-Transport-Security: max-age=31536000; includeSubDomains. This is called HSTS, and OWASP's cheat sheet covers exactly how to set it safely: OWASP HSTS Cheat Sheet. You can check whether yours (and other security headers) are already in place with our free security headers checker.

Step 4: Clean up mixed content

If the padlock shows a warning icon even after Steps 2-3, some element on the page is still loading over plain http://. Browsers block or flag this because an attacker on the same network could tamper with that one insecure file and use it to attack the rest of the page — Mozilla's developer docs explain the mechanics here: MDN: Mixed content.

Common culprits and fixes:

Old image or script tags hardcoded as http://yoursite.com/logo.png — change them to https:// or, better, a protocol-relative //yoursite.com/logo.png.
Embedded content (YouTube videos, fonts, ad scripts, widgets) pulled from a third party still on http:// — check the embed code and swap to the provider's https:// version.
Database-stored links in WordPress posts/pages from before you had SSL — use the plugin Better Search Replace (or Really Simple SSL's built-in "Mixed Content Fixer") to bulk-update http://yoursite.com to https://yoursite.com across your database.

After fixing, reload the page and re-check the browser console — no more "Mixed Content" warnings means you're done.

Step 5: Verify the fix actually stuck

Check all of these before calling it fixed:

[ ] https://yourdomain.com loads with a padlock, no warning
[ ] http://yourdomain.com automatically redirects to https://
[ ] http://www.yourdomain.com and https://www.yourdomain.com also redirect correctly
[ ] Browser console shows zero mixed-content errors on your homepage and top 2-3 pages
[ ] SSL Labs test shows grade A or A+, not a warning
[ ] Certificate expiry date is at least a month out, and auto-renewal is confirmed on

If any box stays unchecked after these steps, the underlying cause is usually a caching layer (CDN or browser cache serving an old version) — clear your CDN cache and hard-refresh before troubleshooting further.

Key takeaways

"Not Secure" almost always means one of three things: no certificate, a broken/expired certificate, or mixed content — diagnose which one first.
Get a free certificate from Let's Encrypt (via your host or Certbot) and confirm auto-renewal is on, since 90-day expiry is the #1 cause of recurring warnings.
Force HTTPS with a 301 redirect (plugin, Cloudflare toggle, or a few lines in .htaccess/Nginx config), then add an HSTS header.
Hunt down and update any leftover http:// links in images, embeds, or your database — that's what causes mixed-content warnings even after the certificate is fixed.
Re-test with SSL Labs and your browser console before considering it closed.

If you've fixed the padlock but you're still wondering what else on your site might be exposed, that's worth a second look — our guide on what makes a website hackable covers the other common gaps. And if you'd rather have a person confirm everything is actually locked down (not just the padlock, but the whole site), Bug Circuit's Circuit audit is a one-time $49 manual review by a real security engineer, with a full report of anything else worth fixing. You can also start with a free passive security check — no card, no login — before deciding if you need more.

12 Signs Your Website Has Been Hacked

Bug Circuit — Fri, 31 Jul 2026 02:23:38 +0000

Originally published on the Bug Circuit blog.

If your site shows a browser warning, redirects visitors somewhere strange, has admin accounts you didn't create, or your emails are suddenly bouncing, treat it as hacked until you've checked and ruled it out. None of these signs alone is proof, but two or more together is a strong signal.

This is for any small business owner, freelancer, or agency running a WordPress site, Shopify store, or small SaaS app who's noticed something "off" and wants to know if it's a hack or a glitch. You'll get a plain-English checklist of the 12 most common symptoms, what each one actually means, how urgent it is, and the exact first steps to take.

Quick-scan checklist

Run down this table first. Anything in the Critical or High row means stop reading and act now — jump to "What to do right now" below.

Sign	What it usually means	Urgency
Browser or antivirus blocks your site	Malware or phishing content detected	Critical
Google flags you in Search Console	Confirmed malware, spam, or hacked content	Critical
Visitors get redirected to another site	Malicious redirect script injected	Critical
Homepage defaced or shows a ransom note	Active, confirmed compromise	Critical
New admin/user accounts you didn't create	Attacker has persistent access	Critical
Unknown PHP/script files in your file manager	A backdoor was uploaded	High
Site is suddenly slow or host suspends you	Server resources hijacked (e.g., crypto-mining)	High
Popups or ads only visitors see, not you	Cloaked malware showing different content to bots vs. humans	High
Emails from your domain bounce or land in spam	Domain blacklisted or used to send spam	Medium
Customers report fraud after buying from you	Payment page or card data possibly skimmed	Critical
Gibberish or spammy pages show up in Google	"SEO spam" injection targeting search rankings	Medium
Can't log in / login page looks different	Credentials changed or a fake login page installed	High

The 12 signs, explained

1. Your browser or antivirus blocks the site

If Chrome, Safari, or your antivirus shows a "Deceptive site ahead" or "This site may harm your computer" warning, Google or another security vendor has already detected malware or phishing on your pages. Check your status directly with Google's Safe Browsing site status tool — it's free and takes ten seconds.

2. Google Search Console shows a Security Issues warning

If you have Search Console set up, go to Security & Manual Actions > Security Issues. A message here ("hacked content," "harmful content," or "URL injection") is Google's own confirmation, not a guess. Google documents the common causes and cleanup steps in its hacked-sites help center.

3. Visitors get redirected to a random site

Someone lands on your homepage and ends up on a casino, pharmacy, or fake-prize site instead. This is almost always a malicious redirect injected into your theme files, .htaccess, or a compromised plugin. It often only fires for visitors coming from Google, so you may not notice it browsing directly — test in an incognito window from a search result, not by typing your URL.

4. Gibberish or spammy pages show up in your Google results

Search site:yourdomain.com in Google. If you see pages you never wrote — often in Japanese, Chinese, or stuffed with pharmacy/gambling keywords — that's "SEO spam injection." Attackers create thousands of hidden pages on your domain to piggyback on its search authority.

5. There's an admin account you didn't create

Check Users > All Users in WordPress, or run wp user list --role=administrator if you have WP-CLI access. An unfamiliar admin (sometimes with a generic name like "support" or "admin2") means an attacker created persistent access — even if you change your password, they can still log back in through that account.

6. Unfamiliar files appear in your file manager

Look in wp-content/uploads/, your theme folder, or your site root for .php files that don't belong there — uploads folders should never contain executable scripts. A quick way to spot recently added files via SSH: find . -type f -mtime -14 -name "*.php". These are frequently backdoors that let an attacker back in even after you "clean" the visible hack.

7. Your site is suddenly slow, or your host suspends it for "resource abuse"

A hosting email about excessive CPU use, or a site that crawls to a halt, can mean an attacker installed a script that mines cryptocurrency or sends spam email using your server's resources. Check your hosting control panel's resource-usage graph for an unexplained spike.

8. Emails from your domain bounce or land in spam

If customer emails suddenly bounce, or your own test emails land in spam, your domain may have been used to send spam and gotten blacklisted, or your SPF/DKIM/DMARC records were tampered with. Run a free check with our email spoofing and DNS checker to confirm your records are intact and your domain isn't blacklisted.

9. Popups, fake update prompts, or ads appear — but only for visitors

If customers report seeing "Your Flash Player is out of date" popups or unexpected ads, but you see nothing when you visit, that's likely cloaking: malicious code detects it's talking to a real visitor (not a search bot or the site owner) and serves different, malicious content. This is a classic technique to avoid detection while still infecting visitors — OWASP's guidance on detecting and responding to this kind of compromise is a solid technical reference if you want the deeper mechanics.

10. You can't log in, or the login page looks different

A changed login URL, a login form that looks slightly off, or a password reset that silently fails can mean an attacker replaced your login page with a fake one to harvest credentials, or locked you out after taking over the account.

11. Customers report fraud charges right after buying from you

This is one of the most serious signs on this list. If several customers report card fraud shortly after a purchase, your checkout page or payment integration may have been tampered with (a "web skimmer") to capture card details in real time. Treat this as a critical, drop-everything incident — it can trigger real financial harm to real people.

12. The homepage is defaced, or there's a ransom note

The most obvious sign: your homepage is replaced with a message, a flag, a group's logo, or a ransom demand. This confirms an active compromise with write access to your files. CISA's incident reporting guidance explains when and how to report an incident like this, particularly if customer data may be involved.

What to do right now

If two or more of the signs above match, work through this in order:

Take a backup of the current (compromised) state first — you'll want evidence, and a clean restore point may need comparison.
Change every password: hosting account, CMS admin, database, FTP/SFTP, and any team logins. Use unique, long passwords for each.
Check for accounts and files you didn't create (signs #4 and #5 above) and remove anything unfamiliar.
Ask your host for their malware scan/cleanup tool — most reputable hosts have one, and can also tell you if other sites on shared hosting were the entry point.
Verify your DNS and email records haven't been changed using our email spoofing checker.
Request a review in Google Search Console once you're confident the site is clean, so the browser warnings and search flags get lifted.
If money, customer data, or payment details were involved, document everything and consider your legal/regulatory notification obligations.

If you're not confident doing this yourself — and most non-technical owners aren't — that's exactly the gap a manual audit closes. For the full step-by-step process (not just the checklist), see our complete guide to what to do when your website's been hacked. If you just want a free first read before spending anything, our free website security check will tell you, no card required, whether something critical is actually going on.

Key takeaways

Two or more signs from the checklist above (especially anything marked Critical) means you should act now, not "when you get a chance."
A hacked site almost always has a hidden backdoor file or extra admin account — cleaning the visible symptom without finding that is why sites get re-hacked within days.
Bounced email and blacklisting are DNS-level symptoms; check your SPF/DKIM/DMARC records, don't just resend the email.
Google Search Console's Security Issues report is the most reliable free confirmation you can get in under a minute.
If fraud is involved, or you're not sure what you're looking at, a second pair of trained eyes beats guessing — a $49 manual audit finds and documents the actual cause instead of you chasing symptoms in the dark.

Bug Circuit's $49 Circuit audit has a real engineer manually go through your site, confirm which of these signs are real, find the backdoor or root cause, and hand you a plain-English report with exact fixes — see pricing if you want a professional to confirm and fix it rather than guess.

Answering a Security Questionnaire, No Security Team

Bug Circuit — Fri, 31 Jul 2026 02:23:36 +0000

Originally published on the Bug Circuit blog.

A client's procurement or legal team just sent you a spreadsheet with 40 questions about penetration tests, vulnerability management, and encryption standards, and you're a two-person shop with no security team. Here's the short version.

You don't need SOC 2 or an in-house security team to pass a vendor questionnaire — you need honest, specific answers backed by real evidence, and a recent third-party security assessment is the single most useful piece of evidence you can attach.

The rest of this guide walks through the questions you'll actually see, explains what each one is really trying to find out, and gives you wording you can copy and adapt without lying or stalling the deal.

Why they're asking at all

A vendor security questionnaire exists because your client's company is on the hook if you get breached and their customer data leaks through your systems. It's not personal, and it's rarely read as closely as it feels — most of the time it's a compliance checkbox for their legal or procurement team, and a junior analyst is scoring it against a rubric. Vague answers or silence look worse than an honest "we're small, here's what we actually do."

If you're wondering whether you even need a security audit to win the contract: usually no single audit is required, but having something concrete to point to turns a stalled email thread into a five-minute approval.

Decoding the common questions

"Do you conduct regular penetration testing?"

What they're really checking: has anyone other than your own developers tried to break into your app, and did you fix what they found?

Honest answer if you haven't: say so, then show what you have done. "We do not run a continuous penetration testing program. We had a manual security assessment performed on [date] covering [scope], and remediated the findings; the report is attached." A single recent manual audit report is far stronger evidence than a vague "yes" with nothing to show for it — reviewers can tell the difference immediately when they ask for the report and you can't produce one.

"Describe your vulnerability management process"

This is asking: when a new bug or CVE comes out, how do you find out, and how fast do you patch it? You don't need a formal SLA document to answer this honestly. A real small-team process might be: "We use [hosting platform]'s automatic security updates for the OS and dependencies, run npm audit / composer audit before each release, and subscribe to security advisories for our main frameworks. Critical issues are patched within days of disclosure." Write down what you actually do — most reviewers just want proof there's a process, not a specific tool stack.

"Do you have a SOC 2 report or ISO 27001 certification?"

SOC 2 is an audit of your internal controls over months, done by a licensed CPA firm, and it typically costs many thousands of dollars — it's built for companies with dozens of employees and dedicated compliance staff, not a five-person SaaS. If you don't have one, say so plainly and offer the closest honest substitute:

A recent manual security audit report of your actual product (not a generic company-wide audit)
Your cloud provider's own compliance attestations (AWS, GCP, and Azure all publish SOC 2 / ISO reports for their infrastructure — you inherit some of that coverage)
A written summary of your access controls, encryption, and backup practices

Saying "we're not SOC 2 certified, but here's our latest audit report and our cloud provider's compliance documentation" answers the underlying concern without pretending to have something you don't.

"How do you encrypt data in transit and at rest?"

This one you can usually answer with total confidence. In transit: "All traffic is served over HTTPS/TLS 1.2+; HTTP requests are redirected to HTTPS." You can verify and strengthen this by checking your site against our free security headers checker — it'll confirm whether Strict-Transport-Security is set (a good baseline value is max-age=31536000; includeSubDomains) and flag missing headers like Content-Security-Policy or X-Content-Type-Options: nosniff. At rest: most managed databases (RDS, Cloud SQL, MongoDB Atlas, Supabase) encrypt storage by default — check your provider's dashboard and state the actual mechanism, e.g. "AES-256 encryption at rest, managed by [provider]."

"Do you have an incident response plan?"

They want to know that if something goes wrong, you won't go silent for two weeks. It doesn't need to be a 20-page document. A short, real answer works: "If we detect a security incident, we isolate the affected system, assess scope, notify affected customers within 72 hours, and document the root cause and fix." If you've never had to think this through, write it down now, before you need it — it's the cheapest item on this list to fix.

"Who has access to production data, and how is access managed?"

List it honestly: how many people, whether you use unique logins and multi-factor authentication, whether you revoke access when someone leaves. "Two team members have production access, both via MFA-protected accounts; access is reviewed quarterly and revoked immediately on offboarding" is a complete, credible answer even for a tiny team.

"We ran a scanner once" is not the same as a real audit

A lot of small teams have, at some point, pointed an automated scanner at their site and gotten a clean report. That's worth mentioning, but be precise about what it proves: automated scanners check for known signatures — outdated software versions, missing headers, common misconfigurations. They can't chain together a business-logic flaw, test whether one customer can see another customer's data, or notice that a password-reset flow leaks account existence. If you want the actual mechanics of the difference, our guide to manual vs. automated penetration testing breaks it down. A questionnaire reviewer who's seen a few hundred of these can usually tell "we ran a free scanner" from "a person actually tested this," so don't oversell the scanner result — describe it accurately and pair it with something stronger if you can.

What to actually attach to the questionnaire

If you want one document that answers the penetration-test question, the vulnerability-management question, and half the encryption question at once, get a manual audit done and attach the report. It doesn't need to be an enterprise-grade, multi-week engagement to be credible — it needs to be recent, specific to your actual site, and written by a human who tested it, not a script.

Before you spend anything, you can get a free read on where you stand: run a free passive security check to see obvious exposures, or check your email setup with our email spoofing tool if the questionnaire also asks about phishing/domain protection (SPF/DKIM/DMARC records are a common follow-up question). If you want to understand pricing before committing, our breakdown of penetration test costs explains why enterprise pentests run into five figures and where a productized manual audit fits underneath that.

The bottom line

Don't lie, don't leave fields blank, and don't pretend a free scanner result is a penetration test. Answer every question with what's actually true about your setup, back the big claims with real evidence where you have it, and fix the gaps you can fix cheaply (headers, MFA, a written incident plan) before you submit. For the one question you probably can't answer honestly yet — proof of a real security test — a manual audit is the fastest, cheapest way to close that gap.

If you want that evidence in hand before your next questionnaire lands, Circuit is a $49 one-time manual audit: a real engineer tests your site and hands you a written report with severity ratings and exact fixes — something you can attach directly to a vendor questionnaire instead of leaving the field blank.

Why Is My Website Sending Spam Emails? (Fix It)

Bug Circuit — Thu, 30 Jul 2026 19:14:02 +0000

Originally published on the Bug Circuit blog.

Your website hasn't grown a mind of its own — a hacked file on your server is almost certainly the one blasting the spam, and you can usually find and remove it in an afternoon. This is one of the most common signs of a compromised site, and it follows a predictable pattern: an attacker gets a script onto your server, that script quietly uses your server's mail function to send spam in bulk, and eventually your host notices before your own visitors do.

Who this is for: owners who got a "spam complaints" or "abuse" notice from their host, found their domain on a blacklist, or just have a hunch something's wrong. What you'll get: how to confirm the spam is genuinely coming from your server (not just spoofed), where the malicious script usually hides, how to pull it out safely, and how to close the door it came through.

How does a website end up sending spam?

It's almost never "your website decided to email people." It's a small file — often just a few lines of PHP — that an attacker uploaded after finding a weak spot: an outdated plugin, a leaked FTP password, an unpatched CMS version, or a contact form that accepts file uploads without checking what's inside them. This class of bug is well documented by OWASP as unrestricted file upload — once a script can land anywhere inside your web root, it can call PHP's mail() function (or open a raw connection to an SMTP server) and start sending on your server's reputation and IP address.

The script usually isn't sending one email at a time by hand — it's looping through a list, often triggered by repeated visits to its own URL or by a scheduled cron job, which is why the volume can spike into the thousands overnight.

Step 1: Confirm it's really coming from you

Before you go file-hunting, check whether the mail is truly leaving your server, or whether someone is just putting your domain in the "From:" field without touching your site at all (that's email spoofing, a related but different problem you can check with our email spoofing checker).

Open a spam sample and view the full headers. In Gmail: the three-dot menu → "Show original." Look at the chain of Received: from lines — read them bottom to top. If one of the early lines shows your actual hosting IP or hostname (not just your domain name), the mail was generated on your server.
Check for a host abuse notice. Most hosts auto-flag or suspend accounts once outbound spam volume trips a threshold — look for subject lines like "Exim mail queue is very large" or "abuse complaint" in your hosting account inbox.
Check the live mail queue. SSH in and run mailq (Postfix servers) or use WHM/cPanel's Email → Mail Queue Manager if your host uses cPanel. A queue in the thousands, all going to unfamiliar addresses, confirms active sending.
Check the mail logs for the source. Look at /var/log/mail.log or /var/log/exim_mainlog (cPanel), or use cPanel's Email → Track Delivery. You're looking for one account or script generating an unusually high, repetitive volume compared to your normal traffic.
Check your web server's access logs for repeated POST requests to an unfamiliar .php file — especially one sitting inside /wp-content/uploads/ or another folder that should only ever hold images and documents.

Step 2: Find and remove the mailer script

Mailer scripts hide in a few predictable places:

Upload folders (wp-content/uploads/, /images/, /media/) — these should never contain executable PHP.
Theme files, especially functions.php, where a few extra lines blend in with legitimate code.
A "plugin" folder you don't remember installing.
A file with a name designed to look boring (class-cache.php, wp-tmp.php) sitting next to legitimate files.

A few read-only commands that help you narrow it down fast:

grep -rl "mail(" --include=*.php wp-content/uploads
grep -rlE "base64_decode|gzinflate|eval\(" --include=*.php public_html

Heavy use of base64_decode, gzinflate, and eval() chained together to hide what a script actually does is the classic signature of a web shell — malicious code an attacker uses to control your server remotely — as described in CISA's guidance on detecting and preventing web shell malware. None of those functions are automatically evil on their own, but finding them obfuscating a file you don't recognize is a strong signal.

Other ways to narrow the search:

Compare against clean copies. If you run WordPress, wp core verify-checksums (via WP-CLI) flags any core file that's been altered. Redownload fresh copies of your theme and plugins from their official source and diff them against what's on the server.
Sort by recent changes: find public_html -type f -name "*.php" -mtime -30 surfaces anything touched in the last month — a freshly modified file inside an otherwise untouched plugin folder stands out.
Check for scheduled tasks: crontab -l on the server, and any "cron" entries inside your CMS's own scheduler — some mailers fire on a timer instead of a web request.
Check for accounts you didn't create: an extra WordPress admin user, or an extra FTP/cPanel user, often accompanies the script as a backup way back in.

Once you find it, move the file out of the web root (rather than deleting it immediately) so you can review it later if needed, then keep searching — attackers who get in once frequently leave more than one way back in.

Step 3: Close the door it came through

Removing the script fixes the symptom. These steps fix the cause:

Update everything — CMS core, every theme, every plugin. Outdated software with a known, unpatched vulnerability is the single most common entry point.
Reset every password: hosting/cPanel, CMS admin, database, FTP/SFTP. Assume whichever one was weakest is how they got in.
Delete plugins and themes you don't actively use. Fewer installed files means fewer places to hide.
Block PHP execution inside upload folders. On Apache 2.4, add this to a .htaccess file inside the uploads directory:

<FilesMatch "\.php$">
Require all denied
</FilesMatch>

Turn on your host's malware scanner or file-integrity monitor if one is offered — it'll catch a repeat attempt faster than you can manually.

Step 4: Get off the blacklists

Once the script is gone and the hole is patched:

Check your server IP and domain at Spamhaus's lookup tool to see if either is listed.
Use each blacklist's own removal request form — don't request delisting until you've actually confirmed the mailer is gone, or you'll get relisted within hours.
Set up SPF, DKIM, and DMARC DNS records for your domain. These won't stop a script that's genuinely sending through your real mail path, but they help mailbox providers trust your legitimate mail going forward and stop the closely related problem of someone spoofing your domain from outside — see Google's bulk sender guidelines for the exact values major providers now expect.

Where to look for evidence

Evidence source	What it tells you	Where to find it
Email headers ("Show original")	Whether mail truly left your server or was spoofed	Any spam sample sent claiming to be from you
Host abuse notice	Your host has already detected outbound spam volume	Hosting account inbox / support tickets
Mail queue size	Whether spam is actively queued right now	`mailq`, or WHM/cPanel Mail Queue Manager
Mail logs	Which account or script is sending, and how often	`/var/log/mail.log`, `/var/log/exim_mainlog`, cPanel Track Delivery
Web access logs	Which URL triggers the script	Raw access logs / cPanel Metrics
Blacklist status	Whether your reputation is already damaged	spamhaus.org/lookup

If digging through server logs isn't something you want to do yourself, our free website security check can tell you, at no cost, whether your site is showing the obvious red flags of a compromise — and our guide on whether your site is hackable in the first place covers the entry points worth locking down before this happens again.

Key takeaways

Spam "from your website" is almost always a hidden script on your server, not spoofing — confirm it by reading the actual email headers.
Check your mail queue and server logs to find which account or file is generating the volume before you start deleting things.
Mailer scripts hide in upload folders, theme files, and disguised "plugin" directories — obfuscated code (base64_decode, eval) is a strong tell.
Removing the file isn't the whole fix — update everything, reset every password, and block PHP execution in upload folders so it can't come back.
Request blacklist delisting only after you've confirmed the script is actually gone.

If you've done the above and still aren't sure the site is clean — or you'd rather have a person confirm it instead of guessing — a real security engineer manually reviewing your site is the honest next step. That's exactly what Bug Circuit's $49 Circuit audit does: a full manual review with a written report of anything found, including exactly where the entry point was and how to close it.

FAQ

Why is my website sending spam emails?

In almost every case, an attacker uploaded a small script to your server — through an outdated plugin, a weak password, or an unrestricted upload form — and that script is using your server's mail function to send spam in bulk, usually without touching your site's visible pages at all.

Is my website hacked if it's sending spam?

Yes. A site can't send outbound spam on its own; it requires a malicious file or account that shouldn't be there. Treat it as an active compromise and remediate it the same way you would any other hack.

How do I know if my website is sending spam?

Check the full email headers of a spam sample claiming to be from you, look for an abuse notice from your host, and check your server's mail queue and logs for an unusually high volume of outbound mail — all of these will confirm whether the mail truly originated on your server.

Will my host suspend my site for sending spam?

Most hosts will suspend or throttle an account once outbound spam trips their abuse threshold, since it damages their shared IP reputation for other customers too. Removing the malicious script and responding to their abuse ticket promptly is usually enough to get reinstated.

Can my website send spam without me knowing?

Yes — that's the normal case. The script typically runs silently in the background or on a timer, so the first sign is often a host notice, a blacklist listing, or a customer telling you they got a strange email "from" your domain.