BTCPay Server shipped version 2.4.5 on October 5, 2026, with the GitHub tag landing the following day, lead developers Nicolas Dorier and Pavlenex confirmed in the project's release notes.

What does the SSRF fix actually do?

The headline security change addresses Server-Side Request Forgery, a vulnerability class in which an attacker tricks a server into issuing outbound requests on their behalf. BTCPay has added outbound-destination filtering on Lightning and LNURL requests, plus the webhooks merchants configure to react to invoice events, reducing the risk that internal services will receive traffic they were never meant to see.

The server now rejects connection attempts to private and loopback ranges by default and lets administrators expand that allow-list deliberately. That posture matches how payment-rail products have handled callback hygiene since the broader industry tightened webhook practices in 2022 and 2023.

Why is Tor behavior changing?

Tor support now defaults to off after each update. Operators who host stores over an onion address must manually re-enable the service in server settings, a change the project describes in the release notes as a deliberate opt-in for deployments that need it rather than a feature every install inherits.

Stores running on clearnet see no interruption. Stores that depended on an onion mirror will see the service go dark at the moment of upgrade and need to flip a single configuration toggle to bring it back.

What changed for refunds and invoice privacy?

Refund approval permissions are tighter in 2.4.5. The release restricts which staff accounts on a multi-user store can authorize outgoing funds, narrowing the insider-risk surface and limiting damage from a compromised administrator credential.

Public invoice pages now hide their details one month after issuance, the release notes state. Payment links that once broadcast payer information indefinitely now expire their public view, capping a low-grade but persistent data leak that long-lived BTCPay invoices have historically created.

What else landed in 2.4.5?

• Invoice generation received performance work aimed at reducing latency on freshly created payment requests.
• Docker deployment scripts received what the project called a meaningful cleanup, pruning legacy container layers.
• Bitcoin Plus, Trezarcoin, and JoinMarket integrations were retired as no longer actively maintained by their respective communities.
• A new btcpay-routes administrative command exposes granular control over Lightning API routes.
• Greenfield, BTCPay's external API surface, shipped new endpoints and breaking changes documented in the GitHub release notes.
• Plugin Builder registration reopened with sandboxing improvements that isolate plugin execution from the host process.

What should operators do first?

Administrators should pull the update through the server's settings menu, then verify their Tor configuration if they previously relied on an onion endpoint. Stores running custom plugins or scripts against older behavior should consult the breaking-changes section of the GitHub release notes before upgrading production deployments, the project advises.

The tighter refund policy matters most for stores with delegated staff access, where approved roles now explicitly exclude broader team members from initiating returns without elevated credentials.

How does 2.4.5 fit the release cadence?

Version 2.4.5 follows 2.4.4 in September 2026 and 2.4.2 in August 2026, both weighted toward security work. Three successive security-led releases inside roughly ten weeks signal a focused hardening cycle ahead of any larger feature push on BTCPay's merchant-stack roadmap.

The next maintenance window will likely arrive within six to eight weeks unless an out-of-band disclosure forces a faster patch.