BTCPay Server

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 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 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 simply turns down the volume on log messages coming from BTCPayServer's security components. It changes the logging level from the default (likely Information/Debug) to Warning, so routine 'authentication scheme challenged' messages no longer fill the logs. There is no code behavior change, no bug fix, and no security vulnerability being patched.

This commit is a large code refactor that moves BTCPay Server's Bitpay-compatible API from the core application into a separate plugin. It relocates controllers, authentication, models, views, and middleware into a new Plugins/Bitpay folder, updates tests and dependency injection, and replaces the old middleware-based Bitpay API detection with a new endpoint selector policy. The change itself is structural rather than a targeted security fix, but any large refactor of authentication and routing code carries a risk of accidentally changing access-control behavior.

This commit is a routine code reorganization: it moves BTCPay Server's translation/localization code from the core server project into a dedicated 'Translations' plugin. The same dictionary-management features, language-pack download, and localization services are preserved, just relocated. There is no indication of a security fix or vulnerability being addressed.

This commit fixes a JavaScript crash in the subscription portal. When a user had a lifetime subscription, the page did not show an auto-renewal checkbox, but the script still tried to attach an event listener to it. That caused a browser error that blocked the rest of the page's JavaScript, making it impossible to upgrade or downgrade the subscription. The fix simply checks whether the checkbox exists before attaching the listener. There is no direct security vulnerability here; it is a functional bug with a minor denial-of-service-like effect on the UI.

This commit adds a feature that lets BTCPay Server administrators download and update language translation packs from a GitHub repository. The code fetches JSON translation files over the internet, stores them in the server's database, and tracks whether a newer version is available. There is no clear security bug in the diff, but the design introduces a supply-chain and server-side request risk that should be reviewed carefully.

This commit adds a new store setting that lets merchants type a short custom message shown on the checkout page. The text is limited to 500 characters, stored as plain text, and displayed using a safe Vue.js directive that escapes HTML. There is no obvious security bug in the change itself, but it is a new user-controlled text field rendered on a payment page, so it needs careful handling to avoid future misuse (for example, if someone later changes how the text is displayed).

This commit changes the WebAuthn/FIDO login JavaScript so that it now sends an extra piece of information, called the userHandle, to the server when a user logs in with a security key or passkey. The userHandle helps the server identify which account the credential belongs to. Without it, the server may have to guess the account from the credential ID alone, which can cause login failures or, in some FIDO implementations, allow a credential to be associated with the wrong account. The change is small and looks like a correctness fix rather than a full security patch.

This change adds speed bumps (rate limiting) to API logins that use username-and-password Basic authentication. It is a hardening fix: before, attackers could make unlimited rapid login attempts through the API; now those attempts are throttled after the account is more than five minutes old. The patch also improves error messages so the server can tell callers exactly why authentication failed, including when they are rate-limited.

This commit is a routine internationalization (i18n) refactor. It marks more user-interface text strings in BTCPay Server's web pages as translatable and updates the default translation dictionary. There is no security-relevant change to application logic, access control, cryptography, or data handling.

This change hides a dashboard widget called 'Lightning Services' from users who do not have permission to change server settings. Previously, the widget may have been visible to users who lacked those rights, potentially exposing links or information about server-level Lightning services. The fix adds a permission check directly to the widget's HTML wrapper so it only renders for authorized users.

This commit fixes a permission inconsistency in BTCPay Server. Previously, a user who had permission to create Lightning invoices for a store might not have had explicit permission to view those same Lightning invoices. The change makes 'view Lightning invoice' a child permission of 'create Lightning invoice', so anyone who can create them can also see them. This is described as a fix, not a new security vulnerability disclosure, and the diff alone does not show an active exploit or a disclosed incident.

This commit mainly adds the LUNO exchange as the default source for South African Rand (ZAR) exchange rates in BTCPay Server. It also includes a small hardening fix in another rate provider so that missing bid/ask values don't crash the app, plus a batch of unrelated test reliability improvements. There is no clear security vulnerability being patched.

This commit fixes a flaky automated test for the crowdfunding feature. The test previously cleared a date field by directly manipulating the webpage's internal value, which was unreliable. The change makes the test click a visible 'Clear' button instead, and adds an ID to that button so the test can find it. There is no security issue here.

This commit is a straightforward code reorganization: it moves the Point of Sale (PoS) user-interface files from a shared views folder into the dedicated Point of Sale plugin folder, and updates the corresponding file paths in the controller and plugin registration. There is no functional change to how the application behaves, and no security fix or vulnerability is introduced.

This commit refactors how BTCPay Server stores labels for payment requests, moving them from a wallet-based graph system into new store-scoped database tables. It also adds a new API endpoint for updating store-scoped labels. The changes are primarily a feature/refactoring effort, but they include security-relevant hardening such as CSRF token validation on the new update endpoint, a check that the target store exists and matches the route, and restrictions preventing deletion or renaming of reserved system label types. A migration copies existing payment-request labels into the new tables and removes the old wallet-graph entries.

This commit is a code reorganization: it moves the Crowdfund feature's files into a dedicated plugin folder and updates the controller to use newer ASP.NET Core patterns (primary constructor, area routing). It also makes a small change so that looking up a store for an app throws an exception if the store is missing, instead of returning null. There is no clear security fix or vulnerability being patched here.

This commit adds new API features to BTCPay Server so users can create unsigned Bitcoin transactions (PSBTs) and broadcast already-signed transactions through the Greenfield API. It is a feature addition, not a bug fix. The code does not appear to introduce an obvious vulnerability, but it changes how wallet transactions are authorized and signed, which is security-sensitive. There is no vendor statement or external report saying this commit fixes a security issue.

This is a small user-interface bug fix. When a user scanned a QR code with their camera to provide a PSBT (a partially signed Bitcoin transaction), the on-screen modal dialog failed to close for multisig transactions because the JavaScript was clicking the wrong button. The patch makes the code click the correct button so the modal closes as expected. There is no security vulnerability here.

This commit adds a CI safety check that refuses to build Docker images unless the current Git commit has a valid GPG signature. It is a hardening improvement, not a fix for an active vulnerability. There is no indication in the commit or title that it responds to a known security incident.