Google Ads IP exclusions can be bypassed. We did it.

What Google Ads advertisers should know about IP addresses used in fraud strategies

Google Ads IP exclusions can be bypassed. We did it.

TL;DR — We reproduced end-to-end, on our own Fáktica Google Ads account in March 2026, a technique that lets an attacker keep generating charged clicks from an IP the advertiser has already added to Google Ads’ exclusion list. On top of that, we are already documenting two fingerprints consistent with this technique on client accounts: clicks from excluded IPs that Google keeps charging, and the same GCLID reused across multiple IPs and machines. Until Google addresses it server-side, IP exclusions and every third-party tool built on top of them offer weaker protection than advertisers assume.

The technique

IP exclusion lists are one of the few native tools advertisers have to block known fraudulent sources. Even in the best case they are a weak defence — we’ve written elsewhere about how dynamic IPs and CG-NAT already erode their effectiveness, and why we only recommend them as a last resort. What we are documenting here is different: a technique that doesn’t just erode IP exclusions, it bypasses them entirely. We call it IP Exclusion Bypass via Link Harvesting.

The attack uses two IPs with distinct roles:

An exposed IP — visible to the advertiser, on the exclusion list, the one doing the dirty work.
A hidden IP — invisible to the advertiser, clean, the one that makes the attack possible.

The setup is the usual fraud pattern: the attacker generates clicks from an IP, the advertiser detects them and adds the IP to the exclusion list. That IP is now the exposed IP. Nothing new so far. The novel part — the bypass itself — is what happens next:

With the exposed IP already on the exclusion list, the attacker introduces the hidden IP, used exclusively to harvest the ad URL — i.e., to retrieve the destination link and its tracking parameters (including the GCLID). The hidden IP never clicks; it only captures.
The hidden IP passes the captured URL and GCLID to the exposed IP.
The actual click request is sent from the exposed IP — the blocked one. Despite being on the exclusion list, Google charges the click.
Because the hidden IP never clicks, it never appears in the advertiser’s traffic data. It cannot be detected and cannot be blocked. It can keep harvesting indefinitely.

The net result: the exclusion list becomes ineffective. The exposed IP keeps producing charged clicks; the hidden IP stays permanently invisible to the advertiser.

How we verified it

In March 2026 we reproduced the full attack in a controlled proof-of-concept (PoC) on our own Fáktica Google Ads account, simulating an attacker against our own campaigns. We successfully generated charged clicks from an IP that was on our exclusion list, exactly as described above. The experiment is internally documented and fully reproducible.

Why this matters beyond a lab test

This is not a theoretical curiosity. In ongoing forensic work on client accounts, we are observing behaviour fully consistent with this technique being actively exploited — in two different ways.

The first is the smoking gun: clicks from excluded IPs that Google keeps charging. We have documented cases of single IPs that accumulated thousands of clicks over almost two years, with tens of clicks per day, fitting every textbook pattern of automated fraud. Also coordinated botnets of IPs cycling through the same set of user-agents, day after day. When advertisers add those IPs to their exclusion lists, what happens is not that the clicks stop — what happens is that Google invalidates some of the subsequent clicks from those IPs, but charges for others. An excluded IP that keeps producing charged clicks is, by definition, bypassing the exclusion mechanism.

The second is GCLID replay patterns — single ad URLs (each with a unique GCLID) appearing in request logs from multiple distinct IPs, often in different countries, within short windows. That is precisely the fingerprint the harvest-and-replay technique produces: one capture, multiple executions. It is also one of the plausible explanations for the same GCLID being charged twice, a pattern we have covered separately.

We cannot confirm from the advertiser side that the specific mechanism is always the one described here — we do not have access to Google’s server logs. But the fingerprint is there, it is consistent, and it is not rare.

The implication is structural:

Google Ads’ native IP exclusion becomes unreliable as a blocking mechanism for any attacker willing to separate harvesting from clicking.
Third-party anti-fraud tools that rely on IP blocking inherit the same limitation. Whatever they block at the IP layer can be bypassed with the same two-IP split.

What Google can do

Google is in a unique position to close this. When a user clicks a Google Ads ad, the ad URL is not the final destination — it is a Google redirect that acts as a bridge to the advertiser’s landing page. The advertiser has no visibility into the hidden IP, but Google does: Google sees the IP that fetched the ad URL and the IP that ultimately executed the click, and both requests share the same click ID (GCLID).

Correlating those two IPs is a server-side operation. Google could flag or invalidate any click whose GCLID was harvested from a different IP than the one executing it, or — at a minimum — treat clicks coming from IPs on the advertiser’s own exclusion list as invalid regardless of which IP originally fetched the URL. Neither is technically hard. Neither requires any new signal that Google does not already collect.

We have reported this to Google on several occasions, on behalf of clients suffering substantial six- and seven-figure losses from attacks that show this exact fingerprint. To date, nothing we can observe from the advertiser side has changed, and the technique continues to work.

This is not the first time this kind of issue has been publicly raised. More than a decade ago, Prof. Manuel Blázquez (Universidad Complutense de Madrid) documented a related vulnerability in Google AdSense — a different exploit (publisher-side, not advertiser-side) but with a structurally identical core: extract the validated ad URL through one channel, execute the click from another, exploit the fact that Google sees both sides while the victim sees only one. Blázquez reported it to Google in 2013, got no substantive response, and published. More than ten years later, we are publishing a variant of the same structural problem, still unpatched.

What advertisers can do today

Honestly, unilaterally, not much — the information needed to definitively detect this attack lives on Google’s servers, not yours. But there is a concrete first step worth taking:

Check whether this is happening to you. Cross-reference your server logs against the IPs you have added to your Google Ads exclusion list. If clicks are still being charged from IPs you believe are blocked, that is a strong indicator the harvest-and-replay technique is being used against your account. A second, complementary signal is GCLID reuse across multiple IPs in your request logs.
If you find it, escalate it to Google with the evidence. Server-side log extracts showing clicks from excluded IPs, and GCLIDs appearing from multiple IPs, are the kind of evidence that gets traction in invalid-click disputes. Make sure the ticket lands in Billing, not generic support.
Stop treating IP exclusion as a primary defence. It is one layer, and increasingly a weak one — both for the reasons we flagged previously (dynamic IPs, CG-NAT) and for the structural reason documented in this post. Detection needs to sit on behavioural and server-side signals that attackers cannot mask by swapping IPs.

If you want to understand the broader attack surface we are seeing across Google Ads — impression fraud, duplicate-GCLID billing, toxic YouTube placements — the rest of this blog is the place to start. And if you suspect you are being targeted and want an independent forensic audit of your traffic, that is exactly the work we do