If your website uses DebugBear’s Real User Monitoring product, there is a specific security alert to pass to the person who maintains it. DebugBear has asked customers to remove its monitoring embed code following a security incident. For a business in Bath or the South West, the first useful step is to establish whether that particular tool is installed.
This is about a named monitoring product. It is not evidence that every slow website, analytics tag or local business site has been compromised. Owners who do use it should arrange prompt technical attention and keep a record of what is found.
What DebugBear has said
In its initial public alert, DebugBear said it was dealing with an ongoing security incident and asked users of its Real User Monitoring product to remove the embed from their websites. Real User Monitoring, often shortened to RUM, measures performance experienced by people visiting a site.
In a follow-up statement, the company said its DNS server records had been compromised through its domain registrar. DNS is the system that directs a domain name to the server that should answer it. A problem there can affect where a browser goes to collect a website resource.
DebugBear said its initial investigation pointed to an attack targeting one particular customer’s website. It said it had seen no indication that its internal systems were compromised, while stressing that investigation continued. Those are the company’s preliminary findings, not an independent assurance that every other customer was unaffected.
The same update said the company could not receive email sent to its domain. Treat that as a statement made during the incident; it does not establish the current position of every support route. Check the vendor’s verified public updates before relying on a contact method or deciding that the incident is over.
Why a small monitoring tag matters
A website may include code supplied by several outside services: performance monitoring, analytics, booking tools or customer chat. The business owner may rarely see these additions because an agency, developer or previous supplier installed them.
That makes a simple inventory useful. A script running in a visitor’s browser is more than a picture on the page. Depending on how the site works and the access available, malicious code can interfere with what a visitor does. The practical question is which external code your pages load and who is responsible for checking it.
A Somerset shop, for example, might have performance monitoring installed alongside its checkout. That is an illustration of why ownership matters, not a claim that a local retailer has been affected. There is no basis in these statements for assuming a particular Bath business lost data or suffered unauthorised transactions.
What to ask your website supplier
Send the vendor’s original alert to your developer or maintenance provider and ask for a clear answer to these questions:
- Do we use this product? Ask them to check the live site, templates, plugins and tag manager, rather than relying only on an old list of subscriptions.
- Has the affected embed been removed? If it is present, ask them to follow the vendor’s removal instruction, account for cached copies and verify that live pages no longer request it.
- What needs investigation? A qualified technical or security team should assess the period of exposure and any evidence of unexpected account activity or website changes.
- What is the next decision? Get a named person, a written status and a time for the next check. Reinstallation should follow verified vendor guidance and the team’s assessment.
Removing a tag stops future loads from that installation; it does not by itself prove that earlier activity was harmless or undo unauthorised changes. If investigation finds a compromise, get appropriate incident-response help. Decisions about accounts, sessions, credentials and customer communications should follow the actual exposure, with specialist advice where needed.
Keep security and search reporting in perspective
Performance tools can support practical website and SEO checks, but a monitoring gap is not a reason to leave an affected script running. Record when it was removed so the resulting break in performance data can be explained later.
For organisations that do not use DebugBear RUM, this alert offers a quieter housekeeping task: ask for a current list of third-party scripts and the person responsible for each. That is useful maintenance without assuming your site was involved. For affected users, the immediate priority remains the vendor’s specific instruction and a properly checked response.