BTCPay Server

This commit is a user-interface redesign, not a security fix. It wraps existing server settings pages into consistent visual sections and adds short explanatory subtitles. No code handling payments, authentication, permissions, or data validation was changed.

This commit only updates user-facing help text in the Point of Sale plugin. It replaces outdated guidance about legacy API keys and Basic authentication with newer guidance about API tokens and the correct REST API endpoint. No code logic, authentication checks, or security behavior changed.

This commit refactors how BTCPay Server stores and handles API keys. Previously, the secret API key itself was used as the database primary key, meaning the full secret was stored in plaintext and appeared in URLs/revocation endpoints. Now the system creates a separate public 'key ID' (starting with 'akid_') derived from a hash of the secret, stores only a hash of the secret in the database, and uses the ID for management operations such as revocation. The change also removes the old BitPay 'Basic auth' legacy API key feature entirely. The commit is framed as a security hardening measure, but it is a large refactor rather than a single bug fix.

This commit changes how BTCPay Server stores and handles API keys. Previously, the secret API key itself was used as the database primary key and was stored in plaintext. After this change, the database stores a one-way hash of the secret, a short prefix for display, and a separate non-secret ID for management. The actual secret is only kept briefly in memory after creation and is then erased. The commit also removes an old BitPay-compatible 'legacy API key' feature that used Basic authentication with a plaintext key. These are defensive security improvements that reduce the damage if the database is stolen, but they do not by themselves fix an active vulnerability in running code.

This commit changes how BTCPay Server's plugin manager asks the plugin directory for update information. Previously, the server fetched the full catalog of plugins and then filtered locally. Now it sends a list of the plugins actually installed or pending on the local server and asks only for updates to those. This reduces unnecessary data exposure of the server's plugin inventory to the directory and may avoid bugs where pending or disabled plugins were not considered when checking for updates. It is a hardening/fix change rather than a clear-cut security patch, and the commit message does not claim it fixes a vulnerability.

This change fixes a bug where BTCPay Server's paid-subscription ('monetization') system could automatically re-enable an administrator account that had been manually disabled. Previously, when a subscription renewed or was bypassed, the monetization service would call SetDisabled(user, false) without knowing why the account was disabled. The patch adds a 'source' trail so monetization can tell whether it was the one that disabled the account, and it now suspends the subscription instead of overriding an admin lockout. In short: admin-imposed account lockouts can no longer be accidentally undone by billing automation.

This commit renames BTCPay Server's exchange-rate source from 'CryptoMarket' to 'Notbank'. It swaps the old provider code for a new one that calls Notbank's API, and adds a database migration that rewrites existing store settings so they continue to use the new rate source name. There is no indication this fixes a security vulnerability; it appears to be a routine rebranding/integration change.

This is a broad security patch for BTCPay Server 2.4.3. It fixes several access-control gaps (for example, lower-privileged store users could manage server admins or see sensitive API keys), hardens user-profile changes by requiring the current password, removes a third-party comment system (Disqus) that could inject scripts, adds rate limits to public invoice creation, stops plugins with known incompatibilities from loading, and tightens validation of Bitcoin transactions and multisig wallet setup. The changelog explicitly calls it a security release and recommends updating for multi-user servers.

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 is a hardening measure, not a direct bug fix. BTCPay Server now turns off username/password Basic authentication for its Greenfield API by default once an account is more than five minutes old. Users can re-enable it manually, but the safer default is to require API keys instead. The vendor describes this as a defense-in-depth follow-up to reduce the impact of other authentication bugs.

BTCPay Server fixed a bug where accounts protected only by TOTP-based two-factor authentication (the six-digit code from an authenticator app) could log into the Greenfield API using just their email and password, skipping the second factor entirely. The code previously blocked basic login only for users with FIDO2/hardware-key second factors, not for users with app-code (TOTP) second factors. The vendor says this was reported by Ben Carman and shipped as an emergency fix in version 2.4.2.

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.