Security: idor in src/services/payments-service.ts #1017

CodeRabbit's historical security scan of this repository (scan e8c825ec-84c1-4a90-b646-61791714baf8, revision bc22677aba, generated 2026-11-01) reported this. It is an AI-generated finding, not a confirmed vulnerability: reachability is not established by the scan, and the report itself says so. Triage before treating it as exploitable.

F-027 — idor (medium)

src/services/payments-service.ts:221-224

A payer can select another user's public key and purchase a different plan without that user's authorization. Confirmation immediately replaces the existing plan, so a purchase with shorter effective retention can cause maintenance to delete events still protected by the beneficiary's previous paid plan.

Evidence

• Source/control: The pubkey and planId fields submitted to the public POST /invoices endpoint, followed by payment of the resulting invoice.
• Sink/decision: PaymentsService.confirmInvoice upserts the beneficiary's subscription using applyPayment, which immediately replaces planId.
• Missing mitigation: The flow does not require beneficiary authorization for a plan change that reduces existing benefits, and it does not preserve the previous plan's retention protection through its paid period.

Suggested fix. Require proof of beneficiary authorization before applying a plan change that reduces existing benefits. Store a subsequent plan separately and retain the current plan's retention protection until its paid period ends.

Finding F-027 of 43 in the scan. The other findings are filed as separate issues by area.