bip322

Version	Released
`0.0.12` patch	Aug 31, 2026
`0.0.11` patch	Aug 02, 2026
`0.0.10` patch yanked 1 CVE	Sep 05, 2025
`0.0.9` patch yanked 1 CVE	Nov 01, 2024
`0.0.8` patch yanked 1 CVE	Oct 20, 2024
`0.0.7` patch yanked 1 CVE	Aug 26, 2024
`0.0.6` patch yanked 1 CVE	Aug 22, 2024
`0.0.5` patch	Aug 10, 2024
`0.0.4` patch	Aug 09, 2024
`0.0.3` patch	Aug 09, 2024
`0.0.2` patch	Aug 02, 2024
`0.0.1` initial	Jul 22, 2024

0.0.12 patch

Aug 31, 2026

0.0.11 patch

Aug 02, 2026

0.0.10 patch yanked

1 CVE

RUSTSEC-2026-0334 GHSA-5chw-87w3-j9cv Aug 14, 2026

BIP-322 address ownership verification bypass for P2WPKH and P2SH-P2WPKH addresses

9.1 / 10

Critical

Network Low None None Unchanged High High None

Affected versions of bip322 accepted a BIP-322 proof created with an attacker-controlled private key as a valid signature for an unrelated victim P2WPKH or P2SH-P2WPKH address, allowing complete authentication bypass in applications using verify_simple, verify_simple_encoded, verify_full, or verify_full_encoded as proof that a user controls a Bitcoin address.

In verify_full, the verifier obtained the public key from the caller-controlled witness and passed it to verify_full_p2wpkh, where the supposed public-key mismatch check read the key from the same witness and compared it with itself:

let witness_pub_key = &witness.to_vec()[1];

if &pub_key.to_bytes() != witness_pub_key {
    return Err(Error::PublicKeyMismatch);
}

Since pub_key was originally parsed from that exact witness element, this comparison was tautological. The code verified that the signature was valid for the public key embedded in the witness, but never verified that this public key hashes to the claimed address, violating BIP-322's requirement that the message_signature satisfy the message_challenge (the claimed address's scriptPubKey).

As a result, an attacker could select any victim P2WPKH or P2SH-P2WPKH address, construct the BIP-322 challenge for that address and message, sign it with their own unrelated private key, and have the proof accepted. No victim key or victim interaction was required. Application-level nonces do not mitigate this, since the attacker can construct and sign the current challenge message with their own key.

P2TR verification is not affected: the public key is derived from the address's witness program rather than from the caller-controlled witness.

The flaw was corrected in commit e8accbe by deriving the expected scriptPubKey from the witness public key (P2WPKH(HASH160(pubkey)), wrapped in P2SH for the nested case) and requiring it to exactly equal the scriptPubKey of the claimed address before signature verification, failing with Error::PublicKeyMismatch otherwise. The fix is included in version 0.0.11. Affected versions 0.0.6 through 0.0.10 have been yanked from crates.io.

There is no known workaround that mitigates the vulnerability. Upgrading to version 0.0.11 is the recommended course of action.

Fixed in


          0.0.11

References

Updated Oct 09, 2026 · Source: OSV.dev

Sep 05, 2025

0.0.9 patch yanked

1 CVE

RUSTSEC-2026-0334 GHSA-5chw-87w3-j9cv Aug 14, 2026

BIP-322 address ownership verification bypass for P2WPKH and P2SH-P2WPKH addresses

9.1 / 10

Critical

Network Low None None Unchanged High High None

Affected versions of bip322 accepted a BIP-322 proof created with an attacker-controlled private key as a valid signature for an unrelated victim P2WPKH or P2SH-P2WPKH address, allowing complete authentication bypass in applications using verify_simple, verify_simple_encoded, verify_full, or verify_full_encoded as proof that a user controls a Bitcoin address.

In verify_full, the verifier obtained the public key from the caller-controlled witness and passed it to verify_full_p2wpkh, where the supposed public-key mismatch check read the key from the same witness and compared it with itself:

let witness_pub_key = &witness.to_vec()[1];

if &pub_key.to_bytes() != witness_pub_key {
    return Err(Error::PublicKeyMismatch);
}

Since pub_key was originally parsed from that exact witness element, this comparison was tautological. The code verified that the signature was valid for the public key embedded in the witness, but never verified that this public key hashes to the claimed address, violating BIP-322's requirement that the message_signature satisfy the message_challenge (the claimed address's scriptPubKey).

As a result, an attacker could select any victim P2WPKH or P2SH-P2WPKH address, construct the BIP-322 challenge for that address and message, sign it with their own unrelated private key, and have the proof accepted. No victim key or victim interaction was required. Application-level nonces do not mitigate this, since the attacker can construct and sign the current challenge message with their own key.

P2TR verification is not affected: the public key is derived from the address's witness program rather than from the caller-controlled witness.

The flaw was corrected in commit e8accbe by deriving the expected scriptPubKey from the witness public key (P2WPKH(HASH160(pubkey)), wrapped in P2SH for the nested case) and requiring it to exactly equal the scriptPubKey of the claimed address before signature verification, failing with Error::PublicKeyMismatch otherwise. The fix is included in version 0.0.11. Affected versions 0.0.6 through 0.0.10 have been yanked from crates.io.

There is no known workaround that mitigates the vulnerability. Upgrading to version 0.0.11 is the recommended course of action.

Fixed in


          0.0.11

References

Updated Oct 09, 2026 · Source: OSV.dev

Nov 01, 2024

0.0.8 patch yanked

1 CVE

RUSTSEC-2026-0334 GHSA-5chw-87w3-j9cv Aug 14, 2026

BIP-322 address ownership verification bypass for P2WPKH and P2SH-P2WPKH addresses

9.1 / 10

Critical

Network Low None None Unchanged High High None

Affected versions of bip322 accepted a BIP-322 proof created with an attacker-controlled private key as a valid signature for an unrelated victim P2WPKH or P2SH-P2WPKH address, allowing complete authentication bypass in applications using verify_simple, verify_simple_encoded, verify_full, or verify_full_encoded as proof that a user controls a Bitcoin address.

In verify_full, the verifier obtained the public key from the caller-controlled witness and passed it to verify_full_p2wpkh, where the supposed public-key mismatch check read the key from the same witness and compared it with itself:

let witness_pub_key = &witness.to_vec()[1];

if &pub_key.to_bytes() != witness_pub_key {
    return Err(Error::PublicKeyMismatch);
}

Since pub_key was originally parsed from that exact witness element, this comparison was tautological. The code verified that the signature was valid for the public key embedded in the witness, but never verified that this public key hashes to the claimed address, violating BIP-322's requirement that the message_signature satisfy the message_challenge (the claimed address's scriptPubKey).

As a result, an attacker could select any victim P2WPKH or P2SH-P2WPKH address, construct the BIP-322 challenge for that address and message, sign it with their own unrelated private key, and have the proof accepted. No victim key or victim interaction was required. Application-level nonces do not mitigate this, since the attacker can construct and sign the current challenge message with their own key.

P2TR verification is not affected: the public key is derived from the address's witness program rather than from the caller-controlled witness.

The flaw was corrected in commit e8accbe by deriving the expected scriptPubKey from the witness public key (P2WPKH(HASH160(pubkey)), wrapped in P2SH for the nested case) and requiring it to exactly equal the scriptPubKey of the claimed address before signature verification, failing with Error::PublicKeyMismatch otherwise. The fix is included in version 0.0.11. Affected versions 0.0.6 through 0.0.10 have been yanked from crates.io.

There is no known workaround that mitigates the vulnerability. Upgrading to version 0.0.11 is the recommended course of action.

Fixed in


          0.0.11

References

Updated Oct 09, 2026 · Source: OSV.dev

Oct 20, 2024

0.0.7 patch yanked

1 CVE

RUSTSEC-2026-0334 GHSA-5chw-87w3-j9cv Aug 14, 2026

BIP-322 address ownership verification bypass for P2WPKH and P2SH-P2WPKH addresses

9.1 / 10

Critical

Network Low None None Unchanged High High None

Affected versions of bip322 accepted a BIP-322 proof created with an attacker-controlled private key as a valid signature for an unrelated victim P2WPKH or P2SH-P2WPKH address, allowing complete authentication bypass in applications using verify_simple, verify_simple_encoded, verify_full, or verify_full_encoded as proof that a user controls a Bitcoin address.

In verify_full, the verifier obtained the public key from the caller-controlled witness and passed it to verify_full_p2wpkh, where the supposed public-key mismatch check read the key from the same witness and compared it with itself:

let witness_pub_key = &witness.to_vec()[1];

if &pub_key.to_bytes() != witness_pub_key {
    return Err(Error::PublicKeyMismatch);
}

Since pub_key was originally parsed from that exact witness element, this comparison was tautological. The code verified that the signature was valid for the public key embedded in the witness, but never verified that this public key hashes to the claimed address, violating BIP-322's requirement that the message_signature satisfy the message_challenge (the claimed address's scriptPubKey).

As a result, an attacker could select any victim P2WPKH or P2SH-P2WPKH address, construct the BIP-322 challenge for that address and message, sign it with their own unrelated private key, and have the proof accepted. No victim key or victim interaction was required. Application-level nonces do not mitigate this, since the attacker can construct and sign the current challenge message with their own key.

P2TR verification is not affected: the public key is derived from the address's witness program rather than from the caller-controlled witness.

The flaw was corrected in commit e8accbe by deriving the expected scriptPubKey from the witness public key (P2WPKH(HASH160(pubkey)), wrapped in P2SH for the nested case) and requiring it to exactly equal the scriptPubKey of the claimed address before signature verification, failing with Error::PublicKeyMismatch otherwise. The fix is included in version 0.0.11. Affected versions 0.0.6 through 0.0.10 have been yanked from crates.io.

There is no known workaround that mitigates the vulnerability. Upgrading to version 0.0.11 is the recommended course of action.

Fixed in


          0.0.11

References

Updated Oct 09, 2026 · Source: OSV.dev

Aug 26, 2024

0.0.6 patch yanked

1 CVE

RUSTSEC-2026-0334 GHSA-5chw-87w3-j9cv Aug 14, 2026

BIP-322 address ownership verification bypass for P2WPKH and P2SH-P2WPKH addresses

9.1 / 10

Critical

Network Low None None Unchanged High High None

Affected versions of bip322 accepted a BIP-322 proof created with an attacker-controlled private key as a valid signature for an unrelated victim P2WPKH or P2SH-P2WPKH address, allowing complete authentication bypass in applications using verify_simple, verify_simple_encoded, verify_full, or verify_full_encoded as proof that a user controls a Bitcoin address.

In verify_full, the verifier obtained the public key from the caller-controlled witness and passed it to verify_full_p2wpkh, where the supposed public-key mismatch check read the key from the same witness and compared it with itself:

let witness_pub_key = &witness.to_vec()[1];

if &pub_key.to_bytes() != witness_pub_key {
    return Err(Error::PublicKeyMismatch);
}

Since pub_key was originally parsed from that exact witness element, this comparison was tautological. The code verified that the signature was valid for the public key embedded in the witness, but never verified that this public key hashes to the claimed address, violating BIP-322's requirement that the message_signature satisfy the message_challenge (the claimed address's scriptPubKey).

As a result, an attacker could select any victim P2WPKH or P2SH-P2WPKH address, construct the BIP-322 challenge for that address and message, sign it with their own unrelated private key, and have the proof accepted. No victim key or victim interaction was required. Application-level nonces do not mitigate this, since the attacker can construct and sign the current challenge message with their own key.

P2TR verification is not affected: the public key is derived from the address's witness program rather than from the caller-controlled witness.

The flaw was corrected in commit e8accbe by deriving the expected scriptPubKey from the witness public key (P2WPKH(HASH160(pubkey)), wrapped in P2SH for the nested case) and requiring it to exactly equal the scriptPubKey of the claimed address before signature verification, failing with Error::PublicKeyMismatch otherwise. The fix is included in version 0.0.11. Affected versions 0.0.6 through 0.0.10 have been yanked from crates.io.

There is no known workaround that mitigates the vulnerability. Upgrading to version 0.0.11 is the recommended course of action.

Fixed in


          0.0.11

References

Updated Oct 09, 2026 · Source: OSV.dev

Aug 22, 2024

0.0.5 patch

Aug 10, 2024

0.0.4 patch

Aug 09, 2024

0.0.3 patch

Aug 09, 2024

0.0.2 patch

Aug 02, 2024

0.0.1 initial

Jul 22, 2024

Activity

Reach

Details