A Two-IP Trick Just Rendered Google Ads Exclusion Lists Useless
Faktica Analytics, a Madrid PPC agency, published a proof-of-concept on April 21 showing Google Ads IP exclusion lists can be bypassed by splitting a single click across two IP addresses. A hidden IP harvests the ad URL and the GCLID, then hands both to an already-excluded IP that fires the click Google still charges for. The fix every advertiser can run this week is a 10-minute server-log cross-check against the exclusion list.
The mechanism is boring, which is why it works
The attack uses two coordinated IPs instead of one. IP A is clean, unknown to the advertiser, not on any exclusion list. It loads the ad and grabs the redirect URL along with the GCLID (the Google Click Identifier that Google uses to attribute and bill the click). IP B is already on the advertiser's exclusion list. The payload gets handed over, IP B fires the click, and Google charges it.
Because the GCLID was generated legitimately at harvest time, it passes Google's server-side validation. The fraud isn't in the identifier. It's in the gap between who requested the URL and who consumed it. Google's click-accounting pipeline doesn't appear to compare the two.
Faktica's Marcos Ferreiro Rodriguez demonstrated this end-to-end on the agency's own Google Ads account in March, then published the full technical writeup on April 21. PPC Land covered it on April 24.
Why this isn't new, and why that's the uncomfortable part
A structurally similar exploit against AdSense was documented by Prof. Manuel Blazquez in 2013. Same idea: separate the fetch from the click, and any per-IP guardrail falls over. That vulnerability has been quietly open for 13 years.
So the question isn't really "did someone find a clever trick." The question is why an auction that bills to the sub-penny has no internal consistency check comparing the IP that harvested a GCLID against the IP that eventually consumed it. From what I've seen across the industry, it's probably because Google prefers false positives on click invalidation to be rare. Adding a new join between two log streams risks flagging legitimate prefetch or redirect behavior, and any false positive costs billable clicks. Which means the incentive to fix this quietly runs the wrong way.
Anyway. The hole exists. The fact that it has existed for more than a decade is the part the Ads PM team is going to have trouble spinning.
The cost is already landing somewhere
Faktica says it has identified client accounts showing six- and seven-figure losses consistent with this pattern. That's their number, not an independent audit, so treat it as a floor, not a benchmark. But it tracks with the broader fraud picture. Fraud Blocker's 2026 data puts the average Google Ads invalid-click rate at 11.5%, up from 5.9% in 2010. Display and Video campaigns run north of 30% invalid. Google's own detection catches an estimated 40 to 60 percent of fraudulent clicks, depending on which third-party study you trust.
The part that stings for anyone running exclusion lists is that the lists aren't really a defense. They're an audit surface. A click showing up in your server logs from an IP you excluded six months ago is evidence of active bypass, not an overdue admin task.
The 10-minute audit any PPC manager can run this week
Two checks are worth doing now. Both require access to your web server logs (nginx, Apache, Cloudflare, or whatever log store you already have) and your current Google Ads IP exclusion list.
Check one: excluded-IP click attempts. Grep your server access logs for any request carrying a GCLID parameter where the source IP is on your exclusion list. If you find any, that's a direct indicator that clicks are being fired from an IP Google was supposed to have blocked at the auction. Document the timestamp, the GCLID, the IP, and the landing page.
Check two: GCLID replay across IPs. Pull the last 30 days of requests with a GCLID and count distinct source IPs per GCLID. A GCLID is a single click. If one GCLID shows up from three IPs inside 60 seconds, something split the harvest from the click. If you see it across different countries, that's close to conclusive. Faktica describes this as the exact trace the harvest-and-replay technique leaves behind.
Both checks take under 10 minutes if your logs are in BigQuery or any SQL-queryable store. They take an afternoon if you're grepping raw log files on a box somewhere. Either way, this is a this-week task, not a next-quarter task.
A third signal worth pulling while you're in the logs: time-of-day clustering on your excluded IPs. Bypass traffic tends to run at odd, non-human hours because whoever is operating the harvester doesn't care what time zone the advertiser is in. If your excluded-IP click attempts cluster between 2am and 5am local time across weekdays and weekends alike, that is not a disgruntled ex-employee or a competitor clicking from a laptop. That's automation, and the volume is often larger than the overall click-fraud number first suggests because most of those clicks were being absorbed silently.
What to do with what you find
If you get hits, escalate to Google's Billing team directly, not the normal Ads support queue. The Ads queue is not equipped to investigate click-level auction behavior. Billing is the team that can refund charges tied to specific GCLIDs. Include the GCLID, the source IP, the timestamp, and a screenshot of the IP sitting on your exclusion list at the time of the click.
It's also worth reading Search Engine Land's 2026 breakdown of where click fraud exposure is rising. The piece predates the Faktica writeup but the campaign-type risk profile it describes lines up cleanly with why this bypass is most painful for Display and Video budgets first.
Third-party click fraud tools that rely on IP blocking (most of them) inherit the same vulnerability. That doesn't make them useless, but it means the IP-exclusion layer on any tool marketing itself as fraud protection is doing less than its dashboards suggest. If you're paying a vendor primarily for IP exclusion management, that is a fair conversation to have with their team about what's actually being protected right now.
The pattern this fits into
This is the third Google Ads security story in six weeks where the detection asymmetry runs the same way. Agencies self-reported MCC hijacks that Google never caught proactively. Agencies got phished through their own contact forms. And now an exclusion-list bypass that requires the advertiser, not the platform, to do the forensic work.
The takeaway isn't that Google Ads is uniquely broken. It's that the defensive posture has quietly shifted. Assume the first-party controls will catch about half of the bad actors, and build your own instrumentation for the other half. Agencies that treat server-log auditing as a monthly reconciliation (the way finance reconciles a bank statement) will catch bypass patterns months before Google does, if Google ever does.
Run the audit before it becomes common knowledge
Faktica's post is public. The technique is documented. Once a proof-of-concept exists on the open web, adoption by less scrupulous operators is usually a matter of days, not quarters. If your exclusion list has been sitting there for a year and you've never cross-checked it against your logs, you're probably paying for clicks you already told Google not to charge you for.
The audit takes less time than one internal meeting. Just run it, document what you find, and send the evidence to Billing before the end of the week.
Notice Me Senpai Editorial
