What to know

  • Outbound HTTP requests block private-network destinations by default.
  • Legitimate private services need narrowly configured exceptions.
  • Refund and invoice permission changes require end-to-end operator checks.

The release changes two important boundaries

BTCPay Server’s 2.4.5 release, published on 6 October 2026, blocks private-network destinations by default for several outbound HTTP features to reduce server-side request forgery risk. The notes also tighten refund approval and invoice-related access behavior. Operators using intentional private services are directed to configure exceptions. This is a release report based on the project’s own notes. It does not establish that any particular merchant was attacked or that a private-network integration is inherently illegitimate.

Why a payment server’s outbound access matters

A server may be allowed to reach systems that a public visitor cannot. If user-controlled settings can influence its destination, that difference can become a security boundary. Our interpretation is that destination validation should be reviewed as a form of authority: who may cause the server to connect, where it may connect and what response information is exposed. Treating a URL as ordinary text misses the network access that processing it may authorize.

Exceptions need a clear business owner

Some installations deliberately connect a payment server to private infrastructure. A default block can therefore reveal a legitimate dependency during an upgrade. The safe response is to identify the exact required destination and document why access is needed. A broad exception that recreates unrestricted private-network access weakens the point of the control. Configuration review should include naming, redirects and the identity responsible for maintaining the exception, using the project’s current documentation for supported syntax.

Test the money movement and the permission check

Refunds deserve more than a visual check that a button appears. An operator should verify which role can request, approve and execute the action, and confirm that unauthorized roles are rejected. Invoice visibility should be checked with an unauthenticated request as well as a staff account. These are defensive test recommendations for systems the operator controls. BijliCoin has not run them against this release and does not provide an exploit recipe or instructions for probing another merchant.

A useful post-upgrade record

The most useful evidence would combine the installed version, successful checkout and notification tests, a review of necessary network exceptions and checks of refund permissions. Preserve that evidence without exposing customer invoices, credentials or financial records. The release improves defined boundaries; it does not replace operating-system updates or a merchant’s authorization policy. Readers should follow the official upgrade guidance and review deployment changes associated with their packaging. The practical news is that this update requires attention to both security defaults and the legitimate workflows those defaults can affect.

Sources and reading

Editorial note: AI-assisted original BijliCoin synthesis. Original BijliCoin synthesis of the linked public primary source. Defensive recommendations are editorial interpretation, not a claim of hands-on testing. No exploit procedure is provided. Illustration is conceptual.

Sources & context

  1. BTCPay Server 2.4.5 official release ↗

See our editorial policy or report a correction.