This Week in Cybersecurity: A $6.3 Billion Binance Heist, Hijacked Update Channels, and an Exploited WordPress Flaw

Explore this content with AI:

ChatGPT | Perplexity | Claude | Google AI Mode

North Korea-linked hackers drained about $6.3 billion from Binance's hot wallets after a recruiter-style lure compromised an engineer

Attackers stole roughly $6.3 billion in digital assets from Binance's hot wallets on October 29, and the FBI said on October 31 that North Korea was responsible, tying the theft to the group it tracks as TraderTraitor. ITV News reports that TraderTraitor is the same actor the FBI linked to last year's $1.5 billion Bybit hack, that the stolen assets were mainly converted into Ethereum, and that the FBI expects laundering through DeFi and instant swap services. Binance put the impact at about $6.34 billion in its November 3 initial findings, and StepSecurity's analysis of those findings says about $2.85 billion was frozen or intercepted.

The path in was an engineer's workstation, not Binance's blockchain. According to Binance's findings, as summarized by StepSecurity, an engineer was approached through a legitimate recruitment platform in September and ran a coding assignment repository on a work computer, which replaced a development tool component and contacted an external server without endpoint protection catching it. On October 20, the attacker used that machine and an internal AI tool to take over two more engineers' computers, and on October 29 deployed a container using a token found on one of them and reached the internal wallet signing service, which submitted transactions outside the normal withdrawal process. Binance says it will absorb the losses and that it had replenished 98% of impacted token assets as of October 31, meaning it replaced assets, not that the stolen funds came back. These findings haven't been independently verified, and the investigation is ongoing.

Why it matters: the attack ran through ordinary developer habits. Treat a coding assignment, a new repository, or a "quick test" from an outside party as privileged code, and run it only in a disposable environment with no production credentials or SSO sessions. Treat internal AI tools as systems that can execute actions, with per-target authorization and logging of who asked for what; keep deployment tokens off developer laptops in favor of short-lived credentials; and make sure your detection can spot a trusted tool, like a version manager, being quietly replaced.

Read more at Euronews

Hijacked update channels pushed an SSH backdoor through Cursor's marketplace and a Linux hosting security tool

On October 29, a tampered version of the Claude Code extension was live on Cursor's extension marketplace for about 11 hours, from roughly 2:27 am to 1:35 pm PDT. The Hacker News reports that versions 2.1.312 and 2.1.313 were published under Anthropic's legitimate extension ID with a malicious loader added to the main script, and that Cursor says at most 5,000 users were affected. The loader adds an attacker-controlled SSH key labeled "svc-telemetry," opens a reverse tunnel to an attacker-controlled server, sets up persistence, and sends host details, including the names of environment variables that look like secrets. Anthropic says its own systems weren't compromised and that its official channels, including the VS Code Marketplace and Open VSX, weren't affected; how the attacker published to Cursor's marketplace hasn't been explained.

A second update channel was hijacked days later. Attackers used compromised credentials to reach the update infrastructure for cPGuard, a Linux server security product from OpsShield, starting around 2:06 am UTC on November 2, and pushed a malicious script in versions 5.88.12 through 5.88.19. The Hacker Wire reports that the script collected password hashes, database configuration files, root shell history, and SSH key files, and that OpsShield caught it within 12 hours and fixed the problem in version 5.88.25 or later. OpsShield told BleepingComputer it detected 2,946 affected servers, which puts the impact at nearly 3,000 servers. No threat actor has been named for either incident.

Why it matters: a security tool or developer extension that updates itself is trusted software with broad access, so a hijacked update lands with full privileges. If any developer installed or auto-updated the extension from Cursor's marketplace on October 29, check for the "svc-telemetry" key and the persistence entries, remove them, and rotate credentials; removing the extension doesn't clean up files it wrote elsewhere. For cPGuard, update, then reset local passwords, rotate database credentials, and replace root SSH keys, since the update alone doesn't invalidate what was stolen. More broadly, hold new versions of auto-updating tools briefly before they reach production servers and laptops.

Read more at StepSecurity

Attackers exploit a WordPress Core flaw that appears during upgrades, and CISA adds it to the KEV catalog

CISA added CVE-2026-119977, a race condition in how WordPress Core unpacks a full-package update, to its Known Exploited Vulnerabilities (KEV) catalog on November 3, with a November 6 deadline for federal civilian agencies. The Hacker News reports that the flaw is rated CVSS 8.1, comes from predictable, web-accessible staging paths used during a core upgrade, and lets an unauthenticated attacker run code if they win a narrow window while WordPress is mid-update. Wordfence reported tens of thousands of attack attempts in the days after disclosure, with attackers polling for staged installer files such as setup-config.php.

WordPress fixed the flaw in version 7.1.4 on October 28, and WordPress.org says the fix was backported to every branch still eligible for security fixes, currently through 4.7, with sites that have automatic background updates turning on updating themselves. Affected versions run from 4.7 through 7.1.3. As of the first reports on October 30, no confirmed compromises had been described, only blocked attempts and probing.

Why it matters: the exposure lasts only while an upgrade is running, which makes the update itself the moment to protect. Update to 7.1.4 (or the backported release for your branch) right away, confirm automatic updates actually ran on every site you manage, including staging and agency-hosted sites, and look for unexpected requests to PHP files under wp-content/upgrade as well as unfamiliar administrator accounts, plugins, or PHP files.

Read more at The Hacker News

Russia-linked APT29 turned patched iPhone and Chrome flaws into watering hole attacks, and CISA adds an Apple bug to KEV

Sekoia published research on November 4 describing a campaign that, it assesses with moderate-to-high confidence, was run by APT29, also tracked as Midnight Blizzard and Cozy Bear. Infosecurity Magazine reports that visitors were fingerprinted and served exploit chains matched to their devices through three routes: scripts injected into legitimate websites, lookalike domains that proxied real sites, and a week-long compromise of Plerdy, a Ukrainian website analytics tracker, from August 27 to September 3. Targets included a Ukrainian gas producer, Ukrainian and Bulgarian military-related sites, and a US chemical-industry trade association, and the payloads stole cookies, device data, and Wi-Fi passwords without installing anything persistent.
 
Every exploit in the campaign targeted a flaw that had already been patched, covering iOS 16.7, iOS 18.5, and Chrome 139 to 145 on Android (excluding 143). Sekoia's conclusion is that a user on an up-to-date operating system is safe from these attacks. CISA added one of the flaws, CVE-2024-27834, an Apple pointer authentication bypass rated CVSS 5.5, to its KEV catalog on November 4 with a November 18 deadline for federal agencies.
 
Why it matters: this is a case where a modest severity score undersold the risk. A medium-rated flaw can be the key piece in a chain, so patch delays on phones are an exposure, not a convenience. Enforce minimum iOS and Android versions through device management, keep Chrome current on managed phones, and review the third-party scripts your own websites load, because a compromised analytics tracker reaches everyone who visits.

Read more at The Hacker News

Breaches at a dozen AI developer platforms show how quickly stolen AI keys get put to work

Wiz's "Black October" report counted at least nine AI developer platforms that disclosed incidents in October, including Fireworks AI, Railway, OpenCode, Warp, and Northflank, and SecurityWeek reports that the count has grown to at least a dozen with WorkOS, Trigger.dev, CommandCode, and Chainstack. The attackers appear to be hunting stored secrets, especially the environment variables that hold AI access keys. WorkOS says an internal sales application was compromised, exposing business contact details and summaries of customer communications; Chainstack says a customer database with account names, member emails, and password hashes was accessed, and that node credentials may have been exposed.

Speed is the pattern worth noticing. Wiz found that in two enterprise cases, the first unauthorized use of a stolen key came within 30 minutes of the credential access, followed by about 800,000 calls over roughly 30 hours in one case and about 1.7 million calls over roughly 13 hours in the other, an estimated $100,000 or more at list price. Wiz sees signs that the same keys were circulating among several actors, consistent with a resale market for stolen AI credentials. SecurityWeek reports that Chainstack and WorkOS were both hit with ARTEX, the AI penetration testing framework we covered last week, though the incidents appear unrelated and attribution isn't established.

Why it matters: an environment variable on a hosting platform is a credential with a bill attached. Rotate keys the moment a platform you use discloses an incident, scope AI provider keys to the narrowest models and regions you need (Wiz found a tightly scoped key was mostly throttled), set spending alerts and quotas, and watch AI provider logs for calls from unfamiliar addresses. Ask the platforms you rely on how they store and encrypt secrets, and how quickly they notify you.

Read more at BleepingComputer

Final thoughts

This week's stories share one weakness: trust that went unchecked. A recruiter's coding assignment, a marketplace and an update server that devices installed from automatically, a WordPress upgrade folder, a trusted website's analytics script, and the secrets stored on a hosting platform each opened a door that defenders weren't watching. In most cases, the fix existed, or the warning came quickly; and the gap was how long it took to act on it.

If there's one action item, it's to list the trusted paths into your environment, such as auto-updating tools, outside code your developers run, third-party scripts, and platform-stored secrets, then ask what would happen if each one turned hostile today. Slow-roll updates to the tools with the most access, keep production credentials off machines that run outside code, and rotate secrets the moment a vendor discloses a problem.

Check back next Thursday for the next edition of This Week in Cybersecurity.