Web3 SDK Security Testing: How to Audit a Wallet SDK

Video transcript

An SDK runs inside every app that installs it, so one bad release reaches every integrator. Test what it builds and ships, not just its source.

Ledger Connect Kit and Solana web3 dot js were both compromised through npm releases. None of these incidents needed a smart contract bug.

First question: does the transaction the SDK builds match the call the integrator asked for? The signature stays valid, so these bugs are quiet.

Keep every user field inside the signed payload, match the signing domain to the contract, decode and compare, and keep defaults safe.

Clear keys after use and redact logs, since Slope sent key material to a monitoring service. Never let an RPC response choose the recipient.

At Ledger, a phished former employee's npm access shipped a drainer, and full resolution took about five hours. Most dApps got it from a CDN without rebuilding.

Integrators run the registry package, not the repo. Diff the two, use trusted publishing, and have integrators pin versions. Provenance alone is not enough.

Map the public surface and threat model it. Diff source against the published package. Fuzz the builders, feed in hostile responses, then review the release path.

Guardian's SDK audit reviews source and published package together, because the gap between them is where supply chain risk lives.

Read the full guide, or talk to Guardian about auditing the SDK your integrators trust.

An SDK runs inside every app that installs it. It builds the transactions users sign, and some SDKs touch keys directly.

So one bad release can reach every integrator at once. Ledger Connect Kit and @solana/web3.js were both compromised that way, through new versions published to npm under trusted names.

This guide covers what to test in a wallet, dApp or signing SDK, and how to run the review.

Why SDKs Are a Target

Integrators install an SDK and stop reading it. Its code then runs beside their users' wallets, keys and API credentials.

The last two are wallet apps, not SDKs. They show two failures an SDK audit looks for: a release outside review, and keys in telemetry.

None of the four needed a smart contract bug.

Transaction Construction

The core question: does the transaction the SDK hands the wallet match the call the integrator asked for?

Bugs here are quiet. The signature is valid, so nothing downstream objects.

Guardian's public reports show the same class of bug in signing code:

• Synthetix withdrawal backend (H-15): signed typed data for withdrawals left out the amount and destination. A tampered request still verified.
• Glider validator (M-14): the P-256 verifier choice sat outside the signed payload, so a relayer could change it.
• Glider validator (L-22): it advertised an EIP-712 domain its owners do not sign. An SDK following it could produce signatures the validator rejects.

What to test

• Every user-controlled field sits inside the signed payload: amount, recipient, chain ID, nonce, expiry.
• The EIP-712 domain matches what the contract verifies, on every chain.
• Build, decode and compare: decoded calldata matches the request for every method.
• Bad arguments fail loudly: wrong decimals, bad checksums, zero addresses, overflowing amounts.
• Defaults are safe: no unlimited approvals, no endless expiry, no silent chain switch.
• What the wallet will display matches what will execute.

Keys, Secrets and Responses

Keys and secrets

Many SDKs never need a private key. When one does, test how long the key lives and where it can leak.

The @solana/web3.js advisory said the bad versions could drain "dapps, like bots, that handle private keys directly." Non-custodial wallets should not be affected, it said.

Bots that hold keys need their own review; see our guide to the offchain automation pentest.

Slope shows the logging risk. Its app sent users' private key material to an application monitoring service, the Solana Foundation said.

• Keys and seeds are cleared after use and never serialized.
• Errors, logs, analytics and crash reports are redacted before they leave the process.
• API keys in a browser bundle are treated as public and scoped to match.
• Signer interfaces accept hardware wallets, KMS or HSM signers, not only raw keys.

RPC and backend responses

An SDK trusts what nodes, relayers, price sources and its own backend return. Each is a place to inject data.

• Confirm the node's chain ID before building or signing.
• Validate schemas, sizes and number ranges on every response.
• Never let a response choose the recipient, spender or contract.
• Set timeouts, and fail closed when a source is down or stale.

Dependencies and Publishing

Integrators run the package on the registry, not the repo. An SDK audit reviews both.

At Ledger, an attacker phished a former employee and used their npm account to publish, bypassing 2FA. Most dApps loaded the kit at runtime from a CDN, so they got the drainer without rebuilding.

Ledger shipped a fix within 40 minutes of becoming aware, but CDN caches kept the bad file reachable a little longer. From compromise to full resolution took about five hours.

Trust Wallet's 2.68 build was uploaded with a leaked Chrome Web Store API key, bypassing internal review. The attacker got the key through exposed developer GitHub secrets, Trust Wallet said, likely in the Sha1-Hulud supply chain attack.

What to test

• Diff the published package against the tagged source. Flag any file the repo lacks.
• Review install scripts and new dependencies in every release.
• Publish with npm trusted publishing, then restrict token publishing, as npm "strongly" recommends.
• Check provenance, but npm says it "does not guarantee the package has no malicious code."
• Remove leavers from registry, code host and CI access on their last day.
• Tell integrators to pin versions. A loader that fetches the latest release makes every publish live.
• Fail CI on known-vulnerable dependencies.
• Rehearse a pull: deprecate, purge CDN caches and notify integrators.

Dependency advisories count too. Guardian's Longshot review flagged a rustls-webpki version with a known TLS validation flaw in its HTTPS client stack.

For the consuming side of npm, see our guide to dApp frontend supply chain security.

How to Test an SDK

1. Map the public surface: every export, default and config option.
2. Threat model each one: who calls it, with what, and what it can sign or send.
3. Read the source, then the published package, and diff them.
4. Fuzz transaction builders and decoders against the contracts they target.
5. Feed hostile RPC and backend responses through a local proxy.
6. Search logs, errors and telemetry for keys and tokens.
7. Review the release path: accounts, 2FA, tokens, CI permissions and rollback.
8. Retest every fix, then write safe-integration guidance.

Differential tests matter most for signing helpers. Build a payload in the SDK, verify it in the contract, and compare.

That catches the Glider-style mismatches above before integrators ship them.

How Guardian Audits SDKs

Guardian's SDK audit covers TypeScript, Python, Rust, Go and JVM client libraries for EVM and Solana, from wallet kits to transaction builders.

It reviews six areas: transaction construction, key and credential handling, response trust, the published artifact, release control and the integration surface.

Source and published package are both reviewed. As the service page puts it, "the gap between them is where supply-chain risk lives."

Engagements are scoped by the public surface and the release pipeline. Offchain services are led by Carlos Polop, who co-founded HackTricks training.

Shipping a wallet extension as well? See the browser extension pentest and our guide to offchain security.

Frequently Asked Questions

What is SDK security testing?

A review of a client library as an attacker would use it: the transactions it builds, its handling of keys and responses, and what ships to the registry, including who can publish.

How is an SDK audit different from a smart contract audit?

A contract audit reviews onchain code at a commit. An SDK audit reviews code that runs in integrators' apps: transaction building, key handling, response checks, dependencies and publishing. Some bugs only show when the SDK and contract are tested together.

What caused the Ledger Connect Kit attack?

An attacker phished a former Ledger employee and published versions 1.1.5 to 1.1.7 to npm with a wallet drainer. Most dApps loaded the kit at runtime from a CDN, Ledger said, so they received it without rebuilding.

Does npm provenance make an SDK safe?

No. Provenance links a package to its source and build, and npm says it does not guarantee the package has no malicious code. Pair it with trusted publishing, disallowed tokens, release review and a diff of each published package.

Sources

• Ledger: Security Incident Report, Ledger Connect Kit (December 20, 2023)
• GitHub Advisory Database: @solana/web3.js malicious versions 1.95.6 and 1.95.7, GHSA-jcxm-7wvp-g6p5 (December 4, 2024)
• Trust Wallet: Browser Extension v2.68 Incident Community Update (December 30, 2025, updated July 17, 2026)
• Solana Foundation: 8/2/2022 Slope Wallet Incident Update (August 8, 2022)
• npm Docs: Trusted publishing for npm packages
• npm Docs: Generating provenance statements
• Guardian: Synthetix Withdrawal Flow (December 15, 2025)
• Guardian: Glider Protocol Review (September 18, 2026)
• Guardian: Longshot Protocol Review (July 3, 2026)
• Guardian: SDK Security Audit