BTCPay Server

This commit fixes a timing issue in BTCPay Server's automated test suite. It ensures that when a test triggers a browser alert dialog, the test waits for the dialog to actually be accepted before continuing. Previously, the test could proceed before the dialog handler finished, causing unpredictable 'flaky' test failures. There is no change to production code or user-facing security behavior.

This commit fixes a potential race condition in how BTCPay Server updates the status of a Payment Request. Previously, the code read the record, changed its status in memory, and saved it back. If two processes did this at the same time, one update could overwrite the other, possibly causing duplicate or missed events. The fix uses a single SQL UPDATE statement that only changes the status if it is different, then checks the result before publishing an event. The commit message calls this a 'possible race condition' but does not describe a specific security outcome.

This commit adds an 'Update' button for disabled plugins in BTCPay Server's plugin management page. It lets users update a disabled plugin directly from the disabled-plugins list instead of scrolling to the available-plugins section. The change also fetches all plugins unfiltered once and does search filtering in memory, and adds unit tests. There is no clear security bug in the diff, but the change touches plugin installation commands and identifier matching, which are security-sensitive areas.

This commit fixes an email-sending bug in BTCPay Server. When an administrator configured an SMTP relay that does not require a username or password, BTCPay was still trying to log in if the server said it supported authentication. That caused unnecessary 535 authentication errors and prevented emails from being sent. The fix simply skips login when both the Login and Password fields are empty. There is no security vulnerability here; it is a reliability/configuration fix.

This commit only changes a test file. It replaces some direct text equality checks with Playwright's built-in 'expect element to contain text' helper, which waits for the text to appear rather than checking instantly. The goal is to make a flaky (sometimes failing) test more stable. There is no change to production code and no security relevance.

This commit is a small cleanup in the BTCPay Server subscriptions plugin. It removes redundant assignments to the PreviousPlan property (which is now set only through the constructor), makes a property read-only, fixes a test to wait for an event, and corrects a namespace reference. There is no indication this fixes a security vulnerability.

This commit makes two small fixes in the BTCPay Server Subscriptions plugin. It changes a test helper so two UI form-filling branches are mutually exclusive, and it tightens when a subscription plan change can be scheduled and updates statistics when a plan actually changes. There is no clear security vulnerability in the diff itself; it looks like a routine bug-fix or code-review follow-up.

This commit is a code reorganization: the existing Forms feature is moved from the core BTCPayServer project into its own plugin folder. Files are renamed and namespaces adjusted, but the actual form logic, validation, and behavior remain essentially unchanged. There is no indication this change fixes or introduces a security vulnerability.

This commit adds a new feature to BTCPay Server's subscription plugin that lets users schedule a plan upgrade or downgrade to take effect at the end of their current billing period, instead of happening immediately. It also lets users cancel a scheduled change. The change is a normal feature addition and does not appear to fix or introduce a security vulnerability based on the code shown.

This commit fixes a store dashboard widget that displays wallet balance charts and numbers. The changes ensure chart labels are rendered correctly (especially the last data point) and convert API timestamps from Unix seconds into ISO date strings that the chart library expects. There is no security-relevant change.

This commit updates the .NET runtime and SDK Docker images used to build and run BTCPay Server from version 10.0.200/10.0.4 to 10.0.201/10.0.5. These are patch-level updates to the underlying Microsoft .NET platform. Such updates typically include bug fixes and security fixes, but the commit message does not say this is a security update and no specific vulnerability is referenced. The change is routine maintenance rather than a fix for a known, actively exploited flaw in BTCPay Server itself.

This commit only changes a single version number in a build file from 2.3.6 to 2.3.7. There is no code change, no bug fix, and no security-related content in the diff.

This commit fixes a privilege escalation bug in BTCPay Server's Greenfield API. Two authorization checks were passing 'null' instead of the actual store ID when verifying whether a user could auto-approve pull payments or payouts. In BTCPay Server's authorization system, a null resource likely causes the check to fall back to a global permission evaluation, meaning a user who only had permission on one store could potentially approve or auto-approve pull payments/payouts for other stores where they should have been denied. The patch simply passes the correct storeId so the permission is scoped properly.

This commit only updates the project's changelog file, adding one line describing a previously completed feature (wallet label filtering). It makes no code changes and has no security relevance.

This commit adds a search box to the wallet transaction label filter dropdown. When a wallet has more than 20 labels, users can now type to search instead of scrolling through a long list. It also shows how often each label is used and lists the 20 most popular labels first. There is no security-relevant change here.

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.