CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 30 Bitcoin

api: add BTCXpubsRequest to fetch multiple xpubs at once

BB0334a516 View source ↗
Public commit record

What the developer wrote

Authored by Marko Bencun

90/100 · Strong
api: add BTCXpubsRequest to fetch multiple xpubs at once

To reduce the number of secure chip operations needed, we introduce a
new API call to fetch multiple xpubs at once. This only requires two
operations in total, instead of two per xpub.

We want to reduce the number of secure chip operations to avoid
running into Optiga's throttling security measure.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a new device API that lets a host computer request up to 20 Bitcoin extended public keys (xpubs) in a single call, instead of making one call per key. The goal is to reduce how often the device talks to its secure chip, avoiding a throttling safeguard. The change itself is a feature addition, not a fix for a known vulnerability, and the code applies existing keypath validation and a double-check against bitflips.

Recommended action

Review the new xpubs handler for consistency with existing xpub export security policy, especially whether batch export should require user confirmation or rate-limiting. Verify that validate_xpub() correctly covers all accepted keypaths and that the 20-item limit is enforced before any secure-chip operation. No immediate patch is indicated by the diff alone.

Security signals we found

01

New API surface added for batch xpub retrieval

02

Existing keypath validation reused (validate_xpub)

03

Double-read of root xprv and double-derivation to mitigate bitflips/faults

04

Hard limit of 20 xpubs per request to bound resource use

05

No user confirmation required for xpub export (same as existing single-xpub API)

06

Commit explicitly states motivation is avoiding Optiga throttling, not a security bugfix

Risk score

Why this scored 30/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 5/15
Confidence 7/10
Evidence quality 3/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.

More from BitBox02 firmware

Related watches

Moderate 60 AI analysisMessage 90 · Strong
BB BitBoxBitBox02 firmware BitcoinHardware wallets

backup: validate decoded seed length

This update fixes a bug in how the BitBox02 hardware wallet reads backup files from an SD card. A tampered backup file could claim to contain a seed longer than the 32-byte limit, which previously caused the device to panic (crash) when li…

Out-of-bounds/panic condition in backup parsingMissing input validation on decoded protobuf fieldSD-card backup file could be attacker-controlled
80baf1eeby benma's agent+34−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 39 AI analysisMessage 73 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

rust: initialize C output buffers

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uni…

Undefined behavior at C/Rust FFI due to uninitialized buffers being treated as Rust slicesPotential optimizer-dependent behavior from violating Rust slice initialization rulesHardening of cryptographic output paths (SHA-256, HMAC-SHA256, HMAC-SHA512)
511018eaby benma's agent+52−2713 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 74 AI analysisMessage 78 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

eth: limit EIP-712 recursion depth

This commit adds a hard limit on how deeply nested Ethereum typed-message (EIP-712) structures can be when the BitBox02 hardware wallet signs them. Without the limit, an attacker could craft a message type that refers to itself over and ov…

Adds explicit recursion-depth cap to attacker-controlled input parsingPre-validates schema roots before host callbacks or user confirmationProtects against stack exhaustion / denial-of-service from deeply nested EIP-712 types
4ccadcc0by benma's agent+196−451 file
No security note in commit
Open full analysis →Source commit ↗