Binance Hack 2026: What TraderTraitor Teaches Exchanges and Fintechs About Developer Endpoints

On Thursday 29 October 2026 about USD 6.3 billion left Binance, by Binance's own estimate. TRM Labs says an attacker moved about USD 6.36 billion out of Binance wallets on ten blockchains, most of it in about 20 minutes starting at 20:05 UTC, and calls it the largest crypto theft on record, about four times the USD 1.5 billion taken from Bybit in February 2025. Binance's first explanation was that the incident "may have started" with a compromised DevOps engineer's laptop that gave the attacker access to a service container, which was then used to submit unauthorized withdrawal transactions. On Saturday 31 October the FBI said North Korea was responsible and named the activity "TraderTraitor."

Binance says user funds are safe and it is covering the losses with its own money. Its detailed technical post-mortem is not out yet, so nobody outside Binance and its investigators can say exactly how the money left.

What we can say is what TraderTraitor has done before, because US agencies, GitHub, incident responders and victims have published it in detail since 2022. The group goes after the people who build and run the systems: engineers, DevOps staff and developers at the vendors those companies depend on. It reaches them with fake recruiters, coding tests, trojanized apps and malicious packages, then uses the access a developer machine already has.

This post is for security, platform and engineering leaders at exchanges, custodians, payment companies and fintechs. It covers what each party has said, what is still unknown, TraderTraitor's earlier campaigns with their primary sources, and a layered checklist with configuration you can apply this week. It also says plainly where Safeguard helps and where it does not. Facts are stated as of 1 November 2026.

What happened on 29 October, in order

Figures differ by source, so each number stays with whoever published it.

NPR's explainer on 31 October put the state of knowledge plainly: a lot of details about the heist are still unclear, and researchers it spoke with said it was too early to say whether there were major flaws in Binance's security. That is the right frame for everything below.

What Binance has said

Late on 29 October. Binance said a compromised DevOps engineer's laptop may have allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions. "We have found no evidence of any wallet private key leak." It suspended deposits and withdrawals and revoked authorizations for the affected address, per BleepingComputer.

On 30 October. "Our initial investigation suggested that the security incident may have involved a compromised laptop, however our subsequent investigation has uncovered additional points of breach." Binance said it was "still gathering the facts."

Teng's description. Co-CEO Richard Teng said the attacker "did not simply use one engineer's permissions, and this was not a single 'one-click' action," and added: "Our investigation has not attributed responsibility to any individual." Reuters reported that Teng described malicious software designed to delete evidence of its activity. Decrypt reported that withdrawals stayed suspended during "a security revamp of the withdrawal service and its related addresses."

Binance has not named an attacker. It described an engineer's endpoint and a service that could submit withdrawals, with no evidence of a key leak. How those withdrawals were approved and signed is what the post-mortem must explain, and we will not guess at it.

What the FBI, TRM Labs and Chainalysis said

The FBI, 31 October. CBS News quoted the FBI's finding that "the Democratic People's Republic of Korea (North Korea) was responsible for the theft of more than $6 billion USD." The Associated Press reported that the FBI tied the attack to TraderTraitor, said the actors were mainly converting stolen assets into ether, and expects them to launder further through decentralized finance and "instant swap services." The FBI asked exchanges, analytics firms and others to block transactions linked to the addresses it listed, the same structure as its February 2025 notice on Bybit.

TRM Labs attributed the theft to TraderTraitor "with a high degree of confidence," according to BleepingComputer. Chainalysis, per the same report, confirmed TRM's findings with "a high degree of confidence." We could not find a Chainalysis post of its own on the incident as of 1 November.

TraderTraitor is the US government's name for a North Korean state-sponsored cluster. GitHub and Microsoft call overlapping activity Jade Sleet, and Mandiant has said its cluster UNC4899 "likely corresponds to TraderTraitor." Press coverage often folds all of this into "Lazarus Group." The method matters more than the name.

Where the money went: freezes, replenishment and withdrawals

Freezes. TRM said Tether, Circle, Ripple and World Liberty Financial froze about USD 2.67 billion in stablecoins, and Arbitrum's Security Council froze 8,426 ETH and 74.6 million ARB, for roughly USD 2.7 billion in total. Binance's own figure is about USD 3 billion frozen with partners.

What the attacker still holds. TRM said the attacker "raced the freezes by selling USDT to market makers and borrowing ETH against USDT on Aave," and now holds more than 420,000 ETH and 18,270 BTC, about "USD 2.4 billion in assets beyond any issuer's reach."

Replenishment is not recovery. On 31 October Teng said: "We've now replenished 90% of the stolen assets, and we're committed to covering the remaining 10%." CNBC, NBC News and CBS News all reported the 90% figure; check Binance's own channels for any later update. CNBC noted that this does not mean the funds were recovered from the attacker. Binance bought replacement tokens with money from its Secure Asset Fund for Users (SAFU), part of its Futures insurance fund and its corporate treasury, and Reuters reported that it set aside about USD 6.34 billion of company funds.

Withdrawals. Phase one began on Sunday 1 November with the Bitcoin network first, according to CNBC and Binance's post on X. crypto.news reported a 06:00 to 09:00 UTC window and selected assets across 15 networks, each subject to security checks, so not every listed route opened at once. Binance has not dated phase two. It took a new proof of reserves snapshot at 00:00 GMT on 31 October and will publish an update once remediation is complete.

Technical details: what is confirmed and what is not

The state of the technical record on 1 November:

The lessons below come from TraderTraitor's documented history and from how exchanges are built in general, not from unpublished details of this incident.

TraderTraitor's playbook, from the public record

Five public cases, each with its own primary source, show the same entry point again and again: a person with privileged technical access, reached through their professional life.

2022: fake jobs and trojanized trading apps (CISA AA22-108A)

On 18 April 2022 the FBI, CISA and the Treasury published advisory AA22-108A. It says intrusions begin "with a large number of spearphishing messages sent to employees of cryptocurrency companies," often people in system administration or software development and IT operations (DevOps). The messages "often mimic a recruitment effort and offer high-paying jobs" to get recipients to download malware-laced cryptocurrency apps: cross-platform Electron apps in JavaScript on Node.js, with names such as CryptAIS and TokenAIS, some signed with Apple developer certificates. A function presented as an "update" downloads and runs the payload. The role named in 2022, DevOps, is the role Binance named in 2026.

2023: repository invitations and malicious npm dependencies (GitHub)

On 18 July 2023 GitHub described a campaign "using a combination of repository invitations and malicious npm package dependencies" against employees at technology firms, many tied to blockchain and cryptocurrency. It attributed the campaign with high confidence to the group Microsoft calls Jade Sleet and CISA calls TraderTraitor. The actor builds fake developer or recruiter personas on GitHub, LinkedIn, Slack and Telegram, invites the target to a repository, and "convinces the target to clone and execute its contents." The malicious npm packages download and run a second stage, and the actor "often publishes their malicious packages only when they extend a fraudulent repository invitation." GitHub's advice: check your security log for action:repo.add_member events from listed accounts, and examine dependencies and installation scripts, especially very recently published packages and scripts that make network connections during installation. No GitHub or npm systems were compromised; the weak point was the developer running the code.

2023: JumpCloud, a supplier as the way in (JumpCloud and Mandiant)

JumpCloud wrote on 12 July 2023 that it traced anomalous activity to "a sophisticated spear-phishing campaign perpetrated by the threat actor on June 22." On 24 July 2023 Mandiant attributed the downstream intrusions to UNC4899, which it said "likely corresponds to TraderTraitor," and identified a malicious Ruby script executed through the JumpCloud agent at a customer on 27 June 2023. JumpCloud reported fewer than five customers and fewer than ten devices affected. Your vendors' engineers are part of your attack surface.

2024: a "pre-employment test" at a wallet vendor (FBI, via BleepingComputer)

In December 2024 the FBI attributed the May 2024 theft of 4,502.9 BTC, worth USD 308 million, from DMM Bitcoin to TraderTraitor. As BleepingComputer reported on 24 December 2024, an actor posing as a LinkedIn recruiter contacted an employee of Ginco, a Japanese enterprise wallet software company, who had access to its wallet management system. The employee received a malicious Python script framed as a pre-employment test on GitHub and copied it to a personal GitHub page, which led to the compromise. "After mid-May 2024, TraderTraitor actors exploited session cookie information to impersonate the compromised employee" and reached Ginco's unencrypted communications system, then likely manipulated a transaction request from DMM. The employee had access to a wallet management system, and the FBI's account turns on session cookie reuse.

2025: Bybit and a developer at Safe Wallet (FBI, Safe and Mandiant)

On 26 February 2025 the FBI said North Korea's TraderTraitor stole about USD 1.5 billion from Bybit on or about 21 February. Safe Wallet, whose multisignature interface Bybit used, published preliminary findings from its investigation with Mandiant; as reported by The Hacker News on 7 March 2025, Safe said the attack involved the compromise of one of its developers' laptops ("Developer1") and "the hijacking of AWS session tokens to bypass multi-factor authentication ('MFA') controls." The developer "was one of the very few personnel that had higher access," and the attacker "removed their malware and cleared Bash history." Reporting on the further analysis says the macOS machine was compromised on 4 February 2025, likely through a Docker project named "MC-Based-Stock-Invest-Simulator-main" that contacted getstockprice[.]com, and that malicious JavaScript was injected into the Safe Wallet web application between 19 and 21 February. Of the earlier cases, Bybit is the closest match to what Binance has described so far, a developer endpoint and a path to the systems that move funds. That is a comparison, not evidence that the same method was used.

Other North Korea-linked clusters

Keep the clusters apart. On 21 November 2023 Palo Alto Networks Unit 42 described "Contagious Interview," in which actors "pose as employers" to "lure software developers into installing malware through the interview process," with JavaScript malware, BeaverTail, "hidden inside Node Package Manager (NPM) packages." Unit 42 attributes it with moderate confidence to a North Korea state-sponsored actor and does not equate it with TraderTraitor. The shared technique is what matters: a coding task, a package install and a developer laptop.

Why developer endpoints are the soft target at exchanges and fintechs

Exchanges spend heavily on wallet security: cold storage, hardware security modules, multi-party computation, withdrawal review. Attackers know this. The record above shows them going around the vault to the people who maintain the machinery around it.

A senior engineer's laptop at an exchange or fintech usually holds or can reach:

• Source code and the build path. Push rights to repositories, the ability to change CI pipelines, and sometimes signing keys for releases or containers.
• Cloud consoles and APIs. SSO sessions, cached CLI credentials and long-lived tokens for AWS, Google Cloud or Azure, often with broad roles because "DevOps needs it."
• Production access. SSH or session manager access to hosts, kubectl contexts for clusters, VPN profiles and bastion access.
• Internal services that move money. Admin tools, withdrawal and treasury services, internal APIs that hot-wallet systems trust because the call comes from inside.
• Communication and approval channels. Chat, ticketing and the systems where transaction requests are raised and approved. The Ginco case went through exactly this channel.

That one machine also runs a lot of code from strangers: npm and PyPI packages, Docker images, editor and browser extensions, take-home tests and "quick look at this repo" requests. Multi-factor authentication does not help once a valid session token is sitting in a browser profile or a CLI cache, which is what both the Ginco and Safe Wallet accounts describe.

So the defensive problem has two halves. Reduce how often untrusted code runs on privileged machines. And reduce what a compromised privileged machine can do on its own, especially to systems that move funds.

A defence-in-depth checklist for exchanges and fintechs

No single control stops a state-sponsored group that is patient, well funded and willing to spend months on one target. The goal is to make each step harder, slower and louder, and to cap the loss if an attacker gets through anyway. The controls are ordered from the developer's keyboard to the hot wallet.

1. Control what packages reach developer machines and builds

Most of the earlier campaigns needed a developer to install something. Route installs through a single controlled path so you can see and stop bad packages before they land.

• Send every install through a proxy you control. A package firewall or a curated internal registry in front of npm and PyPI gives you one place to block known-malicious, typosquatted and dependency-confusion packages, and a log of what every machine fetched.
• Keep an allowlist for wallet, signing and infrastructure repositories. Anything new goes through review.
• Delay brand new versions. GitHub's 2023 alert noted that the actor published malicious packages only when sending the invitation. A minimum release age turns "published ten minutes ago" into "not installable yet." pnpm supports this directly:

# pnpm-workspace.yaml
# Refuse versions published in the last three days (value in minutes)
minimumReleaseAge: 4320
minimumReleaseAgeExclude:
  - "@your-org/*"

• Close dependency confusion. Scope internal packages and pin the scope to your internal registry, so a public package with the same name never wins:

# .npmrc (project level, committed)
@your-org:registry=https://npm.internal.example.com/

For pip, use a single index-url that points at your proxy and never add the public index as an extra-index-url, because pip treats all configured indexes as equal and picks the highest version across them.

2. Lock and verify what you install

A lockfile with integrity hashes means the bytes you install are the bytes you reviewed.

# npm: install exactly what package-lock.json says, fail if it is out of date
npm ci

# pnpm and Yarn (Berry): refuse to change the lockfile in CI
pnpm install --frozen-lockfile
yarn install --immutable

# Python: generate hashes once, then require them on every install
pip-compile --generate-hashes -o requirements.txt requirements.in
pip install --require-hashes -r requirements.txt

# uv: install from the lockfile and fail if it would change
uv sync --locked

Review lockfile diffs in pull requests like code. A new transitive dependency in a wallet service is a security event, not noise.

3. Do not let installs run code by default

Install scripts (preinstall, install, postinstall in npm, and build steps in Python source distributions) run with the developer's full permissions the moment a package lands. Turn them off by default and allow the few packages that truly need them.

# .npmrc
ignore-scripts=true

# CI, explicit form
npm ci --ignore-scripts
# then build only the packages you have reviewed
npm rebuild esbuild

Recent pnpm releases also limit dependency build scripts to an allowlist you maintain. The setting names have changed between versions, so check the build scripts section of the pnpm settings documentation for the version you run.

Yarn Berry has a global switch:

# .yarnrc.yml
enableScripts: false

For Python, prefer wheels so setup.py never runs on install:

pip install --only-binary :all: --require-hashes -r requirements.txt

Disabling scripts does not make a malicious package safe. Its code still runs when your application imports it. It does remove the easiest moment for a first-stage downloader to fire.

4. Run coding tests and unknown repositories somewhere disposable

Every case above that began with a recruiter ended with the target running code on a machine that mattered.

• A written rule. No take-home tests, interview tasks, "can you debug this" repositories or Docker projects from outside the company on a work machine.
• A disposable environment. Give engineers a one-command throwaway VM or container with no credentials, SSH keys, browser profile or VPN. Read the code first with networking off:

# Inspect an untrusted repository with no network and no host credentials
docker run --rm -it \
  --network none \
  --cap-drop ALL --security-opt no-new-privileges \
  -v "$PWD":/work:ro -w /work \
  node:22-bookworm bash

# Inside: look for install hooks before installing anything
grep -n -E '"(pre|post)?install"|"prepare"' package.json

• Editors count too. Keep VS Code Workspace Trust on, so an untrusted folder opens in Restricted Mode and its tasks do not run automatically.
• Verify the recruiter through the hiring company's own careers site or a known employee. A push to Telegram, or to run code before a real interview, is a red flag.

5. Shrink what a developer session can do

Assume a developer endpoint will be compromised one day, and ask what that session can reach without anyone else agreeing.

• Phishing-resistant MFA. FIDO2 security keys or passkeys for SSO, cloud consoles, source control and VPN. They stop credential phishing, not session theft, so pair them with the next items.
• Short sessions bound to managed devices. Hours, not days, for cloud CLI sessions. Both the Ginco and Safe Wallet accounts involve reused sessions.
• No standing production access. Just-in-time elevation for a specific task, with a second approver for anything that touches funds, expiring on its own.
• Separate admin identities and devices. The account that can change wallet infrastructure is not the one that browses, chats and runs interview code.
• No long-lived secrets on laptops. Short-lived cloud credentials per session, and source control tokens scoped to the repositories a person needs.

6. Make the money path defend itself

Binance said an attacker reached a service container that could submit withdrawal transactions and that it found no evidence of a key leak. Whatever the post-mortem shows, the general design lesson holds: the system that signs should not trust the system that asks.

• Keys in HSMs or an MPC scheme, never exportable by a service or an engineer.
• Policy enforced at the signer. Destination allowlists, per-asset and per-window value limits and velocity limits checked by the signer itself, so a compromised upstream service cannot raise its own limits.
• Quorum for anything unusual, with approvers on separate devices and at least one approval path that shares no infrastructure with the requesting service.
• Independent transaction verification. Approvers decode the raw transaction on a separate device rather than trusting a web interface. In the Bybit case, Safe said malicious JavaScript was injected into the Safe Wallet web application.
• Velocity caps sized to your response time. TRM says most of the Binance funds moved in about 20 minutes. Ask how much could leave your hot wallets before your team can press stop, and keep hot balances to a few hours of normal withdrawals.

7. Watch builds, runners and the machines that build them

• Restrict CI runner egress to your package proxy and artifact registry. Unexpected outbound connections from a runner are a strong signal.
• Separate runners by trust. Runners that build or deploy wallet services never run fork pull requests or general team jobs, and pin third-party actions to full commit SHAs.
• Keep SBOMs of what you build and the tooling you build with, so "which images and services carried this package, and when" is a query, not a week of grepping.
• Ship logs off the machine as they are written. The Safe Wallet attacker cleared Bash history, and Teng says Binance's attacker used software to delete evidence.

8. Be ready for the worst 20 minutes

• A hot wallet kill switch that one on-call person can trigger, with a tested runbook.
• Freeze contacts in advance for stablecoin issuers, chain security councils and other exchanges' security teams. TRM's account shows freezes held about USD 2.7 billion while the attacker raced them.
• An analytics partner on retainer and a way to act fast on FBI address lists.
• A tabletop that starts with "a DevOps engineer's laptop ran something it should not have."

Open questions

• How withdrawals were approved and signed. Binance has said a service container was used to submit unauthorized withdrawals and that it found no evidence of a key leak. How those transactions passed whatever approval and signing controls exist is the central unknown.
• What the "additional points of breach" were. Binance has not described them.
• How the laptop was compromised. No primary source has said whether it was a recruiter lure, a malicious package, a trojanized app or something else. TraderTraitor has used all of these before, but that does not tell us what happened here.
• How long the attacker was inside. We found no primary source for any preparation timeline.
• The final loss after freezes and tracing. Figures from TRM, Arkham, Binance and others differ and are still moving.

Binance has said it will publish a detailed technical post-mortem. When it does, the specifics in it should replace anything general in this post.

What shifts the odds

Nothing on this page would guarantee stopping a state-sponsored group that has spent four years refining one playbook against one industry. The public cases point to five things that shift the odds: fewer chances for untrusted code to run on privileged machines, less that one session can do on its own, a signer that enforces its own rules, speed after the fact, and an inventory that answers "were we exposed" in minutes when the next malicious package is named.

Where Safeguard fits, and where it does not

Safeguard is a software supply chain security platform. Some controls above are squarely what it does; many are not. Nothing here suggests Binance is or was a Safeguard customer, or that Safeguard knew of this incident before it was public.

What Safeguard does not cover here. Safeguard does not provide endpoint protection for developer laptops, does not manage wallet keys, does not sign or verify blockchain transactions and does not replace your identity provider or its session controls. Controls 5, 6 and 8 belong to those systems and to your wallet architecture.

Package Firewall: control what gets installed. Safeguard's Package Firewall runs as an install-time proxy fronting npm and pip. Because it sits on the fetch path, it sees transitive fetches too, and it can block malicious, typosquatted and dependency-confusion packages before they reach a laptop or a build. Outcomes are allow, warn and block, with an audit mode that records decisions without blocking and a quarantine mode that holds a flagged package for review. The docs describe look-alike detection, namespace confusion checks, a malware blocklist and a behavioural analyzer that inspects the archive statically without executing it. Every decision goes to the audit trail. An administrator turns it on through a feature flag, and the CLI starts a local or CI proxy:

# Local or CI proxy for npm and pip, recording decisions without blocking
safeguard pkgfw start --mode audit --port 8899

# Point npm at the proxy's npm path for this project
npm config set registry http://127.0.0.1:8899/npm/ --location=project

# One-shot check of a single package version (exit 1 on block)
safeguard pkgfw check --ecosystem npm --name left-pad --version 1.3.0

For pip, set index-url or PIP_INDEX_URL to the proxy's /pypi/ path and remove any public extra-index-url. Start in audit mode on one team, review the trail, then move to block. It does not stop a trojanized desktop app, a malicious Docker image or a script pasted from a chat.

Software composition analysis and SBOMs. Safeguard's SCA resolves the complete dependency graph from manifests and lockfiles, including deeply nested transitive dependencies, across npm, pnpm, Yarn, PyPI, Maven, Gradle, Go modules, Cargo, NuGet, Composer and Ruby Bundler, plus components inside container image layers. SBOMs export in SPDX and CycloneDX. That is the standing inventory of wallet services, build images and internal tooling you need the day a malicious package is named.

Policy gates in CI. Safeguard runs as one shell step in GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins, Azure Pipelines or any CI, and the documented flag fails the job when a gate fails (with policy outcomes enabled for your workspace):

curl -fsSL https://cli.safeguard.sh/install | bash
SAFEGUARD_API_KEY=... safeguard ci scan --wait --fail-on-gate all

With --local, the scan runs on the runner and only the results leave it. Policy conditions include severity, CVSS, EPSS, license, component age, maintenance status and SLSA level, with Block, Warn and Notify actions and an audited exception workflow.

Red Team: check that your detections fire. Safeguard's Red Team engine is defensive adversary emulation. It emits benign canaries mapped to MITRE ATT&CK techniques to show whether your monitoring alerts, runs only against verified, in-scope assets under signed rules of engagement, and never runs real exploit payloads. It tests your alerts; it does not replace endpoint protection.

Compliance evidence. Safeguard itself is SOC 2 Type I and Type II audited, with reports available on request through its Trust Center. Customers use its compliance suite to map controls and collect evidence for SOC 2 and other frameworks, which is where access reviews, change management and vendor risk get proven to auditors and regulators.

What individuals and teams can check today

If you hold crypto on an exchange: turn on the withdrawal address allowlist, use a hardware security key or passkey instead of SMS codes, and trust status updates only from the exchange's own site and verified accounts.

If you are a developer: never run a take-home test, interview repository or "quick debug" project on your work laptop, verify recruiters through the company's own careers page, and treat a request to move to Telegram or install an npm package for an interview as a warning sign.

If you run security or platform at an exchange or fintech, a ten-item check:

1. Every npm and PyPI install on developer machines and CI goes through a proxy you control.
2. Internal package scopes are pinned to the internal registry; no public extra-index-url.
3. Install scripts are off by default, with a short reviewed allowlist.
4. CI installs use frozen lockfiles, and Python installs require hashes.
5. A written ban on running external code on work machines, plus a one-command disposable environment.
6. SSO, cloud, source control and VPN use FIDO2 keys or passkeys, with short sessions.
7. No standing production or wallet infrastructure access; elevation is just-in-time with a second approver.
8. The signer enforces destination allowlists, value limits and velocity limits independently of requesting services.
9. CI runners for wallet services are isolated, egress restricted and pinned to reviewed actions.
10. A hot wallet kill switch, freeze contacts and an analytics partner sit in a runbook exercised this quarter.

Keeping the open source dependencies in your services and build tooling free of known vulnerabilities is a different problem from what drained Binance, but it sits on the same build path. The next section covers it.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

How much was stolen from Binance?

About USD 6.3 billion by Binance's estimate. TRM Labs counts about USD 6.36 billion on ten blockchains and Arkham counted USD 6.01 billion on nine, according to Decrypt. The differences come from the chains, prices and time windows each firm used.

Who did it?

The FBI said on 31 October 2026 that North Korea was responsible and named the activity TraderTraitor. TRM Labs attributes it to TraderTraitor with high confidence, and BleepingComputer reports that Chainalysis concurs. Binance has not named an attacker.

How did the attackers get in?

Binance first said a compromised DevOps engineer's laptop may have given access to a service container used to submit unauthorized withdrawals, then said it found additional points of breach. The full chain is not public until Binance's post-mortem.

Were Binance's private keys stolen?

Binance says it has found no evidence of any wallet private key leak.

Did Binance get the money back?

Mostly not. About USD 2.7 billion to 3 billion was frozen on chain. Separately, Binance said on 31 October that it had replenished 90% of the stolen assets (per Reuters and CNBC) by buying replacement tokens with its own funds. That is coverage, not recovery.

What is TraderTraitor?

The US government's name for a North Korean state-sponsored group that targets cryptocurrency companies. Public reporting since 2022 ties it to job-offer spearphishing, trojanized crypto apps, malicious npm dependencies, the JumpCloud intrusion, the DMM Bitcoin theft and the Bybit theft.

Would a package firewall have stopped this attack?

Nobody can say, because how the laptop was compromised has not been published. A package firewall blocks malicious, typosquatted and dependency-confusion packages at install time, one technique TraderTraitor has used before. It does not address trojanized apps, session theft or how withdrawals were authorized.

Is Safeguard involved in this incident?

No. Safeguard has no role in the incident or its investigation, and nothing here suggests Binance is a Safeguard customer.

Safeguard demos for these controls

These demos show real Safeguard sessions on other examples. None of them shows this incident. Each paragraph explains how the same flow applies to the controls in this post.

The CLI demo shows the Safeguard CLI installed, asked for a dependency fix and running a scan from the terminal. The same CLI starts the Package Firewall proxy with safeguard pkgfw start and runs safeguard ci scan in a pipeline, so this is the tool your developer setup script and CI templates would call.

Click through it at your own pace, or open it full screen.

The local runner demo sets up the runner on your own machine, approves it with a device code and scans from the terminal. For a wallet or signing service whose code should never leave your network, this is how you scan on your own hardware and send only results to Safeguard.

Click through it at your own pace, or open it full screen.

The Claude demo shows Safeguard connected to Claude. The day a malicious package is named in an advisory, you can ask in the chat you already use which of your projects and images carry it, and get the answer from your own Safeguard data.

Click through it at your own pace, or open it full screen.

For more background, see our posts on the JumpCloud supply chain attack, Lazarus campaigns against the financial sector, North Korean IT workers as an insider threat and blocking malicious dependencies at install time.

Quick check

Sources

• Binance links $6.3 billion crypto theft to compromised DevOps laptop, BleepingComputer, 30 October 2026
• Binance Finds 'Additional Points of Breach' in $6.3B Hack, Decrypt, 30 October 2026
• FBI says North Korea was behind $6 billion Binance crypto hack (Reuters), NBC News, 31 October 2026
• FBI blames North Korea for stolen billions at Binance (AP), ABC News, 31 October 2026
• A simple explainer of the massive $6.3 billion crypto heist at Binance, NPR, 31 October 2026
• North Korea responsible for $6 billion Binance attack, FBI, 31 October 2026
• Binance resumes withdrawals following $6.3 billion hack, says 90% of stolen user assets are covered, CNBC, 31 October 2026
• Binance resumes withdrawals for some major cryptocurrencies after $6 billion heist, CBS News, 1 November 2026
• Binance reopens Bitcoin withdrawals after $6.3B hack, crypto.news, 1 November 2026
• AA22-108A: TraderTraitor: North Korean State-Sponsored APT Targets Blockchain Companies, CISA, FBI and US Treasury, 18 April 2022
• Security alert: social engineering campaign targets technology industry employees, GitHub, 18 July 2023
• Security Update: Incident Details, JumpCloud, 12 July 2023 (updated 20 September 2023)
• North Korea Leverages SaaS Provider in a Targeted Supply Chain Attack, Mandiant (Google Cloud), 24 July 2023
• FBI links North Korean hackers to $308 million crypto heist, BleepingComputer, 24 December 2024
• North Korea Responsible for $1.5 Billion Bybit Hack, FBI IC3 PSA I-022625-PSA, 26 February 2025
• Safe Wallet Confirms North Korean TraderTraitor Hackers Stole $1.5 Billion in Bybit Heist, The Hacker News, 7 March 2025
• Hacking Employers and Seeking Employment: Two Job-Related Campaigns Bear Hallmarks of North Korean Threat Actors, Palo Alto Networks Unit 42, 21 November 2023
• Settings (minimumReleaseAge), pnpm
• Package Firewall, Safeguard Docs
• CI/CD Integration, Safeguard Docs
• Policies and Gates, Safeguard Docs
• Software Composition Analysis, Safeguard Docs
• Red Team (Defensive Adversary Emulation), Safeguard Docs

Last reviewed: 1 November 2026.