Security: crypto payment front-running and dependency vulnerabilities

[CShear]

From security audit — March 17, 2026

1. Crypto payment front-running (HIGH)

The POST /api/v1/confirm-payment endpoint is public. An attacker who watches the blockchain for transactions to our known receive addresses can call confirm-payment with the tx_hash and their own email before the legitimate sender does, stealing the subscription.

Options to fix:

• A: Generate a unique payment address per pending transaction (HD derivation from the receive wallet). Most secure but adds complexity.
• B: Require the sender to sign a message proving they own the sending address. Adds friction for agents.
• C: Tie the from_address to the provisioned account — if someone else already claimed a tx from address X, reject subsequent claims from different emails for the same from_address. Simpler but not perfect.
• D: Accept the risk — amounts are small ($1.25-$250), and frontrunning requires real-time mempool monitoring. The attacker gains a subscription but doesn't steal funds.

Recommendation: Option C (from_address binding) is the best balance of security and simplicity. If the same from_address is seen in a new transaction, associate it with the same user account.

2. Dependency vulnerabilities (HIGH aggregate)

npm audit reports 13 vulnerabilities (9 high):

• elliptic (HIGH) — used in @cosmjs wallet signing path
• axios (HIGH, 6x) — transitive via @cosmjs and @regen-network/api
• hono / @hono/node-server (HIGH, 5x) — transitive dependency
• express-rate-limit (LOW) — IPv4-mapped IPv6 bypass

Action: Run npm audit fix for non-breaking fixes. Evaluate upgrading @cosmjs/proto-signing to latest for the elliptic fix. The hono vulnerabilities may not be reachable (needs investigation).

3. Centralize receive addresses (MEDIUM)

Addresses are hardcoded in both src/services/crypto-verify.ts and src/server/api-routes.ts. Should be defined once in config.ts or a shared constant.

Already fixed in this audit

• XSS (sessionId, org.name, refCode) — CRITICAL/HIGH
• API key leak on confirm-payment — HIGH
• Security headers via helmet — HIGH
• API key log truncation — HIGH
• Rate limit on confirm-payment — MEDIUM
• Error message sanitization — MEDIUM