Known advisories in a clean install
npm audit on a fresh install of all three packages (0.7.0, measured
2026-10-08) reports nine packages: eight high, one moderate. Installing
@wasit-dev/cli alone reports eight (seven high, one moderate), since it pulls
a smaller slice of the same graph. None originate in Wasit's own code. They
arrive by two routes:
@stellar/mpp@0.7.1brings older copies of two packages alongside the ones Wasit declares.@stellar/stellar-sdk@15.1.0, because@stellar/mpppeers on^15.1.0, bringsaxios@1.15.0andtoml@3.0.0(high).mppx@0.6.31, because@stellar/mpppeers on^0.6.29, is matched by the "gas draining" advisories (moderate), which affectmppxbefore 0.8.2; themppxWasit declares resolves 0.8.19.@stellar/stellar-sdk@16.3.1, the version Wasit and@x402/stellar@2.28.0both resolve, pinsaxios@1.18.0, which axios advisories published since 0.6.0 now match (fixed in axios 1.20.0). No 16.x release of the SDK moves past axios 1.18.0. 17.2.1 pins axios 1.20.0, but@x402/stellar2.28.0, its latest, requires^16.3.0, so moving Wasit to 17 would install two copies of the SDK.
@stellar/mpp, @x402/stellar and the three @wasit-dev/* packages appear in
that count only because npm marks a package that depends on an affected one.
There is no advisory against Wasit 0.7.0's own code; versions up to 0.6.0 have
the MPP-01 network issue described under Testnet only.
There is no downstream fix. The levers are @stellar/mpp's two peer ranges,
reported upstream as
stellar-mpp-sdk#70 and
written up in findings/upstream-sdk.md, whose
fix has merged upstream while @stellar/mpp@0.7.1 is still the latest on npm;
and a release of the Stellar SDK's 16 line on a fixed axios, or @x402/stellar
accepting 17 (all checked 2026-10-08).
npm run verify:clean-install installs all three packages and prints the
audit on every CI run, so the count is measured rather than remembered.
This is stated here rather than left to be discovered: a tool that checks other people's compliance should be legible about its own supply chain.