Two Major Cybersecurity Incidents in October 2026: The Binance Breach and the Malicious Cursor…

From unauthorized cryptocurrency withdrawals to an SSH backdoor hidden inside a trusted developer extension — two real incidents that reveal how attackers can abuse trusted systems.

Two independent cybersecurity incidents from October 2026: the Binance hot-wallet breach and the malicious Cursor extension. No shared attacker or connection between these incidents has been established.

Introduction

October 2026 brought two major cybersecurity incidents involving very different targets.

On 29 October, Binance reported unauthorized withdrawals involving approximately $6.3 billion worth of cryptocurrency assets from its hot wallets.

Around the same time, a malicious Claude Code-branded extension appeared in the Cursor extension marketplace. The modified extension attempted to install an unauthorized SSH key, establish a reverse SSH tunnel and maintain persistence on developer computers.

At first, these incidents may seem unrelated.

One involved financial infrastructure and cryptocurrency transactions. The other targeted developer workstations through a trusted software distribution channel.

However, both highlight an important security problem: attackers can abuse trusted systems, identities and software to gain access that organizations expect to be protected.

This article examines both incidents, explains their reported attack chains, looks at how the affected organizations responded, and explores what SOC analysts and security teams can learn from them.

PART 1 — THE BINANCE SECURITY INCIDENT

1. What happened at Binance?

On 29 October 2026, Binance reported a major security incident involving its cryptocurrency hot wallets.

According to its security update, the incident occurred at approximately 20:05 UTC and resulted in unauthorized withdrawals involving around $6.3 billion worth of token assets.

Binance also reported that approximately $3 billion had been frozen on-chain through cooperation with blockchain partners, token issuers and other organizations.

Its initial investigation suggested that a DevOps engineer's laptop might have been compromised. According to the initial statement, this could have allowed an attacker to access an internal service container and submit unauthorized withdrawal transactions.

However, Binance later confirmed that its investigation had uncovered additional points of breach.

This distinction matters: the initial laptop explanation was not the complete confirmed root cause.

Sources:

Binance Initial Security Incident Update

Binance Security Incident Update #2

2. Understanding cryptocurrency exchange withdrawals

Before looking at the attack, it helps to understand how cryptocurrency exchanges generally process withdrawals.

Most exchanges use two main types of wallets.

Cold wallets: These keep private keys offline or under highly restricted access. They are generally used for long-term asset storage.

Hot wallets: These remain connected to online infrastructure and are used to process operational withdrawals.

A typical withdrawal process involves six stages:

A customer submits a withdrawal request.
The exchange performs risk and fraud checks.
The request passes transaction authorization.
A signing service creates a digital signature.
The signed transaction is broadcast to the blockchain.
The transaction receives blockchain confirmation.

The authorization and signing stages are particularly important.

Even when private keys remain protected, an attacker who can influence which transactions are authorized may still cause serious financial damage.

3. How the Binance incident unfolded

The public investigation provides evidence of unusual withdrawal activity across multiple blockchain networks.

Binance identified the compromise at approximately 20:05 UTC on 29 October. Independent blockchain researchers traced transactions beginning around 20:04 UTC and continuing until approximately 23:56 UTC.

Their analysis covered 17 hot wallets across multiple blockchain networks. The exact number of networks differs between research reports because their coverage and methodology were not identical.

Stage 1 — Suspected endpoint compromise

Binance initially described a possible compromise of a DevOps engineer's laptop.

Its statement suggested that this may have provided access to an internal service container.

The exact initial infection method remains unknown.

There is not enough public evidence to say that the incident began with phishing, a specific malware family or a particular software vulnerability.

Stage 2 — Internal service access

According to Binance's initial statement, the attacker reached a service container that could submit withdrawal transactions.

This raised an important security question: how could access to an internal service lead to unauthorized financial activity?

Binance has not publicly explained the complete permission and authorization path.

Stage 3 — Unauthorized withdrawals

Blockchain researchers documented outgoing transactions from Binance hot wallets carrying valid signatures.

Independent analysis also identified unusual Ethereum activity involving EIP-7702 authorization.

In simple terms, EIP-7702 allows an externally owned account to authorize delegated code execution. Researchers reported that this mechanism was used in the Ethereum part of the incident to direct wallet execution.

Binance's CEO later stated that the Ethereum delegation did not pass through the exchange's normal approval controls.

This is an important technical finding, but it does not explain the complete initial-access method or every affected blockchain.

Binance also stated that it had found no evidence of wallet private-key leakage.

Stage 4 — Movement across blockchain networks

After the withdrawals, assets moved to newly created destination addresses across several networks.

Some stablecoins were frozen by issuers, while other assets were moved or converted.

Stage 5 — Investigation and response

Binance suspended withdrawals, investigated affected infrastructure, revoked affected authorizations and coordinated with blockchain intelligence providers and other industry organizations.

The visual below summarizes the publicly reported attack sequence. The initial endpoint compromise remains a suspected entry point, not an established complete root cause.

4. Following the money: blockchain investigation

One of the most important parts of this incident was tracking where the affected assets moved.

Blockchain researchers used transaction records to identify destination wallets, follow asset movements and monitor responses from stablecoin issuers.

TRM Labs published an estimate of approximately $6.36 billion across its investigated scope. Bitquery reported approximately $6.32 billion across nine networks. Other estimates differed because of valuation times and network coverage.

The approximate distribution reported by TRM included:

Ethereum: $3.79 billion.
Bitcoin: $1.47 billion.
TRON: $628 million.
XRP Ledger: $296 million.
Solana: $96 million.
Arbitrum, Optimism and Base: approximately $39 million.
Avalanche: approximately $28 million.
Polygon: approximately $10 million.

These are independent research estimates, not separate official Binance loss figures.

What happened to the funds?

Researchers observed transfers to fresh destination addresses with little or no previous activity.

The investigation also identified attempts to move or convert stablecoins before issuer freezes could take effect.

Tether, Circle and other organizations took action against assets within their control.

Binance reported approximately $3 billion frozen on-chain in its 30 October update.

An important distinction: frozen assets are not automatically recovered assets.

A frozen balance may become immobile, but its return requires the relevant legal and operational processes. Similarly, the amount of stolen assets that remains under observation on-chain is not necessarily the same as the amount that has been recovered.

5. Binance's recovery update: what changed on 31 October?

Binance published a further recovery update on 31 October.

It said that the amount of affected assets covered through its reserves and replenishment efforts had increased from approximately 80% to 90%.

According to the update, ten major affected tokens — BTC, ETH, USDT, BNB, SOL, USDC, XRP, USD1, RLUSD and ZEC — were fully backed by reserves.

Binance said the remaining 10% consisted of other, less-liquid tokens that could take longer to acquire through market and over-the-counter purchases.

The company stated that its replenishment efforts involved:

A partial deployment of the Secure Asset Fund for Users (SAFU).
A portion of its Futures Insurance Fund.
Binance's corporate treasury.

Binance also published a new Proof of Reserves snapshot dated 31 October 2026 at 00:00 UTC. It said the full zero-knowledge proof would take approximately 40–50 hours to generate and was expected around 3 November.

The company also said it remained on track to resume withdrawals on Sunday, 1 November, subject to its security checks and further confirmation.

These recovery figures need to be understood carefully.

Replenishing customer assets is not the same as recovering the stolen cryptocurrency. Binance's coverage commitment and the amount of funds frozen on-chain measure different things.

Source: Binance Recovery Update #3–90% of Affected Assets Replenished

6. What SOC analysts can learn from Binance

This incident demonstrates why monitoring wallet balances alone is not enough.

A cryptocurrency exchange security team should investigate multiple sources of evidence together.

Endpoint monitoring: Investigate suspicious activity on privileged engineering workstations.

Identity monitoring: Look for unusual administrator sessions, privileged access and service-account activity.

Container monitoring: Review container execution, access events, workload identities and configuration changes.

Transaction monitoring: Detect unusual withdrawal volumes, unfamiliar destinations and unexpected authorization activity.

Blockchain monitoring: Track suspicious transfers and coordinate with blockchain intelligence providers.

Incident response: Preserve evidence, restrict affected authorization paths, revoke exposed credentials and validate recovery.

A suggested response sequence is shown below.

PART 2 — THE MALICIOUS CLAUDE CODE EXTENSION ON CURSOR

7. What happened in the Cursor marketplace?

On 29 October 2026, malicious versions of the Claude Code-branded extension appeared in the Cursor extension marketplace.

The affected extension identifier was:

anthropic.claude-code

The reported malicious versions were:

2.1.312
2.1.313

According to Cursor's security notice, these versions were available from approximately 2:27 AM to 1:35 PM Pacific Daylight Time on 29 October.

That represents approximately 11 hours and 8 minutes.

Converted to UTC, the reported exposure window was approximately 09:27–20:35 UTC on 29 October.

Cursor stated that the incident may have reached up to 5,000 users. This is an exposure estimate, not a confirmed count of compromised computers.

Microsoft published its technical analysis on 30 October.

Another important clarification: Anthropic did not develop the malicious extension. Microsoft confirmed that the affected packages were not distributed through Microsoft's Visual Studio Marketplace or the official npm distribution, and that Anthropic's systems were not compromised.

Sources:

Cursor Official Security Notice

Microsoft Security Research

8. How a trusted developer extension became malicious

Cursor is an AI-assisted code editor that supports VS Code-compatible extensions.

Developers install extensions to add functionality to their development environment.

These extensions can execute code, access files, start processes and communicate over the network using the permissions of the editor's extension host.

In this incident, the malicious package appeared with the expected extension identifier inside the Cursor marketplace.

The affected versions were distributed through the normal extension-update process.

This meant that users could receive the modified extension without manually downloading a suspicious file or running an unfamiliar command.

9. Inside the malicious extension attack chain

Microsoft's analysis identified injected JavaScript that executed before the extension's normal initialization.

This meant that malicious code could run when the extension loaded, without requiring the developer to execute a particular Claude Code command.

The investigation identified several stages.

Stage 1 — Host reconnaissance

The extension collected system information, including:

Computer hostname.
Username.
Operating system.
CPU architecture.
Home and working directories.
Git email address.
Public IP information.
Selected environment-variable names.

An important technical detail: the initial information beacon collected matching environment-variable names, not their corresponding secret values.

For example, knowing that a variable named GITHUB_TOKEN exists tells an attacker that a potentially valuable credential may be present. It does not prove that the token itself was stolen.

Stage 2 — Unauthorized SSH key installation

The malicious code attempted to add an attacker-controlled public key to the user's SSH authorized_keys file.

The key used the comment:

svc-telemetry

This name was designed to resemble a legitimate monitoring service.

Adding an unauthorized public key creates a potential authentication path for someone holding the corresponding private key, provided the SSH service and configuration allow it.

However, the presence of the key does not by itself prove that an attacker successfully logged in.

Stage 3 — Reverse SSH tunnel attempt

The extension attempted to establish an outbound reverse SSH tunnel to:

134[.]209[.]82[.]225

The connection used TCP port 22.

The purpose was to create a possible remote-access path back to the developer's computer.

Stage 4 — Persistence

The malicious extension also attempted to maintain its presence after a system restart.

On macOS, the investigation identified a LaunchAgent.

On Windows, the investigation identified a scheduled task named:

SysMon

Additional scripts and configuration files were used to maintain the attempted tunnel and persistence behaviour.

Stage 5 — Information reporting

The extension attempted to report collected host information through:

hxxp://134[.]209[.]82[.]225:8099/beacon

Cursor later worked with its hosting provider to take the attacker server offline.

The full sequence is summarized below.

10. Windows and macOS persistence

One of the most important findings was the use of operating-system persistence mechanisms.

The extension used different techniques depending on the affected platform.

macOS

The investigation identified:

~/Library/LaunchAgents/com.apple.sysmond.plist

It also identified related files:

~/.config/.smt
~/.config/.smtk
Temporary .stk_ files.

The LaunchAgent was configured to start the relevant script and keep the process running.

Windows

The investigation identified:

Scheduled task: SysMon
Startup script: sysmon.cmd
%USERPROFILE%\.config\smt.cmd
%USERPROFILE%\.config\smtk
Temporary .stk_ files.

The purpose of these mechanisms was to maintain malicious SSH-related activity across restarts.

The important lesson is that legitimate-looking names do not make a scheduled task or LaunchAgent safe.

Analysts should examine what the object executes, which account runs it, and whether the activity is expected.

11. What Cursor did after discovering the incident

Cursor reported several response measures:

Removed the malicious extension versions.
Temporarily shut down its extension marketplace.
Audited other marketplace extensions.
Rotated marketplace credentials.
Rebuilt and restored the marketplace.
Worked with its hosting provider to take the attacker server offline.
Published technical indicators and remediation guidance.

Microsoft also published technical findings, indicators and defensive hunting recommendations.

Cursor stated that the attacker server no longer functioned.

However, the exact method by which the malicious build was published remained unknown at the research cutoff.

The available public evidence did not establish whether a publishing account, an API token, a build system or a marketplace component was compromised.

12. SOC investigation: how to examine an affected workstation

This incident provides a practical example of how endpoint investigations should be conducted.

A SOC analyst investigating a potentially affected workstation should follow a structured process.

1. Check the extension version.

Identify whether the computer installed version 2.1.312 or 2.1.313.

2. Verify package integrity.

Compare the extension package and injected JavaScript hashes against the indicators published by Cursor and Microsoft.

3. Inspect SSH authorization.

Review authorized_keys for unauthorized keys, especially the reported svc-telemetry marker. Verify the key fingerprint rather than relying only on the comment.

4. Investigate persistence.

Review the macOS LaunchAgent and Windows scheduled task identified in the reports.

5. Investigate process activity.

Look for unexpected SSH or autossh processes started by the editor's extension host.

6. Review network activity.

Search available endpoint, DNS, proxy and firewall telemetry for the reported IP address, SSH connections and HTTP activity on port 8099.

7. Review credential exposure.

Determine which SSH keys, cloud credentials, source-control tokens and active sessions may have been accessible.

8. Remediate safely.

Preserve evidence before cleanup. Use verified remediation instructions, rotate potentially exposed credentials from a trusted device, and rebuild the endpoint when the investigation warrants it.

9. Validate recovery.

Confirm that unauthorized keys, persistence mechanisms and suspicious processes have been removed, and that the activity does not return.

PART 3 — WHAT BOTH INCIDENTS TEACH US

13. Two attacks, five common security lessons

The Binance incident involved cryptocurrency custody and transaction authorization.

The Cursor incident involved a malicious software extension and developer endpoint persistence.

Their technical attack paths were different. There is no established shared attacker, infrastructure or causal relationship.

However, both provide useful security lessons.

1. Protect privileged identities.

An engineer's workstation, service account or developer extension can have access to important systems. Apply least privilege and restrict access to sensitive services.

2. Verify software and updates.

Trusted publishers and software marketplaces still require integrity checks, controlled releases and monitoring.

3. Monitor unusual behaviour.

Watch for unauthorized transaction activity, suspicious process execution, unexpected SSH keys, unusual network connections and changes to privileged configurations.

4. Preserve evidence.

Do not immediately remove every suspicious file or restart a system without considering forensic requirements. Preserve relevant endpoint, identity, network and application logs.

5. Verify recovery.

Removing a malicious package or stopping a suspicious process does not automatically mean the incident is resolved. Validate access, credentials, persistence and system integrity.

14. Final takeaways

The Binance incident demonstrates the risks surrounding privileged infrastructure, transaction authorization and cryptocurrency custody.

The Cursor extension incident demonstrates how a trusted developer tool can become a route to unauthorized SSH access and endpoint persistence.

For SOC teams, the most important lesson is not simply to collect more alerts. It is to understand how trusted systems can be abused, correlate evidence across security layers, and determine what actually happened before declaring an incident resolved.

Trust must be verified. Access must be monitored. Evidence must be preserved. Recovery must be proven.

References

Binance incident

Cursor extension incident

Technical resources

Let's Connect

Cybersecurity is a continuous learning journey. I share practical insights on SOC operations, threat hunting, incident response and security automation.

Contents