Skip to content
Heist/ feed
Back to feed
CriticalFix available

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

Type: advisorySources: OSV

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: ```rust 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 s

Products
bip322
Affected versions
Not specified
Fixed versions
0.0.11
CVEs
Not specified
Confirmed fixed CVEs
Not specified
Updated in this feed
28 Oct 2026, 11:06 UTC · Revision 1

Source evidence

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

core-osv · Original source

Published 14 Aug 2026, 12:00 UTC

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: ```rust 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 s

osv:RUSTSEC-2026-0334

bip322

Fixed versions: 0.0.11

Complete source record
{
  "id": "a01acd7941f8fc3535c562c4f4ea39d940d6b692c6e46d31a12c71db5d9867a7",
  "url": "https://osv.dev/vulnerability/RUSTSEC-2026-0334",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "BIP-322 address ownership verification bypass for P2WPKH and P2SH-P2WPKH addresses",
    "summary": "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: ```rust 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 s",
    "evidence": "osv:RUSTSEC-2026-0334",
    "products": [
      {
        "name": {
          "value": "bip322",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "0.0.11",
            "evidence": "/affected/0/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "critical",
    "structured": {
      "id": "RUSTSEC-2026-0334",
      "aliases": [
        "GHSA-5chw-87w3-j9cv",
        "RUSTSEC-2026-0334"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "SEMVER",
              "events": [
                {
                  "introduced": "0.0.6"
                },
                {
                  "fixed": "0.0.11"
                }
              ]
            }
          ],
          "package": {
            "name": "bip322",
            "purl": "pkg:cargo/bip322",
            "ecosystem": "crates.io"
          },
          "database_specific": {
            "cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "source": "https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0334.json",
            "categories": [
              "crypto-failure"
            ],
            "informational": null
          },
          "ecosystem_specific": {
            "affects": {
              "os": [],
              "arch": [],
              "functions": [
                "bip322::verify_full",
                "bip322::verify_full_encoded",
                "bip322::verify_simple",
                "bip322::verify_simple_encoded"
              ]
            },
            "affected_functions": null
          }
        }
      ],
      "modified": "2026-10-09T08:15:18.366782769Z",
      "provider": "osv",
      "references": [
        "https://crates.io/crates/bip322",
        "https://rustsec.org/advisories/RUSTSEC-2026-0334.html",
        "https://github.com/rust-bitcoin/bip322/commit/e8accbe7d39f48f030e44f333b4796e28f6aad80"
      ],
      "provider_metadata": {
        "license": "CC0-1.0"
      }
    },
    "related_cves": [],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 111384,
  "published_at": "2026-08-14T12:00:00+00:00"
}