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

Pluginize permissions

Public commit record

What the developer wrote

Authored by Nicolas Dorier

18/100 · Opaque
Pluginize permissions
✓ Subject identifies a change! Too few words to establish purpose! No meaningful explanatory body! Opaque security-relevant change
The short version

What changed, and why it matters

This is a large refactoring commit that reworks how permissions are defined and enforced in BTCPay Server so that plugins can register their own permissions. It moves the permission hierarchy out of a hard-coded static class into a runtime service, changes how store context is tracked during requests, and updates authorization handlers. The change is architectural rather than a targeted security fix, but any mistake in the new permission logic could allow users to access stores or functions they should not.

Recommended action

Treat this as a high-risk refactor requiring focused review of authorization behavior. Verify that every endpoint previously protected by static policy checks still receives equivalent enforcement through PermissionService, that plugin-registered permissions cannot impersonate built-in policies, that store scoping still isolates cross-store access, and that the new navigation/current-store split does not leak store-scoped UI actions when the page context is null or different. Run the updated integration tests and add negative tests for plugin policy collisions and unscoped requirement bypasses.

Security signals we found

01

Large-scale authorization system refactor

02

Removal of static permission whitelist and policy map

03

Introduction of dynamic plugin-provided permissions

04

Change in store context propagation (GetNavStoreData vs GetStoreData, SetPreferredStoreId)

05

Authorization attribute change on ListStores from CanModifyStoreSettingsUnscoped to CanViewStoreSettings

06

New PolicyRequirement.RequireUnscoped flag added

07

Permission validation now uses regex rather than hard-coded list

Risk score

Why this scored 51/100

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