Ing. Calogero Bono
Polymarket, the crypto-based prediction market platform, paused trading for about an hour after an attack that started from an external vendor. According to researchers at Hudson Rock, around 2.5 million dollars were stolen. The malicious code was hosted on the infrastructure of DebugBear, a service that measures website performance. The case matters even if you don't use crypto, because it shows how much a single external script added to a site can cost.
A few terms before we get into the facts. A prediction market is a platform where you bet on the outcome of real-world events. A wallet is the digital portfolio that holds cryptocurrencies. POL is the cryptocurrency of the Polygon blockchain. RUM stands for Real User Monitoring and refers to a JavaScript script that collects performance data about a site from visitors' browsers. C2 is the command and control server from which malware receives instructions.
What happened to Polymarket?
According to the Punto Informatico report, on the platform's status page the investigation began at 19.05 after relayer operations were interrupted. A «cancel-only» mode was activated, in which users can only cancel orders. About half an hour later Polymarket said it had identified and fixed the problem, but kept operations on hold as a precaution.
As reported by BleepingComputer, the company wrote that «One of our third party providers was compromised, and we have referred this to relevant law enforcement». It added that affected users will be reimbursed. Trading resumed about an hour after the first suspension.
The problem affected the international platform. According to Wired, Polymarket US, the version for the United States, was not touched. Also according to Wired, the compromised vendor is based in the United Kingdom and British authorities have been notified.
How did the malicious script work?
Hudson Rock identified a malicious JavaScript file distributed from an address on DebugBear's infrastructure. The Polymarket site loaded the script as part of the RUM service, so the code ran in users' browsers. According to Punto Informatico, when a victim logs into their account the script checks the wallet balance and sends the cryptocurrencies to the criminals.
BleepingComputer analyzed a copy of the file and describes the behavior in more detail.
- It checks whether the visitor is logged into Polymarket and tries to use the already authenticated session.
- It checks balances and positions to estimate the value of the funds.
- In some cases it tries to automatically sell positions, in others it transfers the tokens directly to an attacker's wallet.
- It tries to convert cryptocurrencies into transferable assets, exploiting the transaction functions already present on the platform.
The script also communicated with a DebugBear server to receive instructions and send data about accounts, addresses and results. For BleepingComputer, the use of the same infrastructure both for distribution and as C2 raises questions about how much access the attackers had to the company's systems.
How much was actually stolen?
The figures don't match and none has been confirmed by Polymarket. The following tally is ours, but it simply places the sources' data side by side.
- Hudson Rock reports about 28.6 million POL, worth about 2.57 million dollars, as cited by Punto Informatico and BleepingComputer.
- BleepingComputer reports that the suspicious wallet held about 2.19 million dollars at the time of Hudson Rock's investigation.
- According to Wired, the analytics firm Bubblemaps estimates about 700 users involved and about 2.7 million dollars stolen.
Polymarket, contacted by Wired, did not say how many traders were affected or how much was lost. It reiterated that it will reimburse the users concerned.
Why are third-party scripts a risk?
Because an external script runs with the same permissions as your site inside the visitor's browser. If the provider is compromised, the code changes without you touching a single line. Here the service was only meant to measure performance, but from that position it was possible to act inside authenticated sessions.
DebugBear confirmed the incident on X and, according to BleepingComputer, asked customers to remove the RUM code from their sites. In its words, «We're impacted by an ongoing security incident». Hudson Rock researchers also found a commit message from Polymarket itself, chore(polymarket) remove debugbear rum script, a sign that the integration was removed shortly before the announcement.
The theme is the same we address when discussing Italian SMEs and automated attacks. You don't need to be a multi-billion platform to have an exposed surface.
Limits to know
- Polymarket has not said how many users were affected, how much was stolen, or how the reimbursement will work.
- Polymarket did not name the vendor. DebugBear emerges from Hudson Rock's analysis and from its own confirmation.
- Times in the Italian and American sources are given in different time zones and we have not reconciled them. For this reason we stick to the figure of about one hour of suspension.
- The attackers are unknown. We don't know how they compromised DebugBear.
- BleepingComputer contacted both companies and reports no replies, so the reconstruction may change.
- Punto Informatico notes that the platform should theoretically not be accessible in Italy.
What it means for anyone working in digital
The first effect is practical. Every snippet pasted into a site, whether analytics, chat, monitoring or advertising, should be treated as code you may not control. If the site handles logins, payments or personal data, that code has access to everything the user sees.
For developers the risk is twofold. There is the security of users, and there is responsibility toward the client, who does not distinguish between their own code and a vendor's code. Online shops and management software also have pages with logins, so the logic extends well beyond crypto. Anyone running an online shop should know which scripts load on the cart and checkout pages.
Then there is speed. From removing the script to resuming operations took about an hour. A procedure already written for disconnecting a compromised vendor saves precious time.
Our take
The case is instructive because the mistake is not spectacular. A performance monitoring service seems harmless, and precisely for that reason nobody looks at it with suspicion. Yet to do its job it must run in the browser of every visitor. Looking closely, the convenience of a pasted line of code is paid for with access that few stop to assess.
Polymarket's response seems right on timing. It halted operations, removed the script and promised reimbursements. Less convincing is the communication. It did not name the vendor and did not explain how many users are involved, leaving it to Hudson Rock and Bubblemaps to do the math. Wired also recalls an earlier breach with over 2 million dollars in losses, and two similar incidents suggest a process problem rather than bad luck. For businesses the same rule applies. On perimeter security, as in other cases we have covered, the risk starts with what is taken for granted.
Frequently asked questions
Was Polymarket hacked directly?
No, according to the sources the attack came through an external vendor. Wired speaks of a compromised British vendor, not the platform's own site. The malicious code, however, ran on Polymarket's pages.
How much was stolen?
There is no official figure. Hudson Rock indicates about 2.57 million dollars, Bubblemaps about 2.7 million with about 700 users involved. Polymarket has not confirmed the numbers.
Will users be reimbursed?
Yes, according to Polymarket. The company says it will reimburse all affected traders. It has not, however, explained how the process will work.
What is DebugBear?
It is a website performance monitoring service. Its RUM product uses JavaScript to collect metrics from visitors' browsers. The company confirmed the incident and asked customers to remove the code.
How can I protect myself if my site uses external scripts?
Make an inventory of your scripts and remove those you don't need. Limit providers on pages with logins and payments. Prepare a procedure to disconnect them quickly.
What to watch in the coming months
Still to follow are the authorities' investigation, DebugBear's explanations and Polymarket's reimbursements. In the meantime you can act on three fronts.
- List every external script your site loads and ask whether it is still needed, especially in restricted areas.
- Keep servers and components up to date, including with a managed hosting with security updates, and monitor your vendors' alerts.
- Define who can remove an integration in a few minutes and how, so you don't improvise during an incident. If you have custom applications, address the topic with whoever does software development already at the project stage.
To understand how automation shifts risk, also read our in-depth piece on what an autonomous hacker means for SMEs.
