BTCPay Server

This commit changes what text BTCPay Server's API returns as the 'Label' for an on-chain wallet. Previously, if no custom label was set, the API would leak the wallet's technical derivation scheme (a string describing how keys are generated) as the label. Now it returns an empty string instead. This is primarily an information-disclosure cleanup, not a direct exploit.

This commit is a routine infrastructure change: BTCPay Server is switching its automated testing and release system from CircleCI to GitHub Actions. It copies the same test scripts, signing checks, and Docker publishing steps into GitHub Actions workflows. There is no change to the actual BTCPay Server application code that users interact with, and nothing in the commit suggests a security vulnerability was fixed or introduced.

This commit changes how BTCPay Server validates payment method settings so that the store object is passed into the validation process. The change itself only adds a new piece of information (the store) to validation contexts; it does not by itself fix a visible bug or block an attack. Without the rest of the related code, it is unclear whether this prevents a security issue or is just a refactoring/cleanup step.

This commit removes two contradictory sentences from an internal documentation file that tells contributors how to write pull request descriptions. One sentence had told them not to write about testing strategy, while another told them to add a testing note. The change only affects contributor guidance, not the BTCPay Server software that users or merchants interact with.

This is a tiny one-line change to a unit test helper that fetches cryptocurrency exchange rates from BTCTurk. It adds an extra sanity check: it ignores any exchange rate where the bid price (what buyers are offering) is higher than the ask price (what sellers are asking), because that is an impossible/inverted market state. The commit message says it is fixing a flaky test, not a security bug.

This commit rewrites how BTCPay Server performs host-level maintenance. Instead of the web application opening SSH connections directly to the host, it now runs a local helper program called 'btcpay-host'. The Docker image includes a wrapper that can still forward those calls over SSH, but the core application no longer needs SSH credentials or the SSH.NET library. The change removes a large amount of SSH-related code and adds a new plugin for maintenance actions. It is primarily an architectural/security-hardening change rather than a clear-cut fix for a single vulnerability.

This is a one-line change to a test file. It updates a test case that checks for a duplicate email error so that it also provides a current password. The change does not modify any production code and has no direct security impact on the BTCPay Server application itself.

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 only edits the wording of a changelog entry for BTCPay Server 2.4.2. It does not change any code, configuration, or executable files. The edit makes the release sound more urgent, but the commit itself is purely documentation and contains no security fix.

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 commit is a version bump and changelog for BTCPay Server 2.4.2. The changelog describes two security-related changes: disabling Basic authentication by default shortly after account creation, and fixing a TOTP two-factor authentication bypass when using Greenfield Basic authentication. The actual code fixes are not shown in this commit, so we can only see the vendor's description of the issues. The vendor rates these as 'not critical' but still recommends updating.

This commit only adds, removes, and reorders English text strings used for translations and user-interface labels in BTCPay Server. There are no code logic changes, no security settings being enabled or disabled, and no behavior changes. It is a routine localization/string update.

This commit updates several third-party software libraries and a test Docker image to newer versions. It also removes one library (AngleSharp) that was no longer needed. Dependency updates can fix security bugs in those external packages, but the commit message gives no details, and the diff itself does not show any direct vulnerability or attack path in BTCPay Server's own code.

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.

This commit is a user-interface redesign, not a security fix. It wraps store settings pages in new visual 'section' containers, updates headings and spacing, and adjusts CSS styling. No code behavior, permissions, or data handling changed.

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 adds a user-facing preference feature to BTCPay Server's wallet transactions table: a dropdown that lets users show, hide, and reorder columns. Preferences are saved in the browser's localStorage. The change is a routine UI enhancement and does not appear to be a security fix. There is no indication from the commit that the vendor considers it security-relevant.

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 fixes a bookkeeping bug in BTCPay Server's multisig (multi-signature) transaction tracker. Previously, a pending transaction could silently collect enough signatures to be finalized, but the system would still label it as 'Pending' until something else happened. The change makes the service automatically mark such transactions as 'Signed' whenever they are read, and it adds tests to confirm the state is corrected. There is no direct evidence this was a security vulnerability or that it was exploited; it appears to be a state-consistency fix.

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 commit is a minor code cleanup that simplifies how BTCPay Server writes log messages when a pending multi-signature transaction fails to finalize. It removes the list of failed input indexes from the log and merges two nearly identical log statements into one. There is no security-relevant change.

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 only adds more detailed logging when a pending multi-signature Bitcoin transaction fails to finalize. It does not change how transactions are validated, authorized, or executed. There is no security vulnerability being fixed here; it is purely an observability improvement for operators.