AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 51 Bitcoin

wire: skip IPv4-mapped IPv6 addresses in addrv2 messages

Public commit record

What the developer wrote

Authored by Erick Cestari

83/100 · Strong
wire: skip IPv4-mapped IPv6 addresses in addrv2 messages

This issue was discovered through differential fuzzing between btcd and
Bitcoin Core.

IPv4-mapped IPv6 addresses (::ffff:0:0/96, RFC 4291) sent with networkID
0x02 (IPv6) in addrv2 messages are now properly rejected. Per BIP155,
these addresses should use networkID 0x01 (IPv4) instead. This aligns
btcd's behavior with Bitcoin Core's addrv2 handling.

Changes:
- Add ipv4MappedPrefix constant for the ::ffff:0:0/96 prefix
- Add isIPv4Mapped() helper function to detect these addresses
- Update readNetAddressV2() to skip IPv4-mapped addresses with IPv6 networkID
- Add comprehensive test coverage for IPv4-mapped address detection
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a network-address handling bug in btcd, a Bitcoin implementation. When another node sent an IPv4 address disguised as an IPv6 address inside newer 'addrv2' peer messages, btcd would accept it. The change makes btcd reject those mismatched addresses, matching the behavior of the main Bitcoin Core software. This prevents inconsistent address records from spreading between nodes and avoids potential confusion or attacks that rely on address format tricks.

Recommended action

Apply the patch and ensure nodes are upgraded. Monitor for any peer behavior changes in addrv2 handling; no immediate incident response is required beyond normal patching.

Security signals we found

01

Protocol conformance fix for BIP155 addrv2 address encoding

02

Rejection of IPv4-mapped IPv6 addresses sent under wrong network ID

03

Differential fuzzing discovery against Bitcoin Core

04

Potential peer-to-peer address relay inconsistency / de-anonymization vector

05

No memory corruption or cryptographic weakness evident

Risk score

Why this scored 51/100

Our methodology →
Potential impact 12/30
Exploitability 10/25
Stealth signal 8/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.