Key takeaways
- BTCPay Server merged PR #7684, 'Enforce API key permission scope', on 19 October 2026 - but the latest release remained 2.4.5, published 6 October, which predates it.
- That gap lasted seven days. Version 2.4.6 shipped on 26 October at 14:25 UTC and its release notes confirm #7684 is included.
- During the gap a diligent operator running the newest release did not have the fix and could not get it except by building from master.
- The fix constrains restricted keys; the PR states existing unscoped administrator keys keep their current behaviour, so updating alone does not re-scope a key already issued.
- 'Am I on the latest release?' is the wrong question for self-hosted software holding money. The right one is whether the latest release is newer than the last security-relevant merge.
There are three gates between a security fix existing and you being safe from the thing it fixes.
Merged - the code is in the repository. Released - the code is in a version you can install. Installed - you are actually running it.
Coverage of security fixes almost always reports the first gate. Readers almost always hear the third. The distance between them is where the losses happen, and this week produced an unusually clean example of each failing.
What BTCPay merged, and when you could get it
On 19 October, BTCPay Server merged pull request #7684, "Enforce API key permission scope", authored by Kukks and merged by Nicolas Dorier into the master branch.
The change is easy to state. An API key scoped to a single store could reach server-wide or account-wide functions when its owner happened to be a server administrator. After the change, as the PR puts it, API keys stay within the authority they were granted - a restricted key cannot borrow its owner's wider privileges, and cannot mint a broader key for another user.
For a merchant, the practical shape of that is delegating more authority than intended. You issue a key for one store to an integration, a plugin, an accountant's tool. You believe you have handed over one store. If your own account is an administrator, you may have handed over more.
Here is the part that matters. BTCPay's latest release remained 2.4.5, published 6 October - twelve days before the fix was merged, and therefore without it. The fix existed, was public, and was reviewed. It was not in anything you could install.
That gap closed today. Version 2.4.6 was published on 26 October at 14:25 UTC, and its release notes list the API key item citing #7684 directly. Seven days between merge and release.
Why seven days is the interesting number
Nothing here suggests bad practice by BTCPay. 2.4.6 is a substantial security release - it also updates .NET and the container trust store for a Brotli decoder vulnerability, distrusts certificates affected by a certificate authority key compromise, hardens store permissions and handling of untrusted input, and makes logout require a POST request. Bundling those into one tested release is the responsible way to ship, and testing takes time.
The problem is not the delay. The problem is that the delay is invisible to the person exposed by it.
You can audit the third gate yourself in about four seconds: check the version in your footer. Auditing the second gate means reading a repository's merge history against its release tags and forming a judgement about which merges were security-relevant. Essentially nobody self-hosting a payment processor does that.
So during those seven days an operator could do everything right - check for updates, install the newest release, verify the version string - and still not have the fix. Diligence did not help. The only routes were building from master, which most merchants will not and arguably should not do, or waiting without knowing you were waiting.
That asymmetry is the lesson, and it generalises to every piece of self-hosted software that touches money.
The other direction: a patch that existed and was not installed
The same week offered the mirror image, and a caution about how to reason from it.
Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, were disclosed on 21 October, with fixes released. A bounty challenge then invited people to steal Bitcoin from a deliberately exposed PHP server. A researcher known as Killa succeeded on 25 October at 15:47 UTC, and the organiser, James Pavur, confirmed the solve from server logs.
Read carefully, though, what that does and does not establish. The flaws were already patched. One report says the box ran a PHP build predating the 21 October fixes, chosen deliberately. The organiser had initially served ordinary HTML, which kept attackers away from the vulnerable functionality, and only added an accessible PHP page at around 13:00 on the day - under three hours before the successful attack. The stored wallet key turned out to be from a different wallet branch, so the winner could not claim the prize directly and was paid manually.
So the demonstration is that an already-fixed flaw is exploitable on an unpatched machine once you can reach the vulnerable surface. That is worth knowing - it converts "theoretically exploitable" into "demonstrably exploitable" - and it is a much narrower claim than some of the coverage implies.
The ethical hacker Mohan "s1r1us" Pedhapati called the framing around it "a very dangerous narrative", on the grounds that treating a messy challenge as evidence could lead people to delay patching. That caution cuts both ways, and it is the right one. A badly configured challenge is weak evidence that a flaw is dangerous, and equally weak evidence that it is overhyped. Neither conclusion should change your patching schedule.
The question to ask instead
If you run self-hosted software that holds funds, "am I on the latest release?" is not the question. It is necessary and it is not sufficient, because it cannot detect a fix that has not been released.
The better question: is the latest release newer than the most recent security-relevant merge?
That is checkable without being a developer. Open the project's releases page, note the date of the newest release, then look at merges to the main branch since that date and see whether any of them read like security work. If the answer is yes, you are in a gap, and you now know something you could not have known from your version string.
For BTCPay operators today, concretely:
Update to 2.4.6. It carries the API key fix and several unrelated security items.
Expect one breaking change. The legacy per-invoice notification email option has been removed, so check whether any workflow depends on it before you update rather than after.
Re-examine keys you have already issued. This is the part most likely to be missed. The PR states that existing unscoped administrator keys keep their current behaviour. The fix constrains what a restricted key can do; it does not retroactively narrow a key that was never scoped. If you shared credentials with an integration while an administrator, updating does not undo that grant - reissuing it does.
None of this is specific to Bitcoin software. It is the same structure as the disclosure-timing question Bitcoin Core reopened this month, where the gap between a fix existing and users running it is exactly the window an embargo is meant to protect. And it rhymes with extensions being removed from a store, which also changes nothing for the person already affected. In each case the announcement and the remedy are different events, separated by time that nobody reports.
What I checked, and what I did not
I verified the pull request, its merge date, the release tags and the 2.4.6 release notes directly against the repository rather than taking them from coverage. That matters here, because the two outlets reporting that BTCPay's latest release still predated the patch were accurate when they published this morning and were overtaken within hours by 2.4.6.
That is not a criticism of them. It is the thesis: patch-status reporting goes stale faster than patches ship, which is another reason to check the repository rather than the headline.
I have not tested the vulnerability, I am not describing how to exploit anything, and I am not in a position to say whether the API key issue was ever used against anyone. This is not security advice for your specific deployment, and it is not investment advice either.
Frequently asked questions
What was the BTCPay API key problem?
An API key scoped to a single store could reach server-wide or account-wide functions when the key's owner was a server administrator. PR #7684, 'Enforce API key permission scope', changes that so keys stay within the authority they were granted, and a restricted key cannot create a broader key for another user.
Was there a period when operators could not get the fix?
Yes. The fix was merged on 19 October 2026, but the latest release remained 2.4.5 from 6 October, which predates it. Until 2.4.6 shipped on 26 October at 14:25 UTC, the only way to have the fix was to build from the master branch.
Does updating to 2.4.6 fix keys I already issued?
Not entirely. The pull request states that existing unscoped administrator keys keep their current behaviour. The change constrains what restricted keys can do rather than retroactively narrowing a key that was never scoped, so credentials already shared with an integration should be reissued rather than assumed fixed.
Is this the same as the BTCPay incident in August?
No, and they should not be conflated. August concerned a separate LND macaroon flaw fixed in 2.4.2 on 7 August, which was actively exploited to steal funds from servers running earlier versions. The October item is an API key permission scope issue with no reporting that it was exploited.
What did the PHP Bitcoin challenge actually prove?
That an already-patched flaw is exploitable on an unpatched server once the vulnerable surface is reachable. The CVEs were disclosed and fixed on 21 October, the organiser only added an accessible PHP page hours before the solve, and the prize key was stored from the wrong wallet branch. It is a narrower result than some coverage suggests.
What is the practical check to run?
Compare the date of the project's newest release against merges to its main branch since that date, and see whether any look like security work. Your version string can tell you whether you are current; only that comparison can tell you whether being current is enough.
Sources
Every figure and quote above traces to one of these. Checked on publication day.
- github.com — Pull request #7684, Enforce API key permission scope - btcpayserver/btcpayserver
- github.com — BTCPay Server release v2.4.6 - GitHub
- cryptoslate.com — BTCPay's API key fix is merged, but its latest release still predates the patch - CryptoSlate
- thecurrencyanalytics.com — BTCPay API Key Fix Merged, Release 2.4.5 Lags Behind - The Currency Analytics
- cryptoslate.com — Bitcoin hacking challenge finally falls as researcher proves critical PHP flaw is exploitable - CryptoSlate
- blog.btcpayserver.org — Security Advisory: Update BTCPay Server to 2.4.2 Immediately - BTCPay Server blog
Deepmoni Das, Editor
I read the primary filings, exchange notices and post-mortems behind each story and write up what they actually say — with every source linked so you can check me. I am not a trader and I do not hold positions in anything covered here. Research and drafting are AI-assisted; the sourcing, the edits and the mistakes are mine.
Not financial advice. Crypto assets are volatile and unregulated in many jurisdictions. In India, gains are taxed at 30% with 1% TDS on transfers. Do your own research and never invest money you cannot afford to lose.
Editorial note: Crypto Shakti uses an AI-assisted research and drafting workflow. Every article is grounded in the linked primary sources and live market data captured at publication time.