Every analytics tag, ad pixel, and mobile SDK on your properties is third-party code your organization does not control, cannot review, and cannot patch. Recent advances in AI have made each one inexpensive to weaponize. This briefing sets out what we look for, and why continuous monitoring of digital tracking technology has become a baseline expectation.
A six-part assessment of why third-party JavaScript and mobile SDKs have become the lowest-cost path to your customers, and how to detect changes as they occur rather than months later.
If you run a marketing site, a mobile app, or a connected-TV experience, you load a substantial amount of code from other companies on every session. Tag managers. Analytics. Ad pixels. Session replay. Chat widgets. SDKs. Cloudflare's 2024 Application Security Report puts the typical enterprise customer at 47 third-party scripts on the page and connections to 50 separate third-party destinations, with retail and travel sites running higher. Each script runs with the same privileges as your own code: it can read the DOM, capture form input, and call external endpoints. Each one also updates on a schedule you do not set, through a CI/CD pipeline you do not see.
This is the digital tracking technology (DTT) layer. It is the most powerful tool available to a modern marketing team, and it is also, increasingly, the lowest-cost route for a malicious actor to reach your customers. We monitor it because few others do, and because the developments of the past twelve months have fundamentally changed the economics of who can attack you, how quickly, and at what cost.
Until recently, weaponizing a known JavaScript or SDK vulnerability was difficult. Skilled human attackers required days to weeks of focused work, and the most valuable resulting exploits traded on public broker price lists for somewhere between $100,000 and $2.5 million. That cost structure placed serious supply-chain attacks against ad-tech, analytics, and tag-manager scripts largely out of reach for all but nation-states and elite criminal groups.
That ceiling is now moving. In April 2026, Anthropic announced Project Glasswing, a defensive cybersecurity initiative built around a new frontier model called Claude Mythos Preview. Anthropic and its partners (AWS, Apple, Microsoft, Google, JPMorganChase, CrowdStrike, Cisco, Palo Alto Networks, NVIDIA, Broadcom, and the Linux Foundation) confirmed that the model is already finding and exploiting vulnerabilities at a level that "surpasses all but the most skilled humans."
Mythos Preview has identified thousands of zero-days across every major operating system and web browser, scored 83.1% on the CyberGym vulnerability-reproduction benchmark, and in some cases discovered flaws that had survived decades of human review and millions of automated tests. Glasswing is structured as a defensive effort. The capability it documents, however, is not confined to good-faith users. As CrowdStrike's CTO observed, "what once took months now happens in minutes."
For supply-chain risk, the relevant takeaway is not the specific benchmark number. It is the trajectory. Finding and weaponizing vulnerabilities was once a scarce specialty; it is becoming routine. Every line of vendor code on your site, including every tag manager script, every analytics SDK, and every chat widget, shares the character of the codebases in which Mythos Preview is finding bugs. The vendor scripts considered "too small to bother with" yesterday will not remain so for long.
The attack surface of digital tracking technology is not theoretical. It is documented in legal filings, GDPR enforcement actions, and SEC disclosures going back nearly a decade. The shape of the attack is consistent: a small change to a piece of trusted, externally-hosted code goes unreviewed, propagates silently to every property loading it, and exfiltrates data for days to months before anyone notices.
The history of web supply-chain attacks reads like a single paragraph rewritten with different victim names. Four examples follow, all pre-Glasswing and executed by skilled humans against high-value targets:
Attackers modified 22 lines of JavaScript in Modernizr 2.6.2, a third-party library running on BA's payment pages. The injected code copied every customer's name, address, card number, and CVV to baways.com while bookings appeared to complete normally.
An attacker modified the source of [24]7.ai's customer-service chat widget, scraping payment data from every site that embedded it, including Sears, Kmart, and Best Buy. The compromise ran in two windows in late 2017. The vendor took months to notify affected brands, and one of them sued.
After a quiet acquisition, the new owners injected malicious JavaScript into cdn.polyfill.io. Every site loading this trusted, decade-old library was instantly weaponized, redirecting mobile users to scams and deploying malware. The attack ran for months. No code review caught it.
Attackers extracted a credential from a Codecov Docker image and modified a single line in the hosted Bash Uploader to silently exfiltrate CI environment variables (AWS keys, tokens, and passwords) for roughly two months. The change was discovered only when a customer manually compared the script's SHA256 checksum.
These are pre-Glasswing attacks. The Mythos Preview benchmark indicates that the rate of new discovery, and the speed of moving from "vulnerability known" to "exploit working," is set to accelerate. Targets that were not previously worth a skilled attacker's time will become worth the time of a less-skilled one.
Web is the most closely watched surface, and it is still failing. Mobile and connected TV are barely watched at all, and they are failing more severely.
The lesson is consistent across platforms: an SDK or script that appears benign at review time can turn malicious in production, following a software update that the app store does not re-review. Mobile ecosystems are full of overpermissive third-party SDKs. Academic work auditing the Google Play SDK Index has found that more than a third of audited SDKs over-collect data relative to their stated privacy policy, and that this rate has not improved meaningfully year over year.
Across the Vault JS customer base, we observe dozens of vendor-script changes each month on a typical enterprise marketing stack. Almost none are reviewed by the customer's security team before going live.
Most enterprises already operate a CMP for consent, a WAF for traffic, an EDR on endpoints, and a CSP header on the page. None of these is designed to monitor how vendor code changes over time:
The gap is specific and well defined: continuous, behavior-level observability of every third-party script and SDK, every time it changes.
Detection times for supply-chain breaches are routinely measured in months. That is long enough for an attacker to copy card numbers, credentials, or session tokens to a server named to resemble ordinary analytics traffic.
Vault JS is an independent, third-party privacy compliance monitoring platform for enterprise web, mobile, and CTV properties. It does not install code on your site, and it does not block, enforce, or proxy traffic. Instead, it observes, continuously, every third-party script and SDK in your environment, every change to each one, and every resulting shift in behavior. We then report exactly what changed, who is responsible, what risk it carries, and what to do about it.
We observe vendor code the way an attacker's payload actually reaches a victim: from the outside. Vault JS operates a fleet of fully instrumented browsers and real mobile and CTV devices that load your public properties continuously, in the same way your customers' devices do, and execute every third-party script and SDK in a runtime we control and record.
Cloud browsers and real devices render your pages and app surfaces on a schedule you set, from the regions and platforms your customers actually use.
Inside that sandbox we record every network request, DOM read, cookie and storage write, and API call each tag makes, at the moment it makes it, rather than from a static manifest.
Nothing of ours runs on your property, so we add no latency, introduce no new code path, and leave nothing for an attacker to find or disable.
No inline proxy. No browser extension. No on-page agent. It is continuous observation of what your vendors' code actually does, in the runtime where it runs.
That outside-in stream is large, comprising dozens of vendor changes a month on a typical enterprise stack. A four-layer pipeline narrows it to the few that warrant human review, in order of increasing scrutiny:
In practice, we look for the change types that carry the highest signal for a malicious actor, and we score each one by severity. The scoring runs identically across web, mobile, and CTV; only the telemetry differs, because we score the behavior rather than the platform.
| Change type |
Web | Mobile | CTV |
|---|---|---|---|
| Storage scope expansionHigh | New cookies, extended lifetimes, and new localStorage keys. | New SharedPreferences or Keychain entries, and expanded SQLite scope. | New persistent device identifiers that survive across sessions. |
| New input-surface accessCritical | Reads form fields it did not read yesterday: the Magecart and formjacking pattern. | SDK begins reading clipboard, contacts, photo gallery, or camera. | Expanded device fingerprint or a new ACR (automated content recognition) signal. |
| New 4th-party sub-resourceCritical | Vendor X begins loading Vendor Y: the delivery vector trusted vendors get used for. | Dynamic class loading or a runtime native-library swap. | A playback resource pulled from a new host mid-session. |
| Obfuscation or packing shiftHigh | Minifier or packer changes; code begins trying to hide what it does. | Bytecode packing increases, a native-library swap, or a new obfuscator signature. | Bytecode packing or a signature change in the player binary. |
| Permission or capability escalationHigh | No web analog. | Runtime permission request expands beyond the SDK's prior baseline. | Device-API capability request expands: microphone, network discovery, storage. |
Because we score the behavior at the version where it changes, a malicious mobile or CTV update is caught when it ships, not at an app store's one-time review. This is precisely the SparkCat and Keenadu pattern described in §03.
The case for continuous monitoring of digital tracking technology is not that every vendor will be compromised. It is that some will, that the cost of compromising them is falling, and that detection times remain long. Even shorter incidents, such as Codecov's two months or the weeks-long [24]7.ai chat-widget compromise, represent considerable windows for an attacker copying card numbers, credentials, or session tokens to a server named to resemble analytics traffic.
Find the change first. Tell the security team what changed, where, and how to remediate it. Provide the privacy team with audit-ready evidence of whether the vendor was, or was not, doing what it claimed. That is the work.
Request a third-party attack surface audit for your web, mobile, and CTV properties: a complete, evidence-grade map of every script and SDK running on them, with the changes, origins, and risks already classified.
Request an audit at vaultjs.com→