WWCWildWildCrypto
Menu

Wallet safety / Updated 2026-09-03

When the Real Website Serves Malicious Code: Supply Chain Attacks That Swap the Address You Are Paying

You opened your own bookmark, the site was genuine, and the payment still went to a stranger. How compromised code reaches a legitimate site, and the one verification a hacked page cannot fake.

How this guide is checked

Official sources first, no wallet connection, no guaranteed returns.

Reviewed on 2026-09-03 by WildWildCrypto Safety Desk. Method: Human editorial review with official-source checks, affiliate-disclosure checks, and no-financial-advice checks.

Publisher: WildWildCrypto Editorial. Corrections go through the contact page. We do not ask for seed phrases or tell you what to buy.

crypto supply chain attack matters because Every checklist tells you to verify the URL, use a bookmark, and download from the official source — and you did all three, which is exactly why this category is so disorienting when it happens.

This guide explains how malicious code reaches a genuine website through the software supply chain, why the address on your screen can differ from the address you actually sign, and which single verification step survives a compromised front end.

You will learn how one phishing email against a package maintainer put malicious code in front of billions of weekly downloads, why attackers choose a replacement address that looks like yours rather than a random one, how this differs from clipboard malware and address poisoning, and what clear signing on a separate device actually proves.

The attack that does not need you to make a mistake

Most crypto safety advice is built on a single assumption: that theft requires you to end up somewhere you did not intend to be. Click a bad link, install a lookalike app, connect to a cloned site, paste an address from the wrong place. The advice that follows is all navigational — check the URL, use your own bookmark, download from the official source — and it is genuinely good advice, because most losses really do begin with a misdirection.

This category breaks that assumption. Here you open your own bookmark, the domain is correct down to the last character, the TLS certificate is valid, the interface is the one you have used a hundred times, and the company behind it has done nothing wrong that morning. What has changed is the code the site is serving. Modern web applications are assembled from hundreds of small open-source packages, each of which pulls in others, and a single compromised package deep in that chain becomes code running on every site that depends on it. Nothing about the address bar changes, because nothing about the address is wrong. The site is authentic and it is executing an attacker's instructions, and there is no navigational habit that detects this, because you did not navigate anywhere unusual.

The practical consequence is worth stating plainly before the mechanics: for this specific attack, your judgement about where to go is not the defence. What matters is whether anything in your signing process is independent of the compromised screen. That is a narrower question than 'am I being careful', and it has a much more concrete answer.

Checklist

  • The URL, certificate and interface can all be correct while the code is malicious.
  • Web apps are assembled from hundreds of nested open-source dependencies.
  • A compromise deep in that chain runs on every site that includes it.
  • No amount of URL checking detects code that arrived through the dependency tree.
  • The useful question is what part of your signing process is independent of that screen.

How a package nobody chose ends up inside your transaction

The September 2025 npm incident is the clearest worked example available, because the scale was extreme and the analysis is public. It began, as these things usually do, with a phishing email. Aikido Security, which detected the compromise, documented that maintainers received messages from support at npmjs.help — a domain registered on 5 September 2025, three days before the attack — imitating official npm support with a two-factor reset workflow. The phishing page captured username, password and the second factor together in an adversary-in-the-middle flow, which is why having 2FA enabled did not prevent the takeover. The account belonged to Josh Junon, maintainer of packages that almost no ordinary user has heard of and almost every JavaScript application contains.

The reach is the part that resists intuition. The compromised set included debug at roughly 357 million weekly downloads, ansi-styles at roughly 371 million, chalk at roughly 300 million, supports-color at roughly 287 million and strip-ansi at roughly 261 million, with the affected packages together exceeding two billion weekly downloads. These are utility libraries for colouring terminal text and stripping formatting codes. No wallet developer sat down and chose them; they arrive as dependencies of dependencies, which is precisely what made them a useful target.

What the injected payload did is the detail worth carrying. It was a browser-side interceptor: as The Hacker News reported in its analysis of the incident, the code hooked into window.fetch, XMLHttpRequest and window.ethereum.request along with other wallet provider APIs. Sitting at that layer means it can read and rewrite data flowing between the page, the network and your wallet. It scanned for cryptocurrency addresses across Ethereum, Bitcoin, Solana, Tron, Litecoin and Bitcoin Cash, and swapped destinations before transactions reached you for approval. Blockaid's report on the incident described the behaviour as silently replacing addresses with attacker-controlled alternatives crafted to look nearly identical, and its remediation advice reduced to a single principle worth memorising: code can lie, and every interaction should be verified on-chain.

One clarification that matters for who should care. Socket's researchers, quoted in the same reporting, noted that the malware targets end users with connected wallets who visit a site that includes the compromised code, and that developers are not inherently the target — but if a developer opens an affected site in a browser and connects a wallet, they become victims too. This is not a developers-only story. It is a story about anyone who connects a wallet to a web page.

Checklist

  • Entry point: a phishing email from a lookalike npm support domain registered three days earlier.
  • Two-factor authentication was captured live, so having 2FA did not stop the takeover.
  • Compromised packages exceeded two billion weekly downloads combined.
  • The libraries were utilities nobody deliberately installs — they arrive as nested dependencies.
  • The payload hooked window.fetch, XMLHttpRequest and window.ethereum.request.
  • It scanned for addresses across Ethereum, Bitcoin, Solana, Tron, Litecoin and Bitcoin Cash.
  • Blockaid's principle: code can lie; verify every interaction on-chain.
  • The victims are ordinary users who connect a wallet to an affected page.

Why checking the first and last four characters is the wrong check here

Nearly everyone who has sent crypto more than a few times has settled into the same shortcut: glance at the first four characters, glance at the last four, and if both match, approve. It is a sensible response to a string no human can memorise, and it defeats a lazy substitution. It does not defeat this one, because the attacker anticipated it.

The injected code did not pick a random destination. It compared the legitimate address against a list of attacker-controlled wallets using Levenshtein distance — a measure of how many single-character edits separate two strings — and selected the closest match. The replacement was chosen to survive exactly the inspection you were going to perform. When the ends match and the middle differs by a few characters, your shortcut returns a false positive, and you approve with more confidence than if you had never checked at all.

This is also what separates the attack from three neighbouring ones that people often merge together. Clipboard-hijacking malware runs on your computer and swaps the address after you copy it, which means a clean machine is a real defence and the malicious substitution happens outside the browser. Address poisoning plants a lookalike entry in your own transaction history so you copy the wrong address yourself, which means the defence is never copying from history. A phishing site is a different site altogether, which means checking the URL works. Front-end supply chain compromise defeats all three defences at once: your machine is clean, you copied from the correct place, and you are on the correct site. The substitution happens inside the page, after your input and before your signature — a region that none of those habits reach.

Which leads to the uncomfortable but clarifying conclusion. If the same code that chose the malicious address is also the code drawing the address on your screen, then reading it off that screen proves nothing at all, however carefully you read it.

Checklist

  • The first-four-last-four glance is the exact check the attack was designed to pass.
  • Replacement addresses were selected by Levenshtein distance for maximum visual similarity.
  • Clipboard malware runs on your device; this runs inside a legitimate web page.
  • Address poisoning exploits your own history; this needs no cooperation from you.
  • Phishing sites are caught by URL checks; this survives every URL check.
  • Anything the compromised page renders is evidence produced by the attacker.

The one check the compromised page cannot draw

A hardware wallet is usually explained as a way of keeping your private keys offline, and that is true but incomplete. Its more important property in this scenario is that it has its own screen, driven by its own firmware, showing the transaction it is actually being asked to sign. That display is outside the compromised web page's reach. If the page swapped the destination, the device shows the swapped destination — and the mismatch between what your browser promised and what your device is asking you to authorise is the moment the attack becomes visible.

This only works if you use the device the way it was designed. The distinction the industry draws is between clear signing, where the device shows human-readable details of what you are approving, and blind signing, where it shows an opaque hash and you are simply trusting the interface that produced it. Ledger's own report on the December 2023 compromise of its Connect Kit — a case where, in its words, malicious code was injected inside decentralised applications using Ledger Connect Kit, tricking EVM DApp users into signing transactions that drain their signers — concluded with exactly this emphasis. The company wrote that it continues to encourage clear signing as an industry so users can verify what they see on a trusted display on their Ledger signer, and that it would double down on preventing blind signing. It is a hardware manufacturer describing its own product, so read the scope accordingly; but the underlying principle is not proprietary, and every hardware signer with a screen offers the same structural benefit. Blind signing is the setting that converts any such device back into one that approves whatever the compromised screen sends it.

The Connect Kit case is also the honest counterweight to any assumption that this is a problem of careless open-source hobbyists. On 14 December 2023, malicious versions were published over a window of under two hours in the morning after a former employee's package-registry account was phished — Ledger's report attributes the bypass of two-factor authentication on that account to credentials associated with it rather than to a weakness in 2FA itself — and roughly five hours passed between the compromise and complete resolution, though the company reports the window in which assets were actively drained was under two hours. A well-resourced security company, a fix deployed around 40 minutes after it learned of the attack, and users were still drained. Speed of response is not a defence you can rely on, because you may be transacting during the window.

Two supporting habits complete the picture. Verify the full address on the device rather than its ends, since the ends are the part chosen to match. And for a payment large enough that losing it would matter, send a small test amount first, confirm it arrived where you intended by looking it up on a block explorer, and only then send the rest — a slow, unglamorous step that costs a fee and defeats every variant of address substitution regardless of where in the chain it happened.

Checklist

  • A hardware wallet's own screen is rendered outside the compromised page.
  • Compare what the browser promised against what the device is asking you to sign.
  • Clear signing shows human-readable details; blind signing shows an opaque hash.
  • Ledger's post-incident position: encourage clear signing, prevent blind signing.
  • In the Connect Kit case, a fast response still left a draining window of under two hours.
  • Verify the full address on the device, not the first and last characters.
  • For meaningful amounts, send a small test transfer and confirm it on a block explorer first.

A routine that holds when the site itself is the problem

None of this argues for abandoning web applications, which would be both impractical and an overreaction to a risk that is real but intermittent. It argues for a routine that does not depend on the page being honest. Keep the amount that can move in one session small by separating a hot wallet you connect to sites from the holdings you do not; a compromised front end can only reach what the connected wallet can spend. Disconnect wallets when you finish rather than leaving standing connections across browser sessions, and periodically review and revoke token approvals you no longer need, since an approval granted during a compromised session keeps working long after the code is fixed.

Treat pauses as information. If a familiar interface asks you to re-approve something you already approved, prompts an unexpected signature during an ordinary action, or behaves in a way that does not match your memory of it, stop and check whether anyone has reported a problem before continuing. The Connect Kit incident was public within hours, and the ordinary channels — the project's own announcements, established security researchers — carried the warning while the attack was live. Nothing on the page itself would have told you.

Finally, keep the failure mode of the whole category in mind, because it changes what counts as a good day. In the npm case the attackers came away with almost nothing: BleepingComputer's accounting of the attacker's wallets found roughly five cents in ether and about 20 dollars of a low-volume memecoin, and headlines describing losses in the hundreds of dollars appear to have valued that illiquid token generously. The reason is not that the technique failed but that Aikido detected the malicious publish quickly and the maintainer confirmed and began cleanup within roughly two hours. That is a story about detection speed: the same code sat in front of packages downloaded over two billion times a week. The exposure was enormous and the loss was negligible because the window was short. Plan for the version where the window is not short, and the plan is simple: connect little, sign what your device shows you rather than what the page tells you, and test large payments before you make them.

Checklist

  • Separate a small hot wallet for site connections from long-term holdings.
  • Disconnect wallets after use rather than leaving standing connections.
  • Review and revoke token approvals periodically — approvals outlive the compromise.
  • An unexpected re-approval or signature prompt is a reason to stop and check.
  • Warnings travel through project announcements and researchers, never the affected page.
  • The npm attackers stole only a few hundred dollars because detection took about two hours.
  • Assume the next window is longer, and size your exposure accordingly.

Authority sources used

Outbound links are included for verification and entity authority, not decoration.

FAQ

If the website was genuine, what exactly was compromised?

The code the website serves, rather than the website's identity or ownership. A modern web application is assembled from many small open-source packages, each of which depends on others, so what runs in your browser is the sum of hundreds of components the site's developers never individually chose. When an attacker takes over the account of someone who maintains one of those components and publishes a malicious version, every application that rebuilds or reloads with that version begins serving the attacker's code from its own genuine domain. In the September 2025 npm case documented by Aikido Security, the entry point was a phishing email from a lookalike support domain registered three days earlier, and the compromised utilities — packages for colouring and stripping terminal text — exceeded two billion weekly downloads between them. Nothing about the site's address, certificate or reputation changes during this, which is precisely why navigational advice does not detect it. The company operating the site is a victim of the same compromise you are.

Does a hardware wallet actually protect me from this?

It does, but only because of a property people often overlook: it has an independent screen showing the transaction it is genuinely being asked to sign, driven by its own firmware rather than by the web page. If a compromised front end swapped the destination address, the device displays the swapped address, and the disagreement between your browser and your device is the alarm. That protection collapses under blind signing, where the device shows an opaque hash instead of readable details and you are effectively trusting the same interface that may be lying. Ledger's report on the December 2023 Connect Kit compromise ends on this exact point, stating that it continues to encourage clear signing as an industry so users can verify what they see on a trusted display, and that it intends to double down on preventing blind signing. So the accurate version of the advice is not 'use a hardware wallet' but 'use a hardware wallet, read the full destination on its screen, and refuse to approve anything it cannot describe to you in terms you understand'.

How is this different from clipboard malware that swaps addresses?

The place the substitution happens, which changes every defence. Clipboard-hijacking malware runs on your own computer and rewrites an address after you copy it, so a clean device is a genuine protection and antivirus scanning is relevant. A front-end supply chain compromise happens inside a legitimate web page on a clean machine: the malicious code hooks the browser and wallet interfaces — in the npm case, window.fetch, XMLHttpRequest and window.ethereum.request — and alters the destination between your input and your signature. Address poisoning is different again: it plants a lookalike entry in your own transaction history so that you copy the wrong address yourself, which is why the defence there is never copying from history. Each of those three has a defence that fails against the others, and this one defeats all three, because your machine is clean, your source was correct, and your URL was right. The single defence that spans all of them is confirming the destination on a device the page cannot draw on.

I checked the first and last four characters. Was that not enough?

That habit is specifically what the attack defeats, which makes it worse than useless here because it returns a confident false positive. The injected code did not choose a random attacker address; it computed the Levenshtein distance between your intended address and a list of its own, then selected the closest visual match. Levenshtein distance measures how many single-character edits separate two strings, so choosing the minimum produces an address that shares as much of its appearance as possible with the legitimate one — including, very often, the beginning and end that you were going to check. The remedy is not to check more characters on the same screen, because the compromised page renders that screen too. It is to compare against something the page does not control: the full address on a hardware wallet display, or a small test transaction whose arrival you confirm independently on a block explorer before sending the real amount.

Should I stop using decentralised applications altogether?

That would be an overcorrection to a risk that is real but intermittent, and it would push you toward custodial alternatives whose risks are different rather than absent. The proportionate response is to limit what a compromised session can reach and to keep one verification step outside the browser. Practically, that means connecting a hot wallet holding an amount you could lose rather than your main holdings, disconnecting when you are finished instead of leaving standing connections, reviewing and revoking token approvals periodically because an approval granted during a compromised session keeps working afterwards, and confirming destinations on a hardware display before approving. It also means treating unusual prompts as information: an interface that asks you to re-approve something you already approved, or requests a signature during an action that should not need one, is worth pausing on. During the Connect Kit incident the warnings circulated publicly within hours through project announcements and security researchers, while the affected pages themselves looked entirely normal.

How much was actually stolen in the npm attack, and does the amount matter?

Almost nothing, and the smallness is instructive rather than reassuring. BleepingComputer's examination of the attacker's wallets found roughly five cents' worth of ether and about 20 dollars of a low-volume memecoin — early reporting that put the figure in the hundreds of dollars appears to have valued that thinly traded token generously. Either way the proceeds were trivial, and not because the technique failed. Aikido Security's monitoring flagged the malicious publish almost immediately, alerted the maintainer, and cleanup began within roughly two hours. Set that against the exposure — packages with more than two billion weekly downloads, reaching wallets, exchanges and decentralised applications indiscriminately — and the correct reading is that a two-hour detection window separated a negligible loss from a potentially enormous one. The Ledger Connect Kit compromise of December 2023 is the same lesson from the other direction: a well-resourced company deployed a fix around 40 minutes after learning of the attack, and users were still drained during the window. Detection speed is not something you control, so the defences that matter are the ones that work while the malicious code is live.