BTCPay Server’s latest security update asks Bitcoin merchants to review more than an application version. The project’s October 5 announcement of version 2.4.5, followed by its October 6 GitHub release, combines tighter controls with changes to the standard Docker deployment. Administrators are urged to update, while operators using Tor or affected optional integrations are told to review those changes first. Project announcement and release notes.
For a shop, a successful update should leave its payment workflow usable as well as current. The practical preparation is to identify which connections checkout depends on, who has permission to perform sensitive actions, and which optional services need to remain available.
Review outbound connections
Version 2.4.5 blocks private-network destinations by default for outbound HTTP requests used by Lightning connections, LNURL, invoice notifications and webhooks. The release notes describe this as protection against server-side request forgery, commonly shortened to SSRF. Outbound-request changes.
The concern is that someone able to configure a destination could make the payment server contact an internal service that the person could not reach directly. BTCPay’s operator guide identifies local applications, node interfaces and cloud metadata services among the resources such requests might expose. The same protection can also interrupt an intentional connection to a private webhook receiver or a service on a VPN. Operator guidance.
The documented remedy is a narrow exception for a needed destination. Hostnames must match exactly, and an exception without a port covers all ports on that destination. The guide also warns that exceptions apply across the protected HTTP features. That makes a broad permission more consequential than fixing one failed callback might suggest. Review the actual destination and required port instead of disabling the protection globally. Exception scope.
Consider a hypothetical store whose inventory system receives payment notifications on an internal network. An invoice may work while the inventory callback fails. Testing only the public checkout page would miss that dependency. This is an illustrative operational risk arising from the changed default, not a reported incident.
Check Tor and remote node access separately
The accompanying Docker changes make Tor opt-in, including for existing deployments after their next setup or update. The announcement says Tor remains supported and existing Tor volume data is preserved. Operators relying on an onion address need to select the Tor option explicitly using the project’s current instructions. It also lists retired integrations that should be checked before regenerating a customized deployment. Docker changes.
Remote Lightning administration involves a separate setting. The Docker networking guide says the optional LND REST and gRPC routes are disabled by default. Its route-management tool lets an administrator inspect and enable the required interface. The documentation advises using the least-privileged macaroon, the authorization credential used by the client, and protecting it as a secret. Networking guide.
A merchant using a remote node-management app should therefore verify its connection independently of customer checkout. An unnecessary public administration interface should stay closed; a required one needs deliberate configuration and appropriate credentials.
Recheck staff permissions
The release changes overpayment refunds so an employee lacking permission to create approved pull payments cannot automatically approve the refund. Another authorized user must approve the payout. It also adds a distinct permission for manually marking invoices settled or invalid. Permissions changes.
These changes suggest a straightforward acceptance test: have each staff role exercise the ordinary work it is expected to perform, and confirm that sensitive actions still require the intended authority. A blocked refund may reflect the new permission boundary. Granting every employee broader rights would undermine the reason for reviewing it.
Prepare recovery before the update
BTCPay’s Docker update guide says the process regenerates configuration and recreates the stack. Manual edits to the generated Compose file will be replaced. It advises backups and a review of release notes before significant upgrades, so customization should live in the supported persistent configuration. Update workflow.
Recovery deserves particular care when Lightning is involved. The backup documentation warns that restoring stale channel state can lose funds. It distinguishes routine backups from planned migration and says a Lightning restore test should be isolated from peers and the Bitcoin network. An old server snapshot should never be treated as a simple undo button. Backup and restore cautions.
After updating, the merchant’s final check should follow an order through invoice creation, payment detection and the business’s downstream notification process. Confirm remote access and Tor separately if they are used. The aim is a documented, working configuration whose exceptions and permissions can be explained when the next update arrives.