Bsv Wallet Toolbox Mobile
Monthly
Transactions built through a remote StorageClient in @bsv/wallet-toolbox 1.1.47 through 2.3.3, @bsv/wallet-toolbox-client 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile 1.3.21 through 2.3.3 can be silently redirected by a malicious or compromised storage provider, which returns output locking scripts the wallet signs without confirming they match the caller's request. Because the provider can substitute a recipient script or append an attacker-controlled output funded by shrinking change, the wallet broadcasts a transaction paying the attacker while the application and user interface still display the intended recipient; the integrity impact is high with no confidentiality or availability effect, and no authentication against the victim wallet is required (CVSS 4.0 8.7, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). Exploitation requires the application to use a remote StorageClient backend the attacker controls and the user to initiate a transaction through it - local-storage applications and those that independently verify outputs are unaffected; no public exploit code has been identified at time of analysis and the issue is patched in 2.4.0.
Transactions built through a remote StorageClient in @bsv/wallet-toolbox 1.1.47 through 2.3.3, @bsv/wallet-toolbox-client 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile 1.3.21 through 2.3.3 can be silently redirected by a malicious or compromised storage provider, which returns output locking scripts the wallet signs without confirming they match the caller's request. Because the provider can substitute a recipient script or append an attacker-controlled output funded by shrinking change, the wallet broadcasts a transaction paying the attacker while the application and user interface still display the intended recipient; the integrity impact is high with no confidentiality or availability effect, and no authentication against the victim wallet is required (CVSS 4.0 8.7, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). Exploitation requires the application to use a remote StorageClient backend the attacker controls and the user to initiate a transaction through it - local-storage applications and those that independently verify outputs are unaffected; no public exploit code has been identified at time of analysis and the issue is patched in 2.4.0.