How to Identify and Remove Fake Google AdSense Malware from Your WordPress Site

If your WordPress site is suddenly showing Google AdSense ads, banner ads, or popup ads that you never added — and especially if visitors are also reporting strange mobile redirects you can’t reproduce yourself — your site has been hacked. An attacker has injected their own AdSense publisher ID into your pages so your traffic generates ad revenue for them, not you. The injected code is usually stored as entries in your WordPress database (often hidden inside a Header/Footer code manager plugin), which is why it survives plugin deactivation, theme switches, and surface-level malware scans. Removing it requires cleaning the database entries, finding the persistence mechanism that’s putting them back, and closing the original entry point.

There’s a particular moment site owners describe to me when they reach out. They’re browsing their own website, often from a phone, often a few days after the infection started, and they suddenly see a Google ad load on a page that has nothing to do with advertising. Sometimes a popup. Sometimes a banner that wasn’t there yesterday. Sometimes a mobile-only redirect that sends them to a completely unrelated site.

The first reaction is always confusion. “Did a plugin do this? Did my developer add tracking? Is this from my hosting provider?” The second reaction, once they check, is realizing they never set up AdSense on this site at all.

If that’s where you are right now, this guide walks through exactly what’s happening, why the ads are showing up, why deleting the obvious-looking plugin usually doesn’t fix it, and what a real cleanup actually looks like — including a real client cleanup I worked on where this exact malware family was injected through a legitimate-looking code-injection plugin and required full database remediation to remove.

What Site Owners First Notice

The symptoms cluster in a recognizable pattern. If three or more of these match what you’re seeing, you almost certainly have an AdSense injection:

• Google ads appearing on pages where you never installed AdSense
• Popup advertisements opening when visitors load or click anywhere on your site
• Banner ads in the header, footer, or sidebar that you didn’t place there
• Mobile-only redirects — desktop visitors see a normal site, mobile visitors get sent to spam or app-install pages
• Visitors reporting strange behavior that you can’t reproduce on your own machine
• Sudden drops in time-on-page or conversion rates with no other changes that would explain it
• Increased server resource usage from the extra ad scripts loading on every page
• An “AdSense” or similar plugin in your dashboard that you don’t remember installing

The combination most clients describe is “ads on my site + people complaining about popups + nothing in my plugins that obviously explains it.” That’s the fingerprint.

What’s Actually Happening

Someone has gained write access to your WordPress site — usually through a vulnerable plugin, a stolen admin password, or a nulled theme — and injected their own Google AdSense code into your pages. Their AdSense account, not yours.

Every time a visitor loads your site, the injected ad scripts run and serve ads. Every click on those ads sends ad revenue to the attacker. Your site becomes a passive income source for someone you’ve never met, while you absorb all the costs: damaged user experience, slower page loads, lost trust, and (if Google notices) potential search visibility issues.

The injected code typically looks like this in your page source:

<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1644527XXXXXXXX"
     crossorigin="anonymous"></script>
<script async custom-element="amp-auto-ads"
        src="https://cdn.ampproject.org/v0/amp-auto-ads-0.1.js">
</script>

The critical detail: that ca-pub-XXXXXXXX publisher ID is the attacker’s, not yours. If you don’t have a Google AdSense account, that ID has no business being on your site at all. If you do have AdSense but didn’t put the code there, compare the publisher ID — if it doesn’t match yours, you’re looking at the attacker’s account.

This is a malware family that security scanners flag under signatures like rogueads2unwanted_adsense and similar variants. But many infected sites pass scanner checks anyway, because of where the malicious code actually lives.

A Real Client Cleanup: Where This Malware Actually Lives

To make this concrete, here’s how a recent cleanup of this exact malware family unfolded. The client reached out after their WordPress site started showing AdSense ads, popup advertisements, and mobile redirects to suspicious third-party pages. They had never set up AdSense.

When I reviewed the site, the visible scripts looked like the code block above. But the source of those scripts wasn’t where most site owners would think to look.

The malware wasn’t in the plugin files

The infection was tied to the site’s Header Footer Code Manager setup — a legitimate, popular WordPress plugin used to inject custom HTML or JavaScript into page headers and footers. The plugin itself wasn’t malicious. It was being abused as the delivery vehicle.

The attacker had stored their AdSense scripts as snippet entries inside the plugin’s database tables. When WordPress rendered any page, the plugin dutifully read those snippets from the database and injected them into the HTML output, exactly as it was designed to do for legitimate use cases.

Why the obvious cleanup attempts failed

The client (and a previous helper) had already tried the obvious fixes:

• Deactivating the plugin → ads briefly disappeared, but the malicious snippets remained in the database, and reactivating the plugin (or installing a similar one) brought them right back
• Deleting suspicious-looking files in the file system → didn’t help, because the payload wasn’t in a file
• Running a security scanner → flagged the JavaScript family but didn’t remove it, because removal required database-level access the scanner didn’t have
• Manually editing the affected pages → the snippets were rendered dynamically, so editing individual pages did nothing

This is a textbook example of why WordPress malware keeps coming back — the visible symptom and the actual location are in different places.

What actually worked

The successful cleanup required:

1. Identifying the exact database entries (in wp_options and the plugin’s own tables) that contained the injected ad code
2. Removing those entries directly through phpMyAdmin
3. Auditing the rest of the database for related malicious entries that could re-inject the code
4. Reviewing the file system for any backdoor PHP file that could be writing to the database when triggered
5. Verifying core WordPress integrity and checking for additional compromise points
6. Closing the original entry point — outdated software in this case — so the attacker couldn’t simply walk back in

After cleanup, the popups stopped, the mobile redirects ended, and the unauthorized AdSense scripts disappeared from the rendered HTML. But the lesson worth taking from this case isn’t the cleanup steps. It’s the location.

Database injections are the single biggest reason DIY cleanups of fake AdSense malware fail. If you only check files, you’ll never find this.

Why Deactivating Plugins Doesn’t Fix It

This is the part that traps most site owners. They search through their plugin list, find something that looks ad-related (or sometimes a Header/Footer Code Manager plugin they don’t fully recognize), deactivate it — and the ads don’t go away. Or they go away briefly and come back hours later.

Here’s what’s actually happening:

The injected ad code isn’t sitting in a plugin file you can delete. It’s stored as rows in your WordPress database, usually in one of these places:

• The wp_options table — particularly entries created by code-injection plugins like Header Footer Code Manager, Insert Headers and Footers, or similar tools that legitimately store custom HTML/JS in the database
• The wp_postmeta table — sometimes attached to specific posts to make detection harder
• Custom database tables added by suspicious plugins the attacker installed for this purpose

The pattern I see most often is the attacker abusing an already-installed Header/Footer code injection plugin. The plugin itself is legitimate. But because it’s designed to inject arbitrary code into every page header or footer, it’s the perfect vehicle: an attacker who gets database access drops their AdSense scripts into the plugin’s stored snippets, and now every page on your site loads the malicious code.

When you deactivate the plugin, the database rows stay. When you reactivate it (or install a similar plugin), the injection comes right back. When you delete the plugin entirely, sometimes the database rows still don’t get cleaned up — and if there’s a backdoor elsewhere on the site, the attacker simply reinstalls a new injection vector.

This is why so many DIY cleanups fail on this specific malware family. The visible symptom (ads) and the actual location (database) are in different places.

How to Confirm What You’re Seeing Is Malware

Before assuming it’s a hack, rule out the legitimate alternatives:

1. Check the publisher ID

Open your site, view the page source (right-click → View Page Source), and search for ca-pub-. If you see one or more publisher IDs and you have a Google AdSense account, log into AdSense and compare. If they don’t match, the ad code isn’t yours.

If you’ve never had an AdSense account at all and there’s any ca-pub- code on your site, it’s malware. There is no legitimate reason for AdSense scripts to be on a site whose owner doesn’t have an AdSense account.

2. Check for unfamiliar plugins

Go to Plugins → Installed Plugins and look for anything you don’t recognize, especially:

• Plugins with vague names like “WP Stats,” “WP Helper,” “Site Helper”
• Header Footer Code Manager or Insert Headers and Footers plugins you don’t remember installing
• Plugins with no recent updates and no description
• Plugins where the author’s WordPress.org page no longer exists or doesn’t match

If you find any, screenshot them but don’t delete yet — you’ll want the evidence trail for the full cleanup.

3. Check for unfamiliar admin users

Go to Users → All Users and filter by Administrator role. Any admin account you don’t personally recognize is a strong indicator of compromise. The walkthrough in how to find and remove hidden admin users in WordPress covers what to look for and how attackers hide them.

4. Test from incognito mode and a mobile device

Some injection patterns only fire under specific conditions — first-time visitors, mobile user agents, visitors arriving from search engines. Open your site in an incognito window. Open it on your phone. If the popups or redirects only show in those contexts, you’ve confirmed it’s a conditional injection (which is a malware fingerprint, not a legitimate ad setup).

The Real Cleanup (What Actually Works)

Once you’ve confirmed it’s a hack, the cleanup has to address all three layers: the visible ad code, the persistence mechanism that’s reinjecting it, and the original entry point that let the attacker in.

Step 1: Snapshot before changing anything

Take a full backup (files + database) before you touch anything. You’ll want it for two reasons: a working safety net if cleanup goes wrong, and forensic evidence if you need to trace patterns. Save the malicious database rows (with their values) to a separate text file before deletion.

Step 2: Remove the injected code from the database

The fastest way is through phpMyAdmin or your hosting provider’s equivalent database tool. Search for fragments of the injected code — particularly the unfamiliar ca-pub- ID, googlesyndication, or adsbygoogle — across the wp_options and wp_postmeta tables.

For each row that contains the injected ad code, you have two options:

• If the row is purely malicious (a snippet entry that only contains the rogue ads), delete the row entirely
• If the row mixes legitimate content with injected code (rare, but happens), edit the row and remove only the malicious portion

For a deeper walkthrough of database malware cleanup, see how to scan and clean your WordPress database for hidden malware.

Step 3: Audit code-injection plugins

If you find Header Footer Code Manager, Insert Headers and Footers, or any similar plugin installed and you don’t actively use it, remove it entirely. If you do use one of these legitimately, open it and review every snippet — anything you didn’t personally add should be deleted from inside the plugin’s interface, not just from the database (otherwise the plugin may regenerate the row).

Step 4: Find and remove the persistence mechanism

The injection had to come from somewhere. Common persistence patterns I find on these cleanups:

• Hidden admin users who recreate the database entries
• Scheduled WordPress cron tasks that re-inject the code on a timer
• Backdoor PHP files in wp-content/uploads/, fake plugin folders, or theme files that write to the database when triggered
• Modified core or theme files with code that calls a remote server and updates the database based on its response

If you skip this step, the ads will be back within hours. Why WordPress malware keeps coming back covers the persistence problem in depth.

Step 5: Reinstall WordPress core, plugins, and themes from clean sources

Don’t trust visual inspection. Download fresh copies from WordPress.org and the original plugin/theme developers, and overwrite all the files. Throw away anything nulled or pirated — these often ship with backdoors built in (why nulled WordPress plugins and themes are a security disaster).

Step 6: Rotate every credential

WordPress admin, hosting cPanel, FTP/SFTP, the database user, and any email accounts that received password resets during the compromise. Also rotate WordPress security keys (the salts in wp-config.php) to invalidate any active session the attacker still has.

Step 7: Verify the cleanup

Reload your site in incognito mode, on a mobile device, and from a different network. View the page source and search for ca-pub-, googlesyndication, and adsbygoogle. None of those should appear anywhere unless you have a legitimate AdSense setup of your own.

For a complete post-cleanup checklist, see what to do after fixing a hacked WordPress site.

Why This Infection Is More Damaging Than It Looks

A lot of site owners initially treat this as a cosmetic annoyance — “I’ll get to it next week.” The hidden costs add up faster than people expect:

• Lost revenue. Every visitor on your site is generating ad income for the attacker instead of converting on whatever your site is actually for.
• Brand damage. Visitors associate your domain with intrusive popups and shady redirects. Even after cleanup, that perception sticks.
• SEO risk. Mobile redirects and intrusive interstitials can trigger Google’s “intrusive interstitial” penalties. Suspicious script behavior can also lead to Safe Browsing flags or “this site may be hacked” warnings in search results.
• Hosting risk. Some hosts will suspend accounts that serve malicious-looking ad behavior, especially if other customers complain.
• Cross-customer reputation damage. If you sell services or products, the popups visitors encounter create a negative first impression that’s hard to recover from.
• Conditional payloads can escalate. The same injection mechanism delivering AdSense today can deliver credential phishing, fake browser updates, or a redirect to a scam site tomorrow. The attacker controls what runs.

The “just ads” framing badly understates the actual risk. This is the same script-injection mechanism behind credit card skimmers I’ve cleaned on WooCommerce sites — see finding a credit card stealer that no security tool could detect and WooCommerce fake payment form skimmer fix. Same technique, different payload.

How Attackers Get In (So You Can Close the Door)

Knowing how the attacker got admin or database access in the first place is what determines whether the cleanup actually holds. The most common entry points I trace back to on these cleanups:

• Outdated plugins with known exploits. A plugin that hasn’t been updated in months almost always has a public CVE attached to it.
• Nulled or pirated themes/plugins. “Free” premium plugins from unofficial sources frequently ship with backdoors pre-installed — exactly the kind that allow database injection without leaving an obvious entry point.
• Weak or reused admin passwords. Credential stuffing attacks try huge lists of leaked passwords against WordPress logins.
• Compromised hosting accounts. If another site on your shared hosting account is hacked, attackers can sometimes pivot to yours.
• Outdated WordPress core. Less common as an entry point in 2026, but still happens on neglected sites.
• Missing two-factor authentication. Without 2FA, a single leaked admin password is the whole game.

For broader hardening, see how to secure a WordPress site and the more login-focused how to secure your WordPress login.

How to Prevent This From Happening Again

Once you’ve cleaned the site, the goal shifts from removal to prevention. The measures that actually move the needle, in order of impact:

• Update WordPress core, plugins, and themes promptly. Most fake AdSense injections trace back to a known plugin vulnerability that had a patch available.
• Remove plugins you don’t actively use. Inactive plugins still ship code that can be exploited.
• Audit your code-injection plugins. If you have Header Footer Code Manager, Insert Headers and Footers, or similar tools installed and you’re not actively using them, uninstall them.
• Use strong, unique passwords with two-factor authentication. Both on WordPress and on your hosting cPanel.
• Enable file integrity monitoring. Most security plugins can alert you when database options change unexpectedly or when new files appear in places they shouldn’t.
• Install a real Web Application Firewall (WAF). Wordfence, Sucuri, Cloudflare WAF, or your host’s built-in firewall — they all reduce the attack surface.
• Keep off-host backups. Backups stored on the same server as the site can be infected along with everything else.
• Monitor your site’s outbound script references. A periodic check of your page source for unfamiliar script tags is a quick early-warning system.

FAQ

I don’t have an AdSense account but my site is showing AdSense ads. What does that mean?

It means your site is hacked. There is no legitimate way for AdSense scripts to appear on a site whose owner has never set up an AdSense account. The ads are running on the attacker’s account, and every impression and click sends revenue to them.

How do I find the attacker’s publisher ID on my site?

Open your site in a browser, right-click and choose “View Page Source,” then search the source for ca-pub-. Any publisher ID that appears (especially one you don’t recognize) is the attacker’s.

I deactivated the plugin that was injecting the ads but they came back. Why?

Because the injected code is stored in your database, not just in the plugin files. Deactivating the plugin temporarily stops the injection from rendering, but the malicious database entries remain. When you (or the attacker) reactivate the plugin or install a similar one, the entries are read again and the ads return. The fix requires removing the database rows directly.

Why didn’t my security plugin detect this?

Many security plugins are tuned to scan files for known PHP backdoor patterns. AdSense JavaScript stored as a string in the WordPress database doesn’t match those patterns — it’s syntactically valid HTML/JS that legitimate plugins routinely store in the same place. Database-side malware needs a scanner that specifically scans the database, and even those miss the more sophisticated variants.

Should I just delete every code-injection plugin to be safe?

If you’re not actively using one, yes. If you do use one (some sites legitimately need them for analytics scripts, custom HTML, or third-party integrations), keep it but audit the snippets inside the plugin’s interface and remove anything you didn’t personally add.

The ads are on my site, but my AdSense account is in good standing. Could Google ban my AdSense for this?

Possibly. If the rogue ads are running under a different publisher ID, your account isn’t directly affected. If — somehow — your own publisher ID has been hijacked and used in the injection, that’s a separate problem and you should report it to Google AdSense immediately. Either way, if Google’s crawler picks up suspicious script behavior on your domain, it can affect your search visibility regardless of which AdSense account is involved.

How long will it take Google to stop showing search warnings about my site after cleanup?

If your site picked up a “This site may be hacked” or Safe Browsing warning, you can request review through Google Search Console after cleanup. Reviews typically take 24–72 hours. Until cleanup is verified, the warnings stay. If you’re in this situation, my Google blacklist removal service covers the review process.

Could the same injection mechanism be used to deliver something worse than ads?

Yes — and this is the underrated risk. The same plugin/database mechanism that’s currently delivering AdSense scripts can be repurposed at any time to deliver credential-stealing forms, fake browser update prompts, redirects to phishing sites, or e-commerce skimmers. Whatever the attacker chooses to put in the snippet runs on every page load. Treat the AdSense version as a warning shot, not the worst-case scenario.

Need Help Removing Fake AdSense Malware From Your WordPress Site?

If your site is showing unauthorized ads, popups, or mobile redirects, and the obvious fixes haven’t worked, the issue is almost certainly in your database — and the cleanup needs to go further than file scans alone.

I’ve cleaned more than 4,500 hacked WordPress websites since 2018, including dozens of fake AdSense and rogue ad injections like the one described in this post. If you’re not confident handling database-level cleanup yourself, or if you’ve already tried cleaning and the ads keep coming back, this is exactly the kind of case I work on every week.

Get Expert WordPress Malware Removal — or contact me directly via the hire me page.