The WordPress Pharma Hack: Drug Spam Google Sees and You Don’t

This post is part of our series on WordPress attacks in the last 10 years — one major attack per day, what it was, how to detect it, how to remove it and how to keep it out. This instalment covers The WordPress Pharma Hack (2016 — still active today).

What happened

The pharma hack is one of the oldest organised WordPress infections: attackers break in, then rewrite what Google’s crawler sees so your pages rank for pharmaceutical terms — viagra, cialis, online pharmacy — while you and your customers see your normal website. The spam often lives in encoded form in theme files or the database and targets your highest-ranking pages, because their authority is what makes the spam rank. It has never really gone away; it simply shares tooling now with the Japanese keyword hack and casino spam, which work the same way with different keywords.

Who was exposed: Any WordPress site with a vulnerable plugin, theme or weak login. Why it mattered: For over a decade, pharma spam has been among the most common SEO infections found in hacked-site cleanups — some years it has accounted for the majority of all malware detections on cleaned sites.

How this attack works

It starts with ordinary entry — an outdated plugin, a pirated theme, a reused password. Once in, the attacker plants a small cloaking script and an encoded payload. When a request arrives carrying Googlebot’s user-agent, the payload rewrites the page’s title, text and links into drug spam; when you visit, the same code serves your real content untouched, so spot-checking your own site finds nothing.

The engine of every cloaked spam attack is conditional serving: the code checks who is asking — Googlebot’s user-agent, a visitor arriving from a Google result, a particular country or device — and only then swaps in the spam. Everyone else, including you checking your own site, receives the genuine page. A second component manufactures discoverability: planted folders, a fake sitemap, or auto-generated URLs, so Google finds and indexes spam pages faster than you can delete them.

Signs your site has it — and how to confirm

• Your pages appear in Google with pharmaceutical titles or descriptions you never wrote
• Search Console shows impressions for drug keywords on a site that sells nothing medical
• site:yourdomain.com viagra returns results, but the pages look normal when you open them
• Encoded blobs (base64) sitting in theme files, widgets or wp_options

Fetch the suspect page as Googlebot and compare it with a normal fetch — if the HTML differs, cloaking is confirmed. Then run the database check for encoded payloads (large unfamiliar options containing base64_decode or eval) and look for planted folders named like your real pages at the server root.

Step-by-step removal and recovery

Immediate actions for this attack

• Confirm cloaking by fetching a page as Googlebot and comparing it with a normal fetch
• Find the payload in files AND database — pharma payloads regenerate if either copy survives
• Reinstall core, theme and plugins clean; rotate every password and salt key
• Clear Google’s index of the spam via Search Console removals and re-indexing of real pages

The full protocol

1. Back up the infected site (files and database) and label the backup infected.
2. Put the site in maintenance mode so Google stops re-crawling live spam while you work.
3. Delete planted spam folders, fake root files (a hand-made sitemap.xml, rss.xml, feed.xml or robots.txt your plugins did not generate) and any PHP files hiding in wp-content/uploads/.
4. Reinstall WordPress core, your theme and every plugin from clean official sources; delete anything nulled or unused.
5. Clean the database: unfamiliar encoded options, hidden spam containers in post content, rogue cron jobs, and any admin user you do not recognise.
6. Clean .htaccess back to the standard WordPress block and remove rewrite rules pointing at scripts you do not own.
7. Rotate every credential — hosting (with 2FA), wp-admin, database, FTP — and regenerate the salt keys in wp-config.php.
8. Verify like Google: fetch key pages as Googlebot, confirm spam URLs return a genuine 404, then work the Search Console cleanup (removals, fresh sitemap, re-indexing requests for your real pages).

How to prevent it

• Keep every plugin and theme updated — pharma crews scan for old versions at scale
• Never install nulled plugins or themes; they are a classic delivery vehicle for this family
• Run file-change monitoring so an edited theme file alerts you the day it happens
• Scan the database as well as files — file-only scans miss this infection’s home

The defences repeat across this whole series for a reason: kept-updated software, unique passwords with 2FA, the fewest possible plugins, backups stored off the server, and monitoring that looks at your site the way an attacker — or Google — does. Sites rarely fall to one exotic trick; they fall to one ordinary gap.

FAQs

Why can’t I see the spam on my own site?

Because it is cloaked. The code serves spam only to Googlebot (and sometimes to visitors arriving from Google) and serves you the clean page. Fetch your site with a Googlebot user-agent to see what Google sees.

Is the pharma hack dangerous to my visitors?

Usually its goal is rankings, not your visitors — but the same access that planted it can be sold or repurposed for redirects and skimmers, so treat any infection as full compromise.

Will deleting the spam pages fix it?

No. The pages are generated by a payload. Until the payload, its database copy and its persistence points are removed, the pages return — often within hours.

Next in the series and the full timeline: WordPress Attacks in the Last 10 Years — the complete guide.