Polymarket Hack: $2.73M Drained From 737 Accounts

Polymarket Hack: $2.73M Drained From 737 Accounts

Key Points

  • Bitquery reckons that at least $2.73 million was chucked out of 737 accounts via 985 withdrawals within an hour.
  • Every single withdrawal had a valid on-chain approval, but we still have no idea who or what was behind all those approvals.
  • Polymarket promised refunds but that 30 October deadline came and went without any sign of payments.

A suspiciously speedy website performance tool is being talked up as the likely perpetrator behind a $2.73 million Polymarket heist. On October 29th, hundreds of accounts were cleaned out in just an hour. Now, every withdrawal had a valid on-chain approval but the identity of whoever (or whatever) gave those approvals is still a complete mystery.

Polymarket switched its international exchange to ‘cancel only’ mode around 2:05 p.m. ET, and trading resumed a short while after 3 p.m. Bitquery’s records put the first theft at 1:10 p.m. ET, a whole hour before the restriction kicked in.

Polymarket promised to put things right, saying “we’ll make this right and are fully reimbursing all affected traders”. But so far they haven’t released their own numbers or final estimate of losses.

Different Investigators Come Up With Different Loss Figures

Bitquery’s on-chain investigation reckons that at least $2.73 million was lost across 737 accounts, all thanks to 985 withdrawals in an hour.

Now that’s a minimum because Bitquery only counted the cash that went to one of the attacker’s accounts and also identified prediction shares taken from 33 accounts, but at this point, we don’t know the monetary value of those. Their chart gives us a rough idea of 713 wallets that used the main withdrawal route, rather than all 737 accounts affected. These figures will be useful, but should not be taken as identical.

The way the losses broke down was all over the place. Most accounts lost between $100 and $1,000 but 270 accounts lost less than $100 and 130 accounts lost between $1,000 and $10,000, while 4 accounts lost over $100,000 each, which accounts for 43% of the total cash lost. Another 276 accounts lost under $100.

Other sleuths have come up with similar numbers but using entirely different methods. CNBC cited Betting Intelligence and Polysights for an estimate of at least $2.7 million lost across 710 wallets; that was a separate calculation based on public data.

Arkham data was cited by The Block showing a suspected attacker wallet with around $2.65 million in POL, but that’s not even the total amount stolen, it’s just what that particular wallet was holding at the time. Wired reported that Bubblemaps reckoned around 700 victims and $2.7 million in losses.

Suspicion Falls on DebugBear

A source familiar with the matter informed CNBC that the investigation points towards DebugBear, which is a United Kingdom-based website performance monitoring company. As per Polymarket’s statement, there was an external service that got hacked; however, they refused to disclose the name of the company.

DebugBear confirmed an “ongoing security incident”. They asked the customers who are using its real user monitoring product to get rid of the embedded code from their website. Gizmodo also reported that DebugBear’s website was down earlier that night.

Technical analysis by Hudson Rock looked into the file containing the malicious code. However, the file was hosted at the DebugBear delivery address, though the hostname does not tell anything about the perpetrator.

This code was meant to extract account details from browser storage and find out whether there is an active trading client along with the signer of the transaction. Depending on the type of account, it will transfer position tokens or sell positions and move the funds.

Hudson Rock has not executed the script; hence, the findings only reveal what the code was supposed to do. There was also a balance check in which a particular value was compared with the same value. In such cases, the code will not complete the intended actions.

Thus far, there has been no transfer from the victims’ wallet to the recipients’ address due to the use of this code. As per PolygonScan, there was approximately $2.19 million at the fallback address of the script. However, this amount is not confirmed to be the total funds stolen.

Hudson Rock has not found any mechanism through which passwords, seed phrases, or private keys were sent to the reporting endpoint in the code. It is important to note here that in case of an existing browser session, an attacker might be able to transfer the funds without knowing the password.

Explanation of the problem as per Bitquery, “The chain shows they were valid, but it cannot show who made them.”

As per the investigation by Bitquery, there could be two possible explanations. First, there could be some malicious code on the polymarket.com website that prompted users to approve the transfer; second, an access key leak by a vendor could take place. While Polymarket accused an outside party, Bitquery rates the explanation as “Fits, not proven.”

Funds Vanished Quickly, but One Withdrawal Showed Up Later

By the time a trader raised the alarm on X at 1:45 p.m. ET, about 48 per cent of the money had already gone missing.

By 3:49 p.m. ET, roughly $2.17 million, or some 80% of the funds, was left on Polygon, according to Bitquery. At that point, just under $433,000 of the loot had been shifted through to Ethereum.

When cash is kept on one blockchain, it’s much easier to keep an eye on, which can certainly help with the recovery efforts. The suspected attacker’s wallet also got into some frantic activity with the USDC.e and POL through Relay, The Block reported, again and again.

One withdrawal that came a bit later really caught everyone’s attention, a loss of $10.99 from an account at 3:11 p.m. ET, just 38 minutes after Polymarket claimed they had fixed the problem that had caused the whole mess in the first place.

Bitquery did some digging and found out that this particular account had already been drained before, and they couldn’t find any other late withdrawal before 3:49 p.m. ET. The investigation doesn’t seem to think that Polymarket’s claim that the cause had been fixed is worth believing just yet.

Refund Promise Raises Questions About Larger Claims

Polymarket reached out to their users on Discord, telling them that anyone who lost less than $10,000 would get a refund by October 30th, no questions asked.

But with that deadline long gone, nobody seems to know if the promised refunds actually went out. None of the reports I looked at said anything about whether payments were made.

For those users who lost more than $10,000, things get a lot more complicated. They have to sign this release form, but the wording on that document is nowhere to be found in the coverage I reviewed.

Surprisingly, only 37 out of 713 wallets shown in Bitquery’s chart had losses over $10,000, and that’s where nearly 82% of the total dollar losses lie.

June’s Breach Shared Some Similarities, but the Code was Different This Time

Polymarket had another security issue pop up on June 25th. They blamed a third-party vendor, saying that some malicious code had been snuck into their website.

Polymarket said that they had yanked the affected dependency and promised to refund anyone who had been affected. PeckShield reckons that around $3 million was nicked, but they said it was just a phishing scam.

Bubblemaps only counted a handful of affected accounts, less than 15, to be exact. Polymarket wasn’t willing to say how many users were actually affected at the time.

The Defiant dug up some interesting info, it seems that a hidden script was used to get users to approve wallet transactions during the June incident. This latest code, on the other hand, was designed to use active trading sessions as a way to get users to authorise wallet activity.

Midterm Trading is About to Put a lot of Pressure on Polymarket

Polymarket’s international exchange is based on Polygon and operates outside US regulation, which is a bit of a worry. Their separate US platform, on the other hand, is regulated at the federal level and wasn’t touched in the October incident.

Both platforms are expecting a lot more trading in the run-up to the November 3rd midterm elections. Reuters reported that there’s growing interest from financial institutions in getting in on event-driven trading.

NBC News says that Polymarket handles around $200 million in trading activity every single day. A $1 billion funding round led by 1789 Capital, with Donald Trump Jr. as a partner, valued the company at a whopping $21 billion.

Hudson Rock’s Recommendations to Potentially Affected Users

Hudson Rock recommends rejecting all unexpected signing prompts, even if appearing on familiar websites.

Close all exposed browser tabs and check your orders and wallet transaction history on a fresh session. Users should save their transaction hashes and timestamps as evidence.

Disconnecting a wallet will not revert already processed transactions or cancel existing approvals recorded on-chain. They should also reject any unsolicited recovery links and never share their seed phrases.

Expert Analysis: Refunds Don’t Solve the Security Problem

There was a fifty-five-minute gap between the first report of funds being stolen and Polymarket turning the cancel-only mode on. We want to know what security monitoring the platform itself found during those fifty-five minutes. The trader who reported a security issue on X had almost 50% of losses already suffered.

Defenders may argue the trading pause, the full refund Polymarket promises, and the fact that its US site wasn’t compromised at all. These arguments can be valid, and Polymarket deserves credit for its intention to compensate for the losses suffered.

The timing still needs to be explained. According to the build history, Polymarket had removed the DebugBear script from its web application at 1:59 p.m. ET, 49 minutes after the first reported theft. Hudson Rock has noted that this timestamp does not provide the whole window of exposure.

Our main issue here is the use of third-party scripts on pages where traders access their trading accounts and approve transactions. Hudson Rock recommends removing unnecessary third-party scripts from authenticated trading flows.

Both incidents happened because of the presence of third-party code executing on the page where traders were signing their wallet transactions. In our opinion, a platform worth $21B should give some public information about how the scripts appeared and why no checks were performed.

Polymarket’s official statement didn’t mention the vendor, and users don’t know what software could access the trading environment. Users whose losses are more than $10,000 also need information about refund conditions. They constitute only a fraction of the affected wallets but suffer most of the total losses.