Third-Party Script Hijacking: Analyzing the Polymarket DNS Incident

Executive Summary In late October, a severe client-side supply-chain attack impacted the prediction market platform Polymarket, resulting in approximately $2.7 million stolen from 726 user wallets. The attack did not rely on a direct compromise of Polymarket's primary application infrastructure or smart contract code. Instead, threat actors targeted a third-party vendor, DebugBear, which provides website performance and monitoring scripts. By gaining unauthorized access to DebugBear's domain registrar account, the attackers modified DNS records to point traffic to an attacker-controlled server.

When visitors loaded the Polymarket site, their browsers automatically fetched JavaScript assets from the hijacked vendor domain. The rogue server delivered malicious payload code capable of manipulating browser session states and executing unauthorized transactions. This incident highlights a fundamental reality of modern web security: an organization's attack surface extends far beyond its own servers to encompass every external service, script, and domain embedded in its user-facing applications.

Technical Details Modern web applications rely heavily on external software-as-a-service (SaaS) utilities to handle analytics, performance monitoring, customer support, and user tracking. These third-party tools are typically integrated by embedding HTML script tags that pull executable code directly from vendor-controlled domains.

Domain Registrar Compromise vs. Subdomain Takeover It is important to distinguish this attack vector from traditional subdomain takeover. A standard subdomain takeover occurs when a DNS CNAME record points to an abandoned external service, such as an unclaimed cloud storage bucket. In this incident, the threat actors compromised the administrative management portal at the domain registrar level for the third-party provider. By altering the authoritative Name Server (NS) or address records for the vendor domain, the attackers redirected all HTTP and HTTPS requests intended for the monitoring service to infrastructure under their direct control.

Client-Side Execution Context When a browser executes an external JavaScript file specified in a script tag, that script runs within the origin context of the host application. Unless strictly isolated via sandboxed frames or constrained by browser security policies, third-party scripts enjoy full access to:

• The Document Object Model (DOM) of the host application.

• Local storage, session storage, and non-HttpOnly cookies.

• In-memory application state, user inputs, and active session tokens.

• Network requests made via browser APIs.

In the Polymarket incident, the malicious script injected code into the user session to intercept cryptographic wallet interactions and submit unauthorized trade requests. Because the script was loaded from a trusted vendor domain, standard network filtering did not block the initial retrieval.

Defensive Lapses: SRI and CSP Restrictions Two primary browser-level defenses exist to mitigate third-party script tampering: Subresource Integrity (SRI) and Content Security Policies (CSP). SRI allows web developers to define a cryptographic hash of a script file. If the file content on the remote server changes, the browser compares the calculated hash against the SRI value and refuses to execute the script if a mismatch is detected. When dynamic third-party scripts do not support static SRI hashes, a robust CSP can limit script execution locations or require nonces. In this case, the lack of strict cryptographic verification or permissive external script inclusions allowed the modified script to run unimpeded.

Exploitation & Risk Third-party script injection represents one of the most high-impact vectors for web applications because it bypasses conventional perimeter defenses such as Web Application Firewalls (WAFs) and server-side intrusion detection systems. The attack executes directly inside the end user's browser, completely outside the view of back-end security logging.

Attack Surface Expansion Every external domain integrated into a web application creates an implicit trust boundary extension. Organizations frequently maintain strict security controls for their own core subdomains while overlooking the risk profile of third-party domains. Key risks include:

• Unmonitored DNS record changes on vendor domains.

• Cascading failures where a single vendor compromise impacts hundreds of downstream client sites.

• Execution of arbitrary code within user browser sessions leading to session hijacking, credential harvesting, or financial manipulation.

• Exposure of sensitive customer data to unauthorized external endpoints via covert exfiltration requests.

For financial and cryptocurrency platforms, client-side script manipulation poses an existential threat. Attackers can dynamically alter transaction parameters, replace recipient wallet addresses, or invoke web3 provider calls without requiring the host server's permission.

Remediation & Defense Mitigating third-party script risk requires a layered defense strategy encompassing domain management, client-side browser controls, and continuous external visibility.

Securing Domain Infrastructure

• Enforce mandatory Multi-Factor Authentication (MFA) using hardware security keys for all domain registrar accounts.

• Implement Registry Lock status codes on critical domains to prevent unauthorized DNS or registrar modifications.

• Audit administrative roles and access logs within domain registrar portals regularly.

Application-Level Controls

• Implement Subresource Integrity (SRI) for all static third-party scripts by generating cryptographic hashes and including them in script tag attributes.

• Configure restrictive Content Security Policy (CSP) headers. Limit the script-src directive to explicit, trusted domains and avoid wildcards.

• Evaluate client-side script isolation technologies or reverse-proxy third-party scripts through owned, monitored infrastructure where feasible.

• Audit all client-side dependencies continuously to remove obsolete or unnecessary external integrations.

How Mangudai Can Help Mangudai provides Attack Surface Management (ASM) capabilities designed to give security teams continuous visibility into their external exposure footprint, including associated domain assets and client-facing configurations.

Through its Subdomain and External Infrastructure analysis module, Mangudai helps organizations maintain awareness of their exposed web landscape by performing passive and active external checks:

• Subdomain Discovery: Mangudai systematically identifies assets, subdomains, and hostnames linked to an organization's primary domain namespace, surfacing forgotten or unauthorized web endpoints.

• DNS and Infrastructure Mapping: Mangudai continuously monitors public DNS configurations, tracking IP resolution changes, authoritative nameservers, and mail exchanger records to alert teams to unexpected operational shifts.

• Security Header Analysis: Mangudai evaluates HTTP responses across discovered assets, verifying the presence and configuration of Content Security Policy (CSP) headers, HTTP Strict Transport Security (HSTS), and other defense-in-depth response attributes.

• Open Port and Service Identification: Mangudai scans external assets to identify open ports, active protocols, and running service banners.

• Exposed Sensitive File Detection: Mangudai checks public web roots for exposed configuration files, environment variables, or administrative interfaces.

• Banner-Based CVE Matching: Mangudai correlates identified service banners against known vulnerability databases, clearly marking matches as unverified indicators that require further manual confirmation.

Mangudai operates strictly from an external perspective. It does not perform dynamic JavaScript execution analysis, payload sandboxing, or internal application code auditing. Instead, it provides the essential external visibility needed to ensure your application boundaries and security header policies align with enterprise defense standards.

Sources

• Original reporting: https://thehackernews.com/2026/11/hackers-steal-about-27-million-from.html