DebugBear said attackers hijacked its DNS infrastructure and used it to serve malicious JavaScript through the company’s Real User Monitoring script. The company told customers to remove its Core Web Vitals monitoring script, and reports cited by Search Engine Journal say site owners should also review exposed accounts and check for unauthorised changes.

What happened

According to the report, the incident affected websites that had embedded DebugBear’s Real User Monitoring script. Because the script loads from a third-party service, a compromise at provider level could allow malicious code to run in visitors’ browsers on affected sites.

This type of incident is a website supply-chain attack: instead of breaching each website individually, attackers target a service trusted by many sites and use that trust to distribute harmful code more widely.

Why it matters for European businesses

Many European companies rely on external scripts for analytics, performance monitoring, consent tools, chat, marketing tags and A/B testing. These services are operationally useful, but they also create dependencies that can affect website security, customer trust and regulatory exposure.

If a third-party script is compromised, the impact can go beyond temporary website issues. Depending on what the script does, risks may include:

• malicious code executing in user browsers
• unauthorised changes to website content or behaviour
• session theft or credential harvesting
• tampering with analytics or marketing data
• possible exposure of personal data, depending on the script’s access and behaviour

For e-commerce businesses, this can directly affect checkout flows, conversion rates and brand reputation. For regulated organisations, it may also trigger internal incident response and legal review obligations.

Who may be affected

The most immediate risk applies to organisations that used the affected DebugBear monitoring script on public-facing websites. However, the broader lesson is relevant to any company that uses externally hosted JavaScript from performance, marketing or analytics vendors.

Groups likely to care most include:

• SMEs and founders that depend on website plugins and scripts without dedicated security review
• Marketing and e-commerce teams using multiple third-party tags across landing pages and storefronts
• IT and web teams responsible for frontend performance, tag management and incident response
• Digital agencies managing websites for multiple clients with shared tooling stacks

What companies should consider

Businesses using DebugBear should follow the provider’s incident guidance and verify whether the affected script was present on their sites. More generally, companies should review how much trust they place in third-party frontend code.

• Remove or disable affected scripts until the provider confirms remediation and it is safe to re-enable them.
• Review website changes for unexpected code injections, altered templates, modified tag manager settings or unusual redirects.
• Check accounts and access linked to website administration, DNS, tag managers, hosting and analytics tools for suspicious activity.
• Audit third-party JavaScript to identify which vendors run code in the browser and whether all of them are still necessary.
• Strengthen change monitoring for website files, tags and DNS settings so unauthorised changes are detected faster.
• Prepare an incident workflow covering web, marketing, IT and legal stakeholders when customer-facing scripts are compromised.

For European businesses, the incident is a practical reminder that website performance and marketing tooling are also part of the cybersecurity perimeter. Third-party scripts should be treated as a security dependency, not only a convenience for analytics or optimisation.