Watch what runs, not just what you hold: Binance, Polymarket, and the case for continuous scanning

Neither of this week's two big crypto incidents involved a smart-contract bug. In both, the code holding the money did what it was told. The problem was who was giving the orders.

Late on Thursday, October 29, Binance's hot wallet sent about 18,270 BTC to a single address in 11 transactions, starting at 20:20 UTC. The coins were then split across 19 addresses (CoinDesk).

Binance's preliminary explanation points to a compromised DevOps engineer's laptop that gave the attacker access to a service container used to submit unauthorized withdrawals. The exchange says it has no evidence that any wallet's private key leaked (Crystal Intelligence).

What's been reported so far:

• Impact: Binance estimates about $6.3 billion in affected assets. That's an estimate, not a final loss figure.
• Frozen: about $3 billion has reportedly been frozen or secured with partners, per Tech Insider citing Binance. Stablecoin issuers can blacklist addresses. The bitcoin can't be frozen that way.
• Response: Binance initially suspended deposits and withdrawals. By Friday it said deposits were unaffected, while withdrawals remained suspended. Co-CEO Yi He has said Binance will cover all losses (AP, The Block).
• Attribution: TRM Labs attributes the attack to North Korea's TraderTraitor unit "with high confidence." Binance hasn't confirmed this.

How the laptop was compromised, and how long the attacker was inside, are still unknown. Binance has since said its investigation uncovered additional points of breach (AP).

The lesson from that preliminary account is that keeping private keys secret does not protect a signing service from misuse. An internal service allowed to submit withdrawals was reportedly taken over, so unauthorized requests could reach the signing layer through a trusted path. No key leak has been confirmed; the full attack path is still under investigation.

On the same day, Polymarket's international site, Polymarket.com, served a tampered copy of DebugBear's Real User Monitoring (RUM) script. DebugBear is a third-party web-performance vendor. The script checked whether the visitor was logged in, then used that live session either to sell positions or to send position tokens to an attacker wallet (BleepingComputer, SecurityWeek).

• Losses: about $2.5 million traced to the suspected attacker wallet. Other estimates range from $2.2M to $2.7M depending on the source. Those figures are not a confirmed total loss.
• Response: cancel-only mode from 2:05 PM ET. Trading came back about an hour later. Polymarket says it is fully reimbursing all affected traders but hasn't published a timeline.
• Contracts untouched: no smart-contract bug was needed; the script used permissions the victims' browsers already had.
• Not the first time: in June, a different compromised vendor injected a wallet-draining script into Polymarket's frontend, with losses of about $3M (Cyber Kendra).

DebugBear has confirmed it is "impacted by an ongoing security incident" and has told customers to remove its embed code. Polymarket has only said that "one of our third party providers was compromised" (SecurityWeek, BleepingComputer).

Wallet and on-chain monitoring is necessary, but it fires after the money moves. In both cases there was an earlier, observable change somewhere else: a new actor on internal infrastructure, or a script that no longer matched what had been reviewed.

Aeon runs security skills as scheduled agents in your own GitHub repo. A short, honest map:

What exists today

vuln-scanner audits repositories with purpose-built scanners (dataflow analysis, verified secret matching, dependency CVEs) and routes findings to the right disclosure channel: private vulnerability reports for code flaws, PRs only for already-public dependency CVEs.

Additional checks you can build as custom skills

These are proposed custom skills, rather than shipped entries in the current Aeon catalog:

• workflow-security-audit would run zizmor and actionlint over your GitHub Actions on a schedule and flag regressions. CI pipelines are a classic path from a developer laptop to production credentials.
• security-digest would filter CISA's Known Exploited Vulnerabilities (KEV) catalog and GitHub Advisories down to your actual stack, with one action per item.
• skill-security-scan would check agent skills and companion scripts for injection, exfiltration and prompt-override risks.

What it would and wouldn't have changed here

• Polymarket-style script swaps are a good fit for a scheduled check. Fetch every page, list every external script, hash it, and alert when a hash changes or a new origin appears. A file on cdn.debugbear.com changing content would show up as a diff. A scheduled site-scan skill with hash-diff alerts along these lines is in progress, not shipped.
• A scanner can be shown a clean copy while victims get the malicious one, so the stronger fix is preventive: Subresource Integrity (SRI) hashes, a strict Content-Security-Policy (CSP), and self-hosting vendor scripts that sit on authenticated pages.
• Binance-style intrusions are only partly in scope. A repo and CI scanner can shrink the blast radius: over-privileged service tokens, secrets in workflows, containers that can submit withdrawals without a second control. But a scheduled job is not endpoint detection. It won't catch a stolen laptop in real time. Use it for continuous posture checks, and pair it with endpoint detection and response (EDR) plus anomaly rules on the withdrawal path itself.

• Inventory every third-party script on authenticated pages. Anything that doesn't need to be there, like analytics or RUM on a trading UI, comes off.
• Pin what remains with SRI, or self-host it. Add a CSP that blocks unknown origins.
• Hash and diff those scripts on a schedule, and alert on any change you didn't ship.
• Map who and what can submit a withdrawal. Every service identity on that path should have the narrowest scope possible and a second, independent approval for anything unusual.
• Audit CI/CD on every change, not once a quarter. Developer machines reach production through pipelines.
• Alert on new actors, not just big amounts. A new container or token suddenly submitting withdrawals is a stronger signal than the dollar value.

Both companies say users will be made whole. The next team might not be able to. The cheapest moment to catch either attack was the first change, well before the first withdrawal.

Sources: CoinDesk, Tech Insider, TRM Labs, BleepingComputer, The Block, SecurityWeek, Cyber Kendra, Crystal Intelligence, AP.