Written by Mike Kutlu, cside. Payment-page figures come from cside's production browser telemetry over the 14 days ending 2026-07-22 on PCI-scoped pages. Attack context comes from public incident reporting and cside's own published analysis. Methodology and limits are set out at the end. Last reviewed July 2026.
TL;DR
- The median PCI-scoped payment page loads 3 distinct third-party script hostnames. The 90th percentile loads 9, the 99th loads 22.
- About 48% of the distinct scripts on those pages were loaded by another script, not by the page's own HTML, and roughly 65% of pages carry a dependency chain at least three hops deep.
- The surface is fragmented. The top 10 hostnames cover about 41% of monitored-page presence, but reaching 80% takes around 100, and the tail runs past 9,000.
- 91.6% of pages served at least one script they had never served before during the window, at a median of 8 new scripts per page.
- In June 2026 a compromised third-party vendor put a wallet-drainer script into Polymarket's frontend and took roughly $3 million from users' wallets without breaching a server or touching a smart contract.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
Executive summary
Merchants can usually name the third parties they added to a checkout. What they cannot name is the code those third parties bring with them, and that is what this report measures.
Across the PCI-scoped checkouts cside monitors, the median page loads 3 distinct third-party script hostnames, which sounds manageable. But 48% of the distinct scripts observed on those pages arrived via another script rather than the page's own HTML, and about 65% of pages carry a load chain that runs at least three hops from the page. The merchant chose the first hop; a vendor, or a vendor's vendor, chose the rest.
PCI DSS 6.4.3 asks for an inventory of every script on the payment page with a business justification for each. At the median that is about 12 scripts, which a compliance team can work through in an afternoon. At the 99th percentile it is roughly 259, most of them chain-loaded, and nobody at the merchant is in a position to justify most of the list.
The inventory does not hold still either. Over two weeks, 91.6% of monitored payment pages served at least one script they had not served before, a median of 8 new scripts per page. Requirement 11.6.1 asks for change detection at least every seven days; that is the volume such a control has to keep up with.
In June 2026 a compromised third-party vendor injected a wallet drainer into Polymarket's frontend and drained roughly $3 million from users' wallets. Nothing was breached server-side and the contracts were untouched; the whole compromise happened in the browser.
| Metric (14 days ending 2026-07-22) | Value |
|---|---|
| Third-party script hostnames per page (median / p90 / p99) | 3 / 9 / 22 |
| Distinct scripts per page (median / p90 / p99) | 12 / 46 / 259 |
| Scripts loaded by another script | 48% |
| Pages with a chain 3+ hops deep | 65% |
| Pages that saw a new script in the window | 91.6% |
Every count is a genuine third party. The merchant's own first-party scripts and cside's own infrastructure are excluded.
What a payment page actually loads
The inventory required by 6.4.3 starts with a choice of unit, and the two available units give very different answers.
Measured at the hostname level, the median page is modest: 3 distinct third-party script hostnames, 9 at the 90th percentile, 22 at the 99th. Measured as individual scripts, the same pages carry a median of 12, a 90th percentile of 46, and a 99th percentile around 259. A hostname count tells you how many distinct parties the page talks to; the script count is what an assessor will ask you to enumerate.
The head of the distribution is familiar and overwhelmingly Google:
| Rank | Third-party hostname | Share of monitored payment-page configurations |
|---|---|---|
| 1 | www.googletagmanager.com (Google Tag Manager) | 39.7% |
| 2 | www.gstatic.com (Google static content) | 19.4% |
| 3 | www.google.com (reCAPTCHA, accounts, other Google services) | 17.1% |
| 4 | connect.facebook.net (Meta Pixel) | 13.0% |
| 5 | pagead2.googlesyndication.com (Google Ads) | 11.4% |
| 6 | www.google-analytics.com (Google Analytics) | 10.6% |
| 7 | googleads.g.doubleclick.net (Google Ads / DoubleClick) | 9.5% |
| 8 | static.cloudflareinsights.com (Cloudflare) | 9.2% |
| 9 | www.blogger.com (Google) | 9.2% |
| 10 | apis.google.com (Google APIs) | 7.9% |
Those ten hostnames account for about 41% of monitored-page presence. Getting to 80% takes roughly 100 hostnames, and behind them sits a tail of more than 9,000 distinct third-party hostnames. On a Herfindahl-Hirschman index the surface scores about 0.023 on a 0-to-1 scale, which is a fragmented market.
Past the head, checkouts stop resembling one another, and there is no shared list of usual suspects that an assessor or a vendor-risk team can work from.
Half of it was loaded by another script
The counts above say nothing about who put the code on the page, which is where the compliance problem starts.
When cside classifies the distinct scripts on monitored payment pages by how they were loaded, 48% were demonstrably pulled in by another script. The remaining 52% surfaced with no recorded parent, meaning they were loaded by the page's own HTML or their parent metadata was missing.
Measured as hops from the page outward, about 65% of pages reach a three-hop chain: the page loads a script, that script loads a second, and the second loads a third. That measurement is capped at three hops, so the real chains on those pages may run deeper. Only around 31% of pages stop at a single hop.
| Stage | Touchpoint | Catches | Misses | Summary |
|---|---|---|---|---|
| Page HTML | Merchant | Scripts the team added; Vendors under contract; Visible in the tag manager | Anything those scripts load next | Only 31% of pages stop at this hop |
| First hop | Vendor | The vendor you signed with | What that vendor loads next; Updates shipped without notice | 48% of scripts arrive via another script |
| Second hop+ | Sub-vendor | — | Not in any inventory; No contract with the merchant; No change notice | 65% of pages reach at least this far |
Adding a tag manager is one decision by the merchant. Everything that container loads afterwards is somebody else's decision, taken without notice, on the page that handles card data.
Google Tag Manager is the most common injector, and it mostly injects Google
Google Tag Manager is the single most common third party on payment pages, present on about 40% of monitored PCI configurations and roughly 38% of registrable domains. It is also the most common injector.
Concentration like that reads as supply-chain risk until you look at what GTM is loading. Of everything GTM was observed injecting on payment pages, about 93% was Google's own advertising and analytics stack. About 7% pointed at a genuinely non-Google third party.
Most of the exposure is therefore a Google-to-Google dependency, which is still exposure, but exposure to a party the merchant already has a contract with. The 7% is the unpredictable part: arbitrary third-party code reaching a payment page through a trusted container, chosen by whoever holds container access rather than by whoever owns PCI compliance.
Server-side tagging would blunt this, and almost nobody uses it. Fewer than five in every hundred thousand GTM requests on monitored payment pages carried a server-side prefix.
June 2026: the Polymarket wallet drainer
In June 2026 attackers compromised a third-party vendor and injected a wallet-drainer script into the frontend of the prediction-market platform Polymarket. The script took roughly $3 million from a small number of users' wallets. The smart contracts and the chain underneath were not involved: the theft executed in the browser, through a third-party script the platform had trusted for months.
There was no payment form to skim, so the injected code did not behave like a card skimmer. It operated inside the interface, issuing wallet-approval requests through Polymarket's own UI. Users approved them because nothing about the interface looked wrong.
The crypto specifics are incidental. What is left is a trusted third-party script, several hops removed from anything the platform deliberately chose, turning malicious in the browser, and the same mechanism works just as well against card fields on a checkout. cside's full technical breakdown is in Inside the Polymarket $3M client-side supply-chain attack.
Most alerts are outdated libraries
When cside's script monitoring fires on a PCI-scoped page, the mix is lopsided.
| Alert category | Share |
|---|---|
| Known JavaScript-library vulnerabilities (CVE-matched dependencies) | 88% |
| Known-malicious / malware scripts | 9% |
| Other or uncategorised script-integrity alerts | 3% |
Roughly nine in ten alerts are outdated libraries with published CVEs: a patching and inventory problem, and where most of the day-to-day work sits. The 9% that are known-malicious carry critical severity, and they arrive through the same monitoring channel as the library noise. Any filter broad enough to quieten the other 91% will hide them too.
What to do about it
- Inventory what your tags load. A list of what your team added is not a 6.4.3 inventory when 48% of what runs was loaded by something else. Ask your top-level vendors what they pull in downstream, and treat any page where you cannot answer that as unmeasured.
- Budget for the 99th percentile. An inventory of twelve scripts fits in a spreadsheet; at 259 it needs tooling and a named owner. Find out which of your checkout pages is the outlier before an assessor does.
- Size change detection against the real rate. Nine in ten pages see a new script inside two weeks, at a median of 8. A seven-day control that raises a manual review for every change will fall behind in the first cycle, so decide in advance what gets auto-triaged.
- Watch behaviour at runtime. A drainer or a skimmer three hops deep in a chain will not show up in a static scan of what you meant to install, and in the Polymarket case there was nothing server-side to alert on in the first place.
Methodology and data-hygiene notes
- Window and population. All payment-page figures come from the 14 days ending 2026-07-22, drawn from pages designated PCI-scoped in cside's monitoring configuration. The population is cside's monitored customer base across e-commerce, ticketing, non-profits, hospitality, and financial services. It is not a random sample of the web, so the distribution can skew relative to the internet at large. The direction of that skew is not characterised here.
- Third-party definition. "Third-party" excludes any resource served from the payment page's own registrable domain, and excludes cside's own infrastructure (
csidetm.com,csidefd.com,cside.com,cside.dev,client-side.dev). - Hostnames are not vendors. Per-page counts in this report are distinct third-party script hostnames and distinct scripts, not normalised vendor companies. One vendor commonly serves from several hostnames, so hostname counts run higher than vendor counts. Where vendor entities are counted separately the surface is more top-heavy: the top 10 vendor entities cover about 51% of tenant-and-domain observations, against 41% for the top 10 hostnames.
- Reach is measured per configuration. The hostname-reach table counts distinct monitored payment-page configurations, a grain close to but not identical to the registrable domain. Measured per registrable domain instead, Google Tag Manager's reach is about 38% rather than 39.7%. The 41% top-10 figure is a different unit again: share of monitored-page presence.
- Loader classification. A distinct script is counted as chain-loaded when it was observed with a non-empty parent. The remaining bucket combines page-HTML-loaded scripts with scripts whose parent metadata was missing; those two cannot be separated with the available fields, so 52% is an upper bound on genuinely page-loaded scripts.
- Chain depth is capped. Depth is measured in hops from the page and capped at three. Pages in the "3+" bucket may carry deeper chains that are not measured, so the depth figures are a floor. Depth is anchored on pages that expose at least one page-root load edge; pages without one are excluded.
- Approximate counters. Distinct-entity counts use approximate cardinality estimation, carrying roughly half a percent of error. Shares and index values inherit it.
- Alert categories. Category shares are drawn from cside's script-alert pipeline over the same window, grouped by vulnerability class. Absolute alert and site counts are deliberately not published.
- k-anonymity. Any breakdown with fewer than 10 tenants in a bucket is suppressed to prevent inadvertent single-merchant disclosure.
- Attack context. The Polymarket case draws on public incident reporting and cside's own published analysis. It is not an internal detection count.
- Corroborating sources. Sansec publishes named-family Magecart research, Verizon's DBIR tracks payment-card breach patterns, the PCI Security Standards Council publishes the current PCI DSS 4.0.1 requirements, and OWASP and MITRE ATT&CK provide the taxonomy this report's categories map to.
Report data current as of July 2026. cside is a client-side security platform that monitors JavaScript on customer web properties. For more, see cside.com.
