OAK — OnChain Attack Knowledge

Worked example · 2025-03

Solflare base-x library homograph-attack vulnerability (CVE-2025-27611) — Solana — 2025-03

Loss
$0 publicly-confirmed realised loss at v0.1 cutoff. The base-x npm library vulnerability (CVE-2025-27611, published April 30, 2025) was patched by base-x maintainers on March 7, 2025; Solflare released the patched version 2.0.1 on March 20, 2025. No publicly-confirmed in-the-wild exploitation of the vulnerability against Solflare or other affected wallet products has been documented at v0.1 cutoff. The incident is documented for OAK's coverage of the Solana-tooling-cryptographic-library-vulnerability surface as a discrete observable, and for the structurally distinct nature of homograph attacks against Base58 / Base32 / cryptographic-encoding addresses compared to standard URL / domain homograph attacks.
Attribution
unattributed at v0.1 cutoff for any exploitation event (none publicly confirmed). The vulnerability discovery is attributed to John Sessford via a publicly-published Medium analysis ("The Crypto Wallet Vulnerability That Went Undetected for Over Six Years"). Sessford's analysis was the load-bearing initial-disclosure surface; subsequent vendor-side patching by base-x maintainers (March 7, 2025) and Solflare (March 20, 2025) addressed the surface. CVE-2025-27611 was published on April 30, 2025 by GitLab Advisories. The base-x maintainers have not publicly identified any in-the-wild exploitation; Solflare has not disclosed any in-the-wild exploitation. The incident is therefore documented as a vulnerability-discovery-and-patch event with unattributed exploitation-side attribution and pseudonymous (Sessford pen-name) discovery-side attribution.
Key teaching point
Standing latent vulnerabilities in foundational cryptographic-encoding libraries can persist for years before discovery, and the patch-deployment latency across the dependent-wallet ecosystem is a structurally important defender-tooling concern. The base-x vulnerability had existed in the library for over six years before Sessford's discovery; the library is depended upon by over a million projects, including major wallets with combined user bases exceeding 17 million. The patch-deployment trajectory — base-x maintainers patch March 7, Solflare patches March 20, GitHub Security Advisory published April 30 — produced a window of approximately 7-8 weeks between the patch availability and the public CVE publication. Defender-tooling work for Solana wallet ecosystems should treat upstream-library-cryptographic-vulnerability-disclosure-and-patch-deployment as a discrete defender-relevant timeline, distinct from the malicious-publish-and-rotation timeline that dominated the December 2024 web3.js case. The class is structurally adjacent to the broader cross-ecosystem standing-vulnerability cohort (e.g., the 2024 xz-utils zero-day discovery) where the load-bearing structural pre-condition is library longevity-and-trust producing reduced ongoing-review intensity.

OAK Techniques observed:

  • OAK-T11.002 (Wallet-Software Distribution Compromise — broad construction at the upstream-library-vulnerability sub-surface). The base-x library is a foundational cryptographic-encoding library used across the broader JavaScript / TypeScript wallet ecosystem; a vulnerability in the library is a wallet-tooling-supply-chain risk surface analogous to (but structurally distinct from) the December 2024 @solana/web3.js supply-chain compromise (examples/2024-12-solana-web3js-npm-supply-chain.md). The structural distinction is that the base-x case is a standing latent vulnerability (existed in the library for over six years before discovery) rather than a malicious-publish supply-chain attack; the failure mode is a real-world weakness in input-validation logic that allows Unicode lookalike characters to bypass address validation, not an attacker-injected backdoor.
  • OAK-T4.003 (Address Poisoning) at the cryptographic-library-permits-near-miss-encoded-addresses sub-surface. The vulnerability allows Unicode lookalike characters (homographs) to bypass the library's address validation, producing visual matches with legitimate addresses while resolving to attacker-controlled destinations. The structural shape is a cryptographic-library-side address-poisoning enabler — the library does not itself produce poisoned addresses, but its inadequate validation enables attacker-side construction of poisoned addresses that would otherwise be rejected at validation time.

Summary

The base-x npm library is a foundational cryptographic-encoding library that provides Base32 / Base58 / Base64 encoding-and-decoding primitives. The library is used across the broader JavaScript / TypeScript ecosystem, including in cryptocurrency wallets that handle Bitcoin Base58Check addresses, Solana base58-encoded addresses, and similar address-encoding formats. Per the published vulnerability analysis, the library has over a million dependent projects and powers wallets with combined user bases exceeding 17 million users.

In early 2025, security researcher John Sessford (publishing on Medium under the byline "John Sessford") discovered a homograph attack vulnerability in the base-x library's address-validation logic that had existed undetected for over six years. The vulnerability — published as CVE-2025-27611 on April 30, 2025 — allows Unicode lookalike characters (homographs / confusables) to bypass the library's address-validation logic, producing visual matches with legitimate addresses while resolving to entirely different attacker-controlled destinations.

Per Sessford's analysis: when users invoked send-transaction flows in vulnerable wallets, "the address silently changed behind the scenes and funds were sent to an entirely different address" if the address contained Unicode lookalike characters that the library's validation accepted as equivalent. The vulnerability is a structurally novel address-poisoning enabler at the cryptographic-library layer. Per Sessford, "a similar program with Unicode support and confusables in play could reduce the time to find a visual match from around 180 minutes to just 2 seconds" — meaning that automated attack tooling against the vulnerability could find homograph-collision addresses substantially faster than against standard validation regimes.

The base-x maintainers patched the vulnerability on March 7, 2025. Solflare — Solana's second-largest wallet by user base — released the patched version 2.0.1 on March 20, 2025. Per Solflare's public statement (March 2025), "Solflare users are not at risk; we enforce version locking to protect from supply-chain attacks; minor versions get bumped and merged only after a thorough code review." The GitHub Security Advisory was published on April 30, 2025, formalising the CVE-2025-27611 disclosure.

No publicly-confirmed in-the-wild exploitation of the vulnerability against Solflare or other affected wallet products has been documented at v0.1 cutoff. The case is therefore a vulnerability-discovery-and-patch event rather than an in-the-wild exploitation event; its inclusion in OAK is for the structural-class anchoring of the base-x homograph surface rather than for a per-incident worked example.

Why this is structurally significant

The base-x homograph vulnerability is structurally distinct from prior Solana-tooling-supply-chain incidents in three ways:

  1. The vulnerability is a standing latent flaw, not a malicious-publish event. The December 2024 @solana/web3.js compromise (examples/2024-12-solana-web3js-npm-supply-chain.md) was a malicious-publish supply-chain attack — attacker-controlled credentials were used to publish a backdoored version of a legitimate library. The March 2025 base-x case is a standing latent flaw — the library's own validation logic was inadequate against Unicode-homograph inputs, producing exploitable behaviour even in legitimate library versions. The two structural classes have different defender-tooling implications: malicious-publish defenses focus on credential-hardening and registry-side anomaly detection; standing-latent-flaw defenses focus on continuous-vulnerability-research and patch-deployment-coordination across the dependent-ecosystem.

  2. Library longevity-and-trust is a structurally exploitable pre-condition. The base-x library had existed for over six years before the vulnerability was discovered. Library longevity is correlated with reduced ongoing-review intensity — established libraries are presumed-trustworthy by their dependents and rarely receive the scrutiny that newer libraries face. The structural lesson is that library longevity is not a sufficient validation signal for cryptographic-encoding correctness; defender-tooling for wallet ecosystems should treat continuous-vulnerability-research against foundational cryptographic libraries as a first-class concern. The base-x case is structurally adjacent to the 2024 xz-utils zero-day discovery, where similar library-longevity-induced reduced-review allowed a malicious commit to persist undetected.

  3. The homograph-attack class against Base58 / cryptographic-encoded addresses is structurally novel. Standard homograph-attack literature focuses on URL / domain homographs (where the lookalike character resolves to an attacker-registered domain). The base-x vulnerability extends the homograph-attack class to cryptographic-encoded addresses — the lookalike character does not resolve to an attacker-registered surface but rather to an attacker-controlled wallet destination via the cryptographic-encoding's bypass of validation. This is structurally distinct from standard address-poisoning (T4.003) where the attacker pre-funds wallets to produce visually-similar addresses; the base-x class allows attackers to construct visually-similar addresses on-demand against any target address. The defender-side intervention requires both (a) library-side patch deployment and (b) wallet-UX-side address-display hardening (e.g., Unicode-normalisation at display time, fixed-width-font rendering with explicit character-disambiguation visualisation).

The case generalises beyond Solana to any cryptocurrency-encoding scheme that depends on character-level visual disambiguation for end-user safety. Bitcoin Base58Check addresses, Ethereum hex-with-checksum addresses, Solana base58 addresses, and similar encoding formats are all exposed to homograph-attack-class risks if the validation logic admits Unicode-lookalike inputs. Future contributors writing cryptographic-encoding-vulnerability worked examples should preserve the Unicode-homograph-class against cryptographic-encoded addresses framing as a discrete sub-pattern.

Timeline (UTC)

When Event OAK ref
Pre-2020 base-x library exists in npm registry; provides Base32 / Base58 / Base64 encoding primitives; widespread adoption across cryptocurrency-wallet ecosystem; latent address-validation flaw permits Unicode-homograph bypass (genesis surface — latent vulnerability)
2020 Solana mainnet launches; Solana wallets (including Solflare and others) adopt base-x for base58 address handling; latent vulnerability propagates through dependent-wallet ecosystem (cohort scaling)
2025-Q1 (early) John Sessford (security researcher, pseudonymous Medium byline) discovers and analyses the base-x homograph vulnerability; coordinates with base-x maintainers Discovery surface
2025-03-07 base-x maintainers release patched version of the library Patch-availability surface
2025-03-20 Solflare releases patched version 2.0.1; public statement confirms Solflare users not at risk and notes version-locking + code-review controls Wallet-side patch-deployment surface
2025-04-30 GitHub Security Advisory publishes CVE-2025-27611; formalises the homograph-attack disclosure Public CVE surface
2025-04-30 → continuing John Sessford publishes Medium analysis; Coinspeaker, Crypto.News, CoinTrust, Cryptonews publish secondary coverage of the vulnerability and patch trajectory (forensic + journalism surface)
Continuing No publicly-confirmed in-the-wild exploitation; broader dependent-ecosystem patch-deployment continues across affected wallets and applications (continuing surface)

What defenders observed

  • Pre-event (library-longevity-and-trust layer): the base-x library had existed for over six years with widespread adoption; the latent flaw persisted undetected through this window. The structural pre-condition is library-longevity reducing ongoing-review intensity. Defender lesson: foundational cryptographic-encoding libraries should be subject to continuous adversarial security research regardless of their age and adoption; library-longevity is not a sufficient validation signal.
  • At-event (discovery layer): John Sessford's discovery was an independent security-research event, with coordinated disclosure to base-x maintainers preceding public disclosure. Defender lesson: the security-research ecosystem on cryptocurrency-tooling libraries is operationally functional; coordinated-disclosure-and-patch was the dominant 2025 pattern for this class. The lesson generalises beyond the base-x case.
  • At-event (patch-deployment-coordination layer): the trajectory from base-x patch (March 7) to Solflare patch (March 20) to public CVE publication (April 30) is approximately 7-8 weeks. The dependent-wallet patch-deployment lag from upstream-library patch is a structurally important defender-tooling concern — wallets that delay patch deployment after the upstream patch is available expose users to the window between upstream-patch and wallet-patch. Defender lesson: wallet vendors should commit to patch-deployment-latency targets (e.g., 48 hours from upstream-patch availability for security-class CVEs) and disclose these targets publicly.
  • At-event (wallet-vendor-side controls layer): Solflare's public statement noted version-locking and code-review controls as the protective surface. These are the canonical 2024-2025 defender-side controls for upstream-library vulnerabilities; the structural shape — version-locking against unauthorised upstream changes + code-review of upstream-version-bump merges — is the operational pattern that the broader Solana wallet ecosystem follows. Defender lesson: version-locking and code-review controls are necessary-but-not-sufficient against standing-latent flaws (the legitimate library version itself is the flaw); the structural defense additionally requires continuous-vulnerability-research against the locked library version.
  • Post-event (in-the-wild-exploitation-detection layer): no publicly-confirmed in-the-wild exploitation has been documented; this could reflect (a) zero or near-zero exploitation, (b) exploitation that has not been publicly forensically anchored, or (c) exploitation whose victims have not publicly disclosed losses. Defender lesson: zero-confirmed-exploitation is not the same as zero-exploitation; defender-tooling work should preserve continued forensic monitoring against the vulnerability class rather than declaring resolution at patch-deployment.

What this example tells contributors writing future Technique pages

  • Standing-latent flaws in foundational cryptographic libraries are a discrete class within T11.002. Future T11.002-adjacent worked examples should preserve the substrate distinction: malicious-publish (web3.js December 2024), standing-latent (base-x March 2025), and wallet-binary compromise (Slope August 2022) are three structurally distinct sub-surfaces within the broader T11.002 class.
  • Homograph attacks against cryptographic-encoded addresses are a discrete sub-pattern within T4.003 (Address Poisoning). Future T4.003 worked examples should preserve the cryptographic-library-side-validation-bypass sub-pattern alongside the standard pre-funded-wallet-mimicry sub-pattern. The base-x case is the canonical 2025 worked example for the cryptographic-library-side sub-pattern.
  • Library-longevity is not a sufficient validation signal for cryptographic-encoding correctness. Future contributors writing supply-chain or cryptographic-library worked examples should preserve this framing; the structural pre-condition for the base-x case is library-longevity-induced reduced-review-intensity.
  • Patch-deployment-latency is a first-class defender-tooling-tracking metric. Future contributors writing CVE-anchored worked examples should record the upstream-patch-availability-to-wallet-patch-deployment latency as a discrete metric; the metric is structurally informative for defender-tooling discipline across the broader wallet ecosystem.
  • The vulnerability-discovery-and-patch event is a discrete worked-example class. OAK's worked-example corpus is dominated by exploitation-event worked examples; future contributors should preserve vulnerability-discovery-and-patch events as a structurally distinct class with unattributed exploitation-side and pseudonymous / confirmed discovery-side attribution. The base-x case is the canonical 2025 worked example for this class.

Public references

Discussion

The base-x homograph vulnerability is OAK's canonical 2025 worked example for standing-latent cryptographic-library flaws affecting Solana wallet ecosystems. The case extends OAK's T11.002 (Wallet-Software Distribution Compromise — broad construction) coverage to the standing-latent-flaw sub-surface, complementing the December 2024 @solana/web3.js malicious-publish case and the August 2022 Slope wallet-binary case.

The structural distinguishing feature of the case is the library-longevity-and-trust pre-condition. The base-x library's six-year-plus existence with widespread adoption produced a reduced-review-intensity surface that allowed the latent flaw to persist undetected. This is structurally informative for the broader 2024-2025 supply-chain risk literature — library longevity is not a sufficient validation signal; foundational cryptographic libraries warrant continuous adversarial security research regardless of adoption depth.

The case also surfaces a v0.x-priority taxonomy gap: the OAK Technique surface at v0.1 lacks a clean slot for vulnerability-discovery-and-patch events as a discrete worked-example class. The corpus is dominated by exploitation-event worked examples; vulnerability-discovery-and-patch events with no confirmed in-the-wild exploitation are documented unevenly. The Token-2022 transfer-hook class vulnerability worked example (examples/2024-2025-token-2022-transfer-hook-class-vulnerability.md) is the closest existing precedent. v0.x development should formalise the vulnerability-discovery-and-patch event class with the base-x case as the 2025 anchor and the Token-2022 transfer-hook case as the 2024-2025 anchor.

For OAK's broader cohort coverage, this case + the December 2024 web3.js case (examples/2024-12-solana-web3js-npm-supply-chain.md) + the August 2022 Slope wallet case (examples/2022-08-slope-phantom.md) collectively establish that Solana wallet / tooling supply-chain risk has matured into a discrete cohort with multiple structurally-distinct sub-surfaces. Each sub-surface — wallet-binary, malicious-publish, standing-latent — has its own defender-tooling alignment, its own exploitation-event-vs-discovery-event ratio, and its own patch-deployment-coordination dynamics. OAK's T11.002 v0.x development should preserve this taxonomy.

The Unicode-homograph-against-cryptographic-encoded-addresses class generalises beyond base-x and beyond Solana. Bitcoin, Ethereum, and other ecosystems with character-level visual address-disambiguation are exposed to the same structural threat; Solana is the canonical 2025 instance because base-x is the dominant Solana-side base58-encoding substrate. Future contributors writing cross-ecosystem cryptographic-encoding-vulnerability worked examples should preserve this framing.

Techniques demonstrated (2)