BTCPay: the server changed. Who can still spend?

Two dates that change the decision

BTCPay’s November 2 statement reports on-chain Bitcoin and Litecoin hot wallet thefts on installations running 2.4.1 or earlier.

The August 7 advisory identified the fix in 2.4.2 and limited the risk examined then to Lightning Network Daemon (LND) credentials. That historical assessment and the November investigation need to retain their respective scopes. This November 3 analysis proposes recovery criteria; Pentesty has not performed forensic examinations of the incidents.

Define what the new deployment needs to prove

The project advises rebuilding all installations through 2.4.1, including those updated after November 1’s warning, with a fresh server, wallet and seed. Signs of intrusion require this despite updating; generate the seed on a trusted device. Pentesty proposes turning rebuilding into decisions another team can review.

Preserve logs and transaction records before replacement; do not restore a full backup of the old server onto the new machine. Revoke and replace potentially exposed hosting, SSH, application, API and Lightning credentials from a trusted device; keep new secrets off the old machine.

In its August 10 response, the project also advised reducing operational funds held online. For the current plan, agree with operations who approves that limit and under what conditions it will be reviewed.

Verify that the previous authority has been removed

For the proposed assessment, inventory the credentials the instance could access. Use internal identifiers to connect issuer, purpose, dependent integration and owner. Distinguish the application receiving notifications from one able to administer the wallet. Acceptance needs to show who ended each permission and which legitimate behavior was preserved.

Rehearse replacement using a disposable credential in an authorized test project with no real funds. Record a permitted operation, revoke the credential at its issuer and repeat the controlled request. Check the expected refusal and then legitimate operation with its replacement, distinguishing lost permission from service unavailability. Do not reuse compromised secrets in the exercise.

Record acceptance of the environment and custody of the new seed separately, keeping the seed out of maintenance attachments. The analysis of hardware provenance and custody helps frame receiving checks when a device takes part in that process.

Make authorization observable in the exercise

Prepare an isolated replica with synthetic identities and records. The agreed method must exercise the actual integration controls and simulate only signing and broadcasting, preventing transactions on payment networks. Record adaptations and environmental limitations with technical and financial owners.

• Instance: connect each simulated request to the correct environment and integration, checking the permitted operation as well.
• Identity: present a test account lacking the required role and record where its operation is refused.
• Destination: change a relevant field after fictional approval and observe whether the executor requires a new decision.

Accept recovery with the gaps visible

Associate results with the configuration examined, the time and the people accepting continuity. Include scheduled integrations and the procedure that will provision the next server. An exception should identify its effect on the workflow and who decides whether it can remain, with a review deadline. At handover, connect the deployed artifact to the selected release and the origin evidence examined. The historical boundary does not define the current upgrade target.

Provide enough evidence to repeat the exercise without distributing secrets: internal identifiers, observed decisions and protected records. The financial owner should recognize the business operation; operations should be able to locate the configuration that executed it. Specify the functions that remain unverified.

Keep investigation of earlier access under its own time coverage and owner. The analysis of Exchange patching and recovery develops this distinction. The acceptance process described here documents an authorized sample and its limitations, without concluding that every form of compromise has been excluded. Identify the controls exercised and the stages simulated in the conclusion.

Frequently asked questions

Related reading

• Binance: validating withdrawal authorization
• Security hardware provenance and custody
• Separating patching, investigation and recovery

Sources and references

• BTCPay: investigation and recovery, November 2, 2026
• BTCPay: scope of the August 7, 2026 LND advisory
• BTCPay: August 10, 2026 response

Original Pentesty analysis, published November 3, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.