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

Add granular API permissions for on-chain wallets (#7357)

Public commit record

What the developer wrote

Authored by thgO.O

81/100 · Strong
Add granular API permissions for on-chain wallets (#7357)

* refactor(wallets): align greenfield routes with wallet policies

* fix(wallets): keep payjoin psbt unfinalized before request
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit introduces more fine-grained permission checks for BTCPay Server's on-chain wallet API. Previously, many wallet operations required broad 'modify store settings' or 'view store settings' permissions. Now, operations are gated by dedicated wallet permissions such as viewing wallet data, managing wallet settings, creating/signing/broadcasting transactions, and managing wallet transactions. The change also fixes a Payjoin bug where the PSBT was finalized before the Payjoin request, which could break Payjoin flows. Overall, this is a hardening/security improvement rather than an introduced vulnerability.

Recommended action

No immediate action required; this is a security-hardening change. Operators should review API keys after upgrading to ensure they grant the new wallet-specific scopes where needed, since old broad scopes may no longer suffice for some wallet endpoints.

Security signals we found

01

Authorization policy tightening from broad store policies to wallet-specific policies

02

New explicit permission checks in transaction creation endpoint

03

Payjoin PSBT handling bugfix: clone before finalize to keep Payjoin PSBT unfinalized until after request

04

Test coverage added for forbidden access scenarios under new granular permissions

05

Swagger documentation updated to reflect new required API key scopes

Risk score

Why this scored 40/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 6/15
Affected reach 8/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.