BTCPay Server's October 19 Fix Isn't in the Release You're Running
A permission-tightening merge landed in BTCPay Server's codebase on October 19, but the newest tagged release predates it. That means store-scoped API keys can still reach further than merchants think, and the people most exposed are the ones who chose self-custody precisely to avoid this kind of surprise.
The patch is in the repository. It isn't in the release you're running.
BTCPay Server merged a change on October 19 that narrows how store-scoped API grants behave. The problem is timing. The newest tagged release still predates that merge. So anyone who pulled the latest listed version and issued an API key scoped to a single store may be handing out more reach than they intended. A key that says "this one store" can, in practice, touch more than that.
That's not a hypothetical for a self-hosted payment processor. BTCPay's entire pitch is that you keep the keys, you keep the node, you keep the books. Merchants who set it up did so because they didn't want a third party deciding who can move what. Store-scoped keys are the mechanism that makes that promise hold at the team level. One key per storefront, one set of permissions, nothing bleeding across. When the scope leaks, the wall between a merchant's stores stops being a wall and becomes a suggestion.
Small operators carry the risk here. Picture a Dubai merchant running three storefronts on one instance, one for retail, one for wholesale, one for a side venture, with a contractor holding a key to just the wholesale one. That merchant isn't running a security team. They're running a business, and they trusted the label on the key.
Worth drawing the line clearly. The licensed custodians in DIFC and ADGM aren't the exposed group. They don't self-host. The exposure sits in the long tail of merchants who took the harder path on purpose, and that's the group least likely to be reading merge logs.
The fix itself is narrow: constrain what those grants can do at creation. Straightforward. The gap is release lag, and release lag is the part that bites. Merges always run ahead of tags. That's true in every open source project and it isn't going to change.
Here's the thing about self-custody. It's a responsibility, not a feature. If you're running BTCPay and you've issued store-level API keys, go look at them today. Check the scopes, rotate anything you can't account for, and put an IP allowlist in front of the endpoints that move money. The merge will ship in a release. Until it does, the documentation is ahead of the software, and that's a bad place to be standing.