Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A malicious JSON-stringifyable message can be made passing on verify(), when global Buffer is buffer package Details This affects only environments where require('buffer') is <https://npmjs.com/buffer E.g.: browser bundles, React Native apps, etc. Buffer.isBuffer check can be bypassed, resulting in strange objects being accepted as message, and those messages could trick verify() into returning false-positive true values v2.x is unaffected as it verifies input to be an actual Uint8Array instance Such a message can be constructed for any already known message/signature pair There are some restrictions though (also depending on the known message/signature), but not very limiting, see PoC for example https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this PoC This code deliberately doesn't provide reencode for now, could be updated later Output (after being bundled): Impact Malicious messages could crafted to be verified from a given known valid…
Recommended action: Upgrade to 1.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Private key can be extracted on signing a malicious JSON-stringifiable object, when global Buffer is buffer package Details This affects only environments where require('buffer') is <https://npmjs.com/buffer E.g.: browser bundles, React Native apps, etc. Buffer.isBuffer check can be bypassed, resulting in k reuse for different messages, leading to private key extraction over a single invalid message (and a second one for which any message/signature could be taken, e.g. previously known valid one) v2.x is unaffected as it verifies input to be an actual Uint8Array instance Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still should not leak the private key Also, message validation could have…
Recommended action: Upgrade to 1.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.