Lessons from the Polymarket breach: why the third-party code you trust is the biggest risk to your website and mobile app this holiday season

TL;DR

• Attackers are reaching customers through third-party code instead of breaking into company servers. A hijacked DebugBear script drained about $2.7 million from Polymarket users in an hour on October 29, and AppsFlyer's Web SDK served a crypto stealer in March.
• Mobile apps carry the same risk through third-party SDKs. They get less scrutiny than websites and take days longer to fix, because every update has to clear app store review.
• PHP2Shell gives attackers another route in. A compromised PHP server, yours or a vendor's, can add skimmers to the pages shoppers load, and patching doesn't remove what was planted first.
• North Korean groups are planting malicious code in trusted libraries and lookalike packages that developers find through search.
• Holiday traffic makes payment flows the most valuable target of the year, and code freezes don't stop vendors from changing their code.
• Retailers should audit the scripts on their web pages and the SDKs in their mobile apps now. Feroot can find and block malicious third-party code on both, and it analyzes mobile apps without pulling developers off holiday work.

Do you know what third-party code is running on your website and inside your mobile app right now? Feroot identifies malicious scripts and SDKs and blocks attacks like this one in real time, and has already blocked them for multiple clients. Get a complimentary Feroot scan of your web pages and mobile apps.

Third-party code has become the easiest way to reach a company's customers. It runs in their browsers with the site's full trust, and almost nobody reviews it. On October 29, attackers drained about $2.7 million from 737 Polymarket accounts in roughly an hour. Nobody broke into Polymarket's servers or its smart contracts. The money left through a third-party script on Polymarket's own site.

Retailers carry the same risk at a larger scale. They run dozens of scripts like it across their websites, on their checkout pages and inside their mobile apps, where third-party SDKs get even less scrutiny. Most of those teams believe their payment flows are locked down. Polymarket had sensible controls in place, including a Content Security Policy and an approved vendor list, and the attack still got through.

What happened at Polymarket

The attack was hard to see coming because it arrived through a trusted vendor, and attackers could change the vendor's script without touching anything Polymarket built. The script was DebugBear's real user monitoring (RUM) tool, which Polymarket used to measure page speed. DebugBear says attackers changed its DNS records through its domain registrar. The script address on Polymarket's pages stayed the same, but a server the attackers controlled started answering at it.

The replacement file could move money because it ran inside users' logged-in sessions with the same access as Polymarket's own code. It read trading API keys stored in the browser, found the app's own transaction signer, and used it to sell positions or send tokens to an attacker wallet. Bitquery found approvals being used 3 to 7 seconds after they were created, so this was automated from start to finish.

A Content Security Policy couldn't have stopped it, because the DebugBear host was legitimately on the approved list, and so was every other host the script contacted. That is exactly how a trusted vendor is supposed to look. Polymarket responded quickly: it removed the script within the hour, paused its relayer, reset user sessions, and says it has refunded about 95% of affected wallets in full, returning $3.9 million to traders in total.

Would you catch a vendor script that changed while its URL stayed the same? Feroot flags scripts whose code or behavior changes and blocks them before they touch customer data. Request a complimentary scan.

AppsFlyer had the same problem in March

The AppsFlyer incident shows how far one compromised vendor domain can reach. From March 9 to 11, websdk.appsflyer.com served malicious JavaScript to every site that loaded AppsFlyer's Web SDK. AppsFlyer told BleepingComputer the cause was a domain registrar incident, the same entry point the DebugBear attackers used seven months later. The company says its SDK platform serves about 15,000 businesses.

Nobody noticed right away because the injected code kept the SDK's analytics working, so marketing teams saw normal events in their dashboards. Underneath, it hooked the browser's network requests and swapped cryptocurrency wallet addresses for ones the attackers controlled. Feroot's research team was one of three groups that independently confirmed the compromise by analyzing archived copies of the payload, according to the Cloud Security Alliance's research note.

These attacks are hard to stop because the attackers never needed the vendor's source code or application servers. They went after the registrar, took over a domain that every customer had already allowlisted, and let visitors' browsers run the result.

Your mobile app has the same exposure, and fewer people are watching it

Mobile apps carry the same risk with even less oversight, since most retailers audit their apps far less than their websites. A typical retail app ships with third-party SDKs for analytics, attribution, advertising, crash reporting, payments and customer chat. Each one runs inside the app with the app's own permissions. Some fetch configuration or code from the vendor after the app is installed, and many checkout screens load web content in a WebView, which puts third-party JavaScript straight back into the payment flow.

App store review won't protect you from a bad SDK. It has already missed them. In February 2025, Kaspersky found a malicious SDK called SparkCat inside apps on both Google Play and Apple's App Store, the first known stealer to get past App Store review. It was disguised as an analytics module, pulled its configuration from GitLab, and scanned users' photo galleries for crypto wallet recovery phrases. The infected Android apps had been downloaded more than 242,000 times, and the developers who shipped them likely had no idea. A new SparkCat variant got into both stores again in April 2026.

The mobile audit can't wait. Problems in an app take far longer to fix. You can pull a bad script from a website in minutes, but a vulnerable or malicious SDK stays on every phone running the old build until customers install your update, and app store review adds time before that update is even available. An audit that finds a problem the week of the sale is too late to protect that weekend's shoppers.

Most retailers have this blind spot because the teams that monitor website scripts rarely have the same view inside the app. Auditing a mobile app at the code level means listing every SDK and library in each iOS and Android build, checking them for known vulnerabilities and unapproved behavior, and watching what data and API calls each one sends once the app is running. Done by hand, that work lands on mobile developers in the busiest weeks of their year.

Most security teams have never looked inside their own app. Feroot's MobileGuard analyzes your iOS and Android apps without requiring any work from your developers. It audits every SDK in the app and flags the ones behaving in ways you never approved. Get a complimentary web and mobile app scan.

PHP2Shell: a server bug that ends up in the shopper's browser

PHP2Shell matters to retailers because it gives attackers a direct way to rewrite the pages of PHP-based stores. The name covers two flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0. They let an unauthenticated attacker run code on any reachable server with a vulnerable PHP version, which includes many stores built on WordPress, Magento (Adobe Commerce), Drupal and Joomla.

Attackers moved fast. Details leaked on October 20 and fixes (8.2.35, 8.3.36, 8.4.27 and 8.5.12) shipped on October 21, but Amazon's honeypots had already logged an exploitation attempt on October 17. By October 25, one attacker had chained the flaws with a Linux kernel exploit to root 25 servers.

The damage from this server bug shows up in the customer's browser, because whoever controls the server controls what its pages send to shoppers. That could mean a skimmer on the payment and login forms, a form that quietly copies each entry to a server the attacker controls, or a redirect or fake overlay that sends shoppers to a phishing page. SOCRadar found that one PHP2Shell operator's toolkit also included scripts for pulling API keys and backend URLs out of websites' client-side JavaScript.

Patching your own servers covers only half the exposure. Analytics tags, chat widgets, A/B testing tools, marketing pixels and plugins are served from vendors' infrastructure. If a vendor runs vulnerable PHP, an attacker can change its script at the source, and every site that loads it starts delivering the malicious version at once, the same pattern as AppsFlyer and DebugBear. You can patch every server you own and still serve a compromised script to every shopper.

A fully patched store may still be compromised, because patching doesn't undo anything that happened before it. A backdoor or injected script added during the exposure window can stay in place after the upgrade, and firewalls and vulnerability scanners don't see what a script does once it loads in the browser. As Feroot wrote when the flaws were disclosed, the patch closes the hole without telling you what your pages, and your vendors' scripts, delivered to customers before you closed it.

Patched, but not sure what your pages served before you did? A complimentary Feroot scan shows every script running on your checkout and login pages today, where each one came from and what data it can reach. Start your scan.

Why Black Friday and Cyber Monday raise the stakes

The holiday weekend is the most dangerous time of year for a checkout flow. More card numbers move through retail payment forms and apps that weekend than at any other point.

A holiday code freeze can give teams false confidence, because it only covers what their own developers ship. A vendor can still change the file behind a script tag on its own schedule, an SDK update can ride along in a routine app release, and marketing can still add a promotion pixel, a chat widget or a buy-now-pay-later badge in the last week, since nobody files those as code changes. A store can pass its last review and still be running code nobody on the team has looked at.

Retailers may not find out they were hit until long after the season ends, because a skimmer works quietly. A script like the one in the Polymarket incident could have read the card number, expiry and CVV fields on a checkout page just as easily. A retail skimmer copies card data in the background, and the fraud surfaces weeks later as chargebacks, after the holiday numbers have already been reported.

Merchants also have a compliance reason to act, because PCI DSS 4.0.1 already requires them to control payment page scripts. Requirement 6.4.3 asks for an inventory of every script on payment pages, a written reason for each one, and a way to confirm each script's integrity. Requirement 11.6.1 asks merchants to detect unauthorized changes to payment page content and HTTP headers. Both became mandatory on March 31, 2025. The DebugBear and AppsFlyer files are the kind of change 11.6.1 was written for, since each one kept its URL and its approved domain while the code inside changed.

North Korea is working the same supply chain

Nation-state attackers make this risk harder to manage. North Korean groups have spent 2026 planting malicious JavaScript in code that developers trust. Google's Threat Intelligence Group attributed the March hijack of Axios, one of the most widely used JavaScript libraries on npm, to a suspected North Korean actor it tracks as UNC1069. Other campaigns publish lookalikes built to pass for the real thing: JFrog found six npm packages imitating rollup-plugin-polyfill-node, and researchers caught a fake package called easy-day-js posing as the dayjs date library inside the Mastra ecosystem. In late October, ESET reported that one group had moved on to stealing developer credentials and pushing malware into legitimate projects on npm, Packagist, PyPI and browser extension stores.

Developers can pull these fakes in by accident, since Google search is part of the lure. Check Point found that spoofed sites from the Lazarus group's Operation Dream Job campaign ranked at the top of Google results. A developer who searches for a library, a code snippet or a vendor's tag can land on a copy that looks right and carries a hidden loader.

These campaigns have mostly targeted crypto wallets and credentials, but retailers should still pay attention. Once trusted-looking JavaScript gets into a build or onto a page, it runs in every visitor's browser with the same access your own code has.

What to check while there's still time

Start with the app. Mobile fixes need extra days to clear app store review, and peak traffic is close.

1. List every SDK and library in your current iOS and Android builds and audit them at the code level for known vulnerabilities and behavior you never approved. If your developers are tied up with holiday releases, use an approach that doesn't depend on them. Submit any fixes now so the update is live before the weekend.
2. List every script that runs on checkout and payment pages, including the fourth-party code your vendors pull in. Remove anything checkout doesn't need; RUM tools, heatmaps and chat widgets rarely belong there.
3. Watch what each script and SDK contains and what it does once it runs. A domain allowlist approved both the DebugBear and AppsFlyer files.
4. Pin web scripts with Subresource Integrity where the vendor supports it, so the browser rejects a file whose contents have changed.
5. Upgrade PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, then compare your checkout templates and the scripts they load against a known good copy from before October 17. Ask each script vendor whether the servers delivering its code run PHP and when they were patched.
6. Extend the code freeze to third-party tags and SDK version bumps, with a cutoff date after which nobody adds a pixel, widget or library to payment flows.
7. Decide now who can block a script or shut off an SDK feature over the holiday weekend, and time how long it takes. In the Polymarket incident, the whole drain played out in about an hour.
8. Keep your PCI DSS 6.4.3 script inventory and 11.6.1 change records current. Your assessor will ask for both.

How Feroot identifies and blocks these attacks

These attacks run in the shopper's browser and inside the app, so that is where Feroot works. It covers the digital experience layer: the scripts, tags, SDKs and third-party code running on your customers' devices, where WAFs and server-side scanners have no view.

Spotting a bad script after the holiday weekend is too late, so Feroot identifies and blocks attacks while they are happening. It flags a script or SDK the moment its code changes or it starts doing something it never did before, such as reading payment fields or sending data to a new destination. DXSecure then blocks it before card numbers or credentials leave the page. Feroot has already blocked this kind of attack for multiple clients. PaymentGuard protects payment pages and produces the evidence PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 call for.

Mobile is where Feroot stands apart from other client-side security vendors, because a retailer's app carries the same third-party risk as its website with far less oversight. MobileGuard, a key feature of the Feroot platform, audits iOS and Android apps at the code level, inventories every SDK and API call inside them, and flags SDK behavior and data flows you never authorized. It does this without requiring developer intervention, so your security team can audit the app on its own while developers stay focused on holiday releases. DXSecure enforces the same authorization policies across websites and mobile apps.

Feroot knows what these attacks look like because our researchers took the AppsFlyer payload apart in March.

Find out what's running before holiday traffic peaks. A complimentary Feroot scan of your web pages and mobile apps shows every third-party script and SDK, what each one can reach, and which ones Feroot would block. Get your complimentary scan.

Sources

• Polymarket hack investigation (Bitquery)
• Hackers steal about $2.7 million from Polymarket traders via hijacked DebugBear script (The Hacker News)
• Some Polymarket user funds stolen by hackers (CNBC)
• AppsFlyer Web SDK used to spread crypto-stealer JavaScript code (BleepingComputer)
• AppsFlyer SDK supply chain crypto stealer research note (Cloud Security Alliance)
• Crypto-stealing apps found in Apple App Store for the first time (BleepingComputer)
• Kaspersky discovers new crypto-stealing Trojan in App Store and Google Play (Kaspersky)
• Kaspersky finds new SparkCat malware in app stores (Malaysian Wireless)
• PHP2Shell: why patching alone isn't enough (Feroot)
• Amazon says PHP2Shell exploitation began 4 days before patches (BleepingComputer)
• PHP2Shell attack roots 25 servers (The Hacker News)
• PHP2Shell exploitation: two critical PHP flaws explained (Recorded Future)
• PHP2Shell exploit tooling found on exposed attacker server (SOCRadar)
• North Korean hackers blamed for hijacking Axios (TechCrunch)
• North Korean hackers use fake coding tools (The Korea Herald)
• North Korean hackers abuse Mastra npm supply chain (Cyber Security News)
• North Korean hackers steal developer credentials to inject malware (Cyber Security News)
• North Korean recruitment scam fooled Google (TechRadar)