BTCPay Server

This commit marks several public methods on ASP.NET Core controllers with [NonAction], which prevents them from being exposed as web-accessible HTTP routes. Without this attribute, these helper methods could be reached directly via URL, potentially allowing users to bypass intended workflows, access internal logic, or trigger actions that were only meant to be called by other controller code. The change is a hardening fix rather than a clear-cut exploit patch, because the diff alone does not show that any of these routes were actually reachable or dangerous in practice.

This change makes BTCPay Server's Greenfield API stop accepting username-and-password 'Basic' authentication by default for existing users. New accounts can still use it for only the first five minutes after creation to set up an API key. After that window, Basic auth is blocked unless the user explicitly turns it on in their profile. The goal is to reduce the risk of password-based attacks on API access.

BTCPay Server fixed a bug where accounts protected only by TOTP-based two-factor authentication (2FA) could access the Greenfield API using just an email and password, skipping the second factor. The change now blocks Basic authentication for any account that has any form of 2FA enabled, not just those using FIDO2 security keys. The vendor calls this a critical vulnerability under active exploitation and urges immediate upgrades.

This commit changes how BTCPay Server decides whether a Bitcoin transaction input is a SegWit (witness) type when building PSBTs (Partially Signed Bitcoin Transactions). Previously the code only recognized three specific SegWit formats: native SegWit pay-to-pubkey-hash, native SegWit pay-to-script-hash, and Taproot. The new code uses a broader check that covers any script type classified as a witness script, including possible future SegWit versions. It also adds calls to fill in the 'witness UTXO' field in two wallet controller flows that previously did not do so. The practical effect is to make PSBTs more complete and compatible with future Bitcoin upgrades, and to reduce the chance that a wallet or signer will fall back to less secure non-witness data handling.

This commit removes a single line that automatically added witness UTXO data to SegWit inputs when decoding a PSBT. The change is titled 'Preserve imported PSBTs,' suggesting the previous behavior was modifying user-supplied transaction data in an unwanted way. Without more context, it is unclear whether this is a security fix or a functional/data-integrity change. The removed operation could, in some PSBT workflows, alter the information a hardware wallet or signer sees, which can affect how transactions are validated or signed.

This commit changes BTCPay Server so that when it builds or decodes Partially Signed Bitcoin Transactions (PSBTs), it explicitly adds a compact 'witness UTXO' record for any SegWit inputs. Previously, some SegWit PSBTs may only have carried the full previous transaction (non-witness UTXO). Adding the witness UTXO improves compatibility with hardware wallets and signers that require or prefer it, and can reduce the data those devices need to process. The change itself is a correctness/compatibility improvement rather than an obvious vulnerability fix, but the absence of witness UTXOs in SegWit PSBTs can cause signing failures or force fallback behaviour in some wallets.

This commit is a follow-up code review patch for BTCPay Server's pending Bitcoin transaction (multisig) signing feature. It tightens when the service logs a warning versus a debug message after a failed finalization attempt, and it removes an unused optional parameter from an internal helper method. The changes are defensive: they reduce false-warning noise and make the per-input signature tracking more accurate. There is no direct evidence in the commit of an exploitable vulnerability being fixed.

This change tightens how BTCPay Server stores signature attempts for multi-signature Bitcoin transactions. Previously, every submitted PSBT (a partially signed transaction file) was kept in history, even if it added no real progress. Now only PSBTs that actually advance signing or successfully finalize the transaction are retained. This prevents unbounded growth of stored signature history, which could waste storage and potentially be abused to clutter or inflate a pending transaction record.

This commit fixes a bug in BTCPay Server's multisig transaction handling. Previously, the service could get stuck in a 'Pending' state even when enough valid signatures had been collected, because it discarded new signature submissions that didn't immediately improve progress and didn't retry finalizing the transaction. The fix keeps distinct-but-not-yet-helpful PSBTs (partially signed transactions), records them, and retries finalization each time a new PSBT arrives, allowing later valid signatures to complete the transaction.

This commit changes how BTCPay Server stores invoice comments and metadata. Previously, comments were saved in a separate field and could be updated with a method that was not safe when multiple requests happened at the same time. The patch moves comments into the invoice metadata and uses database-level JSON operations to update only the requested field, reducing the chance that simultaneous updates overwrite each other. It also removes the dedicated 'comment' field from the public API, so comments can only be updated through the UI or via metadata. The commit title explicitly calls this a race-condition safety fix.

This commit refactors BTCPay Server's plugin management into a dedicated plugin and adds an embedded plugin directory that loads content from an external plugin catalog via an iframe. The change moves plugin URLs from the server settings area to a new plugin area, adds URL sanitization for author and documentation links, and introduces checks to prevent installing mismatched plugin identifiers. It is a feature/refactoring commit rather than a disclosed security fix, though it includes some defensive hardening.

This commit adds a feature that lets BTCPay Server users import wallet labels from a BIP-329 file. The code parses uploaded JSONL files, validates entries, and attaches labels to transactions, addresses, or transaction outputs. The change is a normal feature addition; there is no direct evidence in the commit that it fixes a security vulnerability, but it does introduce a new file-upload and parsing path that should be reviewed for robustness.

This commit adds right-to-left (RTL) language support to BTCPay Server. It introduces metadata tracking for whether a language is RTL, fetches that flag from the translation manifest, stores it in the database, and switches the user interface to RTL-specific CSS stylesheets when an RTL language like Arabic is active. There is no security issue visible in the change.

This commit is a routine UI refactor: it renames the internal ASP.NET Core view component from <vc:breadcrumb> to <vc:title-header>, updates CSS class names, and standardizes how page titles are set across many Razor views. There is no security-relevant change in behavior—no new endpoints, no permission changes, no input handling changes, and no fixes for injection or bypass issues.

This commit is a routine user-interface cleanup. It replaces many copies of hand-written breadcrumb navigation HTML across the application with a single shared 'Breadcrumb' view component. There is no security-relevant change here—only the way page headers and navigation links are rendered.

This commit adds a new editable comment field to BTCPay Server invoices. Store staff can add private notes to invoices through the web interface or API, and these comments appear in invoice reports. The change is a normal feature addition, not a security fix. There is no indication in the commit that it addresses any vulnerability or security incident.

This change is purely a user-experience improvement: when a BTCPay Server user is denied access to a page, the 403 error page now tells them which specific permission they are missing. It does not alter who can access what, nor does it fix or introduce any security vulnerability. It simply makes the denial message more informative.

This commit adds a new optional 'tax on tips' feature to BTCPay Server's Point of Sale app. Merchants can now configure a separate tax rate that applies to customer tips, and the receipt/cart display breaks out the tip tax separately from regular item tax. There is no indication this is a security fix; it is a normal business-logic feature addition.

This commit removes the 2FA recovery-code feature from BTCPay Server. Recovery codes are normally printed when you enable two-factor authentication and used as a backup way to log in if you lose your phone. After this change, users can no longer create or use those codes. The commit does not add a replacement backup login path, so anyone who loses access to their authenticator app may be permanently locked out of their account unless they have another login method configured. The change is presented as a feature removal, not as a fix for a specific security bug.

This commit adds passkey (passwordless) and login-code login support to BTCPay Server and rewrites much of the existing two-factor/FIDO2/LNURL-auth login flow. It is a large feature patch, not a documented security fix. The changes introduce several security-relevant design choices: passkeys can bypass the password entirely, session state now carries the login method and return URL, and the migration forces TwoFactorEnabled=true for all users while adding a separate AuthenticatorEnabled flag. Because the patch is broad and partially refactored, there is a non-trivial risk of authentication bugs (e.g., bypasses, session confusion, or incorrect 2FA enforcement), but the supplied diff does not show an obvious exploitable vulnerability.

This commit adds a new feature that lets server administrators set a maximum number of stores each non-admin user can create, both globally and per-user. It is a new restriction/control feature, not a fix for an existing vulnerability. There is no evidence in the commit or supplied references that this change addresses a security incident or was disclosed as security-relevant.

This commit restructures several user-interface pages so that payment requests, pull payments, invoices and apps no longer live under a '/stores/{storeId}/...' URL path. Instead they use flatter routes such as '/payment-requests/{id}/edit'. The change also updates the authorization layer so that when a store-scoped route is missing but an object ID is present, the system can fail the request with a 403 rather than letting the action itself silently return a 404. Several tests were updated to expect 403 instead of 404 for missing objects, and some permission-guard tests were removed or changed. The commit is described by the author as a UI route cleanup, not as a security fix, but it does touch access-control code.

This commit adds a new merchant setting that lets a store choose whether entered prices already include sales tax or whether tax should be added on top. It updates the Point of Sale screens, order calculation logic, and tests. There is no indication in the commit that this fixes a security vulnerability; it appears to be a normal feature addition for tax handling.

This commit adds a server-side translation manager to BTCPay Server and, in the process, fixes several security-relevant bugs. The most important fix is that downloaded language packs are now verified against a SHA-256 hash from a manifest, preventing a corrupted or tampered translation file from being accepted. The commit also adds server-side guards so built-in or currently-selected translations cannot be uninstalled by a crafted request, restores a typed 'Delete' confirmation before removing custom translations, and redirects old URL paths to new ones so existing integrations keep working. Most of the change is a feature refactor (renaming 'dictionaries' to 'translations' and moving to a manifest-based system), but the security hardening is explicitly described in the commit message and diff.

This commit adds a new server-admin-only option called 'Bypass monetization.' When a BTCPay Server instance charges users for subscriptions, admins can now mark specific invited or existing users so they do not need a paid subscription to log in. The change is intentional and exposed through the admin UI; it does not appear to be a hidden backdoor. There is no direct evidence in the commit that it fixes a security bug or introduces a vulnerability, but any feature that lets an admin exempt users from billing controls should be reviewed for authorization and audit-trail completeness.