BTCPay Server

This commit fixes a broken access control bug in BTCPay Server's form feature. Previously, when checking whether a user could view a private form, the system asked 'Is this user allowed to view store settings anywhere?' without specifying which store. That meant any user with store-settings permission for any store could see private forms belonging to other stores, and could potentially create invoices against those stores. The patch changes the authorization check to include the specific store ID of the form, so users must have permission for that exact store.

This commit simply re-adds a helper method called GetAppData that retrieves application data from a web request. It throws an error if the data is missing. There is no indication of a security fix or vulnerability in this change.

This is a one-line bug fix that prevents a file-move operation from failing when a destination file already exists during plugin installation. The change makes the system overwrite the existing manifest file instead of throwing an error. It appears to be a stability fix for a rare edge case rather than a security vulnerability.

This commit improves how BTCPay Server figures out whether a crash was caused by a third-party plugin. It adds a new check that inspects the crash's stack trace to see if any loaded plugin's code appears in it. This is a defensive reliability improvement, not a fix for an active security vulnerability. It helps the server better identify misbehaving plugins so they can be disabled or reported, reducing the chance that a bad plugin causes repeated outages or unexpected behavior.

This commit updates several third-party software libraries and the underlying .NET runtime image used by BTCPay Server. Library and runtime updates often include routine bug fixes and security patches, but the commit message does not say any specific vulnerability was being fixed. Without a vendor security advisory or changelog reference, we cannot confirm this is a security patch, though it is a common way projects keep dependencies secure.

This commit only updates the default translation file for the BTCPay Server application. It adds, removes, and modifies user-facing text strings (for example, labels like 'API Key Analysis', 'Never Used', and 'Used Permissions'). There are no code logic changes, no security fixes, and no changes to how the application behaves or protects data.

This commit is a large cleanup/refactoring change that removes unused code, simplifies controllers, and updates tests. It also removes the temporary file URL feature entirely. There are a few small security-relevant changes, such as switching pull-payment lookups to use context data set by an authorization filter and removing explicit store-id checks in some actions, but these appear to be moving checks into a shared filter rather than removing them. The commit title and message do not describe this as a security fix.

This commit is a user-interface fix for the BTCPay Server dashboard on mobile devices. It simplifies how the wallet balance widget is rendered, removes a multi-column dashboard layout, and makes the default cryptocurrency optional. There is no security-relevant change.

This commit adds a new feature that tracks which permissions each API key actually uses and shows the owner a dashboard of used, unused, and stale permissions. It is a security-hardening and visibility improvement, not a fix for an active vulnerability. The change also deletes usage records when an API key is removed.

This commit is a large internal cleanup that renames and unifies how BTCPay Server looks up store, invoice, app, and payment-request data from the HTTP request context. The main visible change is that many controllers stop manually checking the database for a store/invoice and instead rely on data that an authorization filter already placed in the request context. The commit also adds route-to-store mappings for paymentRequestId and pullPaymentId, and adds a new test that verifies a user with view-only invoice permission cannot read an invoice belonging to a different store. While the change is mostly defensive, it is also risky: if the authorization filter ever misses a route or a controller action is reachable without the filter, the controller may assume it has a valid store/invoice when it does not, which could lead to null-reference crashes or, in the worst case, cross-store data access.

This commit removes unused C# 'using' statements (imported namespaces) and one unused Razor view import across 372 files. It is a code-cleanup change with no functional modifications. The only non-cleanup hunk is a tiny refactor in GreenfieldInvoiceController.UpdateInvoice that reorders an existing null check and variable assignment without changing behavior.

This commit is a code-quality and null-safety refactor. It makes the helper that retrieves the current store from an HTTP request return null when no store is set, adds a separate throw-on-null variant, and updates many controllers to use the appropriate variant. It also switches invoice lookups to use a context item set by an authorization filter. The changes reduce the chance of accidental null-reference crashes and make authorization checks more centralized, but the commit itself does not describe a specific security bug being fixed.

This is a large internal code cleanup that replaces calls to ASP.NET Core's UserManager for getting the current user's ID with a new direct helper that reads the value from the user's identity claims. Most changes are mechanical refactors across many controllers and views. There are a few small behavior changes worth watching: the new helper returns an empty string instead of "???" for missing users, some places now treat a missing user ID as a validation failure rather than passing it through, and a couple of user-not-found cases now return NotFound instead of throwing an exception. The commit does not describe itself as a security fix and no external advisory is provided.

This commit fixes how BTCPay Server's navigation bar decides which store's permissions to use when showing or hiding menu items. Previously, the permission checks inside the navigation bar could accidentally use the store from the main page (for example, the server settings page) instead of the store selected in the navigation bar. This could cause menu items to be shown or hidden incorrectly. The change makes the navigation bar temporarily switch to the correct store context while it renders, and removes a caching shortcut that could reuse the wrong permission result. There is no direct evidence in the commit message or diff that this was exploited or reported as a security vulnerability.

This commit fixes a small bug where a special permission claim was being added to a user's identity every time it was transformed, instead of only once. Repeated claims are harmless in most cases, but could in theory cause the identity to grow unexpectedly or lead to subtle authorization behavior. The fix checks whether the permission claim already exists before adding it again.

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.

This commit only changes test code. It fixes a minor indentation issue and adds a test category label so that an existing test called CanUsePairing is run as part of automated browser-based (Playwright) testing. There is no change to production code, no bug fix, and no security relevance.