VeltoraSecurity Assessment Report

Security impact

A payment link is meant to be a bearer instrument: whoever holds the complete link, including the fragment after #, can claim the funds, and nobody else can. The fragment carries the IV that the encrypted escrow key needs. The link ID in the path is supposed to be useless on its own, which is why it is safe to log, and it does get logged: by the CDN, the hosting platform, the error monitor and every support ticket that pastes a failing link.

The ID is not useless. GET /api/links/[linkId] returns the AES key with the ciphertext and the GCM tag, and with the key in hand the IV is not secret. XOR the tag with the GHASH of the ciphertext to get the encrypted counter block, decrypt that block with the key, and the first 96 bits are the IV. The key and the IV then decrypt the escrow key. Our proof of concept recovered the escrow private key from a link ID alone and signed a claim with it, using the application's own encoder, without claiming a live link.

So anyone who can read a log line that contains a link ID can claim that link while it is funded. The attacker needs the ID, which is why likelihood is Possible and not Likely.

export async function GET(_req: Request, { params }: { params: { linkId: string } }) {  const { data } = await db    .from("payment_links")    .select("ciphertext, aes_key, expires_at")    .eq("id", params.linkId)    .single()  return Response.json({ ciphertext: data.ciphertext, key: data.aes_key })}

Recommendation

Stop returning the key. Split the secret so that the server holds nothing that decrypts the link: derive the encryption key from material that lives only in the fragment, and make the link ID a random value with no relationship to it. Re-issue every unclaimed link under the new format and invalidate the old ones.

Remediation and verification

Open

Security impact

POST /api/webhooks/settlement is where Relaymint tells Veltora that a deposit or swap has settled. The route parsed the body, looked up the user by the account field and credited the ledger with amount. It did not check the Relaymint-Signature header, did not check a timestamp, and did not record the event ID. The URL is in the public client bundle because the staging build also uses it for polling.

Anyone could therefore credit any account with any amount, and the ledger balance is what the withdrawal flow spends from. We credited a test account on staging with a forged event and withdrew the credit to an external address. This needed no account, no identifier and no race, which is what Likely means, and the impact is funds taken at scale.

We reported this on the second day of the review. Veltora shipped signature verification and an event-ID uniqueness constraint two days later. The fix commit is in the baseline this draft covers, and we verified it there.

export async function POST(request: Request) {  const event = settlementSchema.parse(await request.json())  const account = await findAccount(event.account)  await ledger.credit(account.id, event.amount, event.asset)  return new Response(null, { status: 204 })}

Recommendation

Verify the Relaymint signature over the raw body before parsing, reject events older than five minutes, and record each event ID under a unique constraint so a replay credits nothing. Treat the credit as the last step of a transaction that includes the event-ID insert.

Remediation and verification

Fixed in commit 9c3e1a7f04b2d86e5a1f7c20e4d93b58a6f2c071, which is included in the reviewed baseline. The route now verifies the signature over the raw body with a constant-time comparison, rejects stale timestamps, and inserts the event ID under a unique constraint in the same transaction as the credit. Two contributed regression tests cover a forged signature and a replayed event; both pass.

Security impact

A payout batch has a draft state, an approved state and a submitted state. The approver role exists so that one person cannot both prepare and release a payment. The UI hides the edit button once a batch is approved and shows it only to editors, but PATCH /api/payouts/[batchId] checks only that the caller is a member of the batch's organisation. It does not check the caller's role, and it does not check the batch status.

So a viewer, or an editor after approval, can replace the recipient address on any line of an approved batch. The scheduler submits whatever the row holds at run time. We changed a recipient on an approved staging batch as a viewer and watched the scheduler pay the new address.

The attacker has to be a member of the organisation, which is why likelihood is Possible. The approval step exists because membership alone should not be enough to move money.

export async function PATCH(request: Request, { params }: { params: { batchId: string } }) {  const session = await requireSession()  await requireOrgMember(session, params.batchId)  const patch = batchPatchSchema.parse(await request.json())  await db.from("payout_lines").upsert(patch.lines)  return Response.json({ ok: true })}

Recommendation

Enforce the role and the status on the server: only editors can change a draft, nobody can change an approved batch, and approval signs a hash of the lines that the scheduler re-checks before submitting. Record who changed what on each line.

Remediation and verification

Open

Security impact

POST /api/passkeys/credentials stores a credential ID and public key before any registration ceremony completes, and it asks for no session. The public key field has no length limit in the schema or the database. The nightly backup reads the whole table into memory and serializes it as one JSON value.

Anyone can therefore write rows until the backup job runs out of memory or time. Nobody is locked out when that happens. What is lost is the ability to restore passkey credentials if the live table is later lost, and account access depends on them. Rows never expire, so the condition persists until an operator clears it by hand.

We rate the impact Moderate because the harm is the loss of a recovery control rather than a realised loss.

Recommendation

Persist a credential only after a verified registration ceremony. Cap the public key length in the schema and the database. Stream the backup in bounded chunks.

Remediation and verification

Open

Security impact

Sign-out clears the access cookie and leaves the per-wallet refresh cookie, which lives for fourteen days. On the next connect with the same wallet, the client finds no access token, exchanges the refresh cookie for a new one, and lands in a signed-in session. Nothing on that path asks for a passkey assertion.

So on a shared laptop with the wallet extension still unlocked, whoever connects that wallet next resumes the session without the passkey that is supposed to guard the embedded wallet and the payout routes. The cookie is httpOnly and SameSite=Lax, so it cannot be driven from another origin. That is why likelihood is Rare: it needs the device.

Recommendation

Delete the refresh cookie on explicit sign-out, and require a fresh assertion before a refresh restores a session that was signed out.

Remediation and verification

Open

Security impact

The quote on the review screen is a dry run. When the user confirms, swapSubmitMachine requests a live quote and signs the intent Relaymint returns. Nothing compares the live quote's recipient, output asset or minimum received with the reviewed one. If Relaymint returns different terms, through a bug or a compromise, the user signs terms they never saw. We rate it Rare because it needs Relaymint to misbehave.

Recommendation

Compare the live quote field by field against the reviewed quote and fail closed on any difference in recipient, asset, amount or deadline.

Remediation and verification

Open

Security impact

POST /api/wallets/[walletId]/sign takes a typed-data payload and a passkey assertion and forwards both to Wardkey. It checks that the wallet belongs to the caller. It does not check what is being signed. The passkey prompt shows the same generic text for every request, so a user cannot tell a routine approval from a token allowance to an attacker.

Any script running on the page while the user is signed in can therefore request a signature over anything, and the user approves it believing it is routine. We rate likelihood Possible because it needs a script foothold on the origin, and impact Moderate because we demonstrated the missing control, not a drained wallet.

Recommendation

Allowlist the typed-data types the product actually uses, decode them on the server, and show the decoded action in the confirmation before the passkey prompt.

Remediation and verification

Open

Security impact

The send confirmation renders the recipient as the first four and last four characters. Eight hex characters are 32 bits, so a matching address takes about four billion attempts, which is minutes on one GPU. Address poisoning then puts that address in the user's transaction history. The confirmation screen, which is the last control, cannot tell the two apart.

Recommendation

Show the full address on the confirmation, grouped for reading, and flag a recipient that is new to this user.

Remediation and verification

Open

Security impact

Claimed and expired links keep their ciphertext and key in the table, and the GET route keeps serving them. With GUV-1 that means a link ID in an old log decrypts the link's contents indefinitely, including the sender's note and amount, after the funds have gone.

Recommendation

Delete the key when a link is claimed or expires, and return 410 for those links.

Remediation and verification

Open

Security impact

The CSV import sums the batch in the browser and posts the total with the lines. The server stores the total as sent. The approver screen leads with that total. An editor can make a batch look smaller than it is; the per-line amounts are still correct and still shown, which is why impact is Negligible.

Recommendation

Recompute the total on the server from the stored lines and ignore the client value.

Remediation and verification

Open

Security impact

The review screen shows a fee computed from a rate cached for up to sixty seconds. Submit fetches the live rate. In volatile periods the charged fee can exceed the shown one by a few percent.

Recommendation

Show the fee the submission will use, or cap the submitted fee at the displayed value.

Remediation and verification

Open

Security impact

The scheduler picks up approved batches and marks them submitted only after Relaymint accepts them. Two overlapping runs both pick up the same batch. Relaymint rejects the second submission because Veltora sends the batch ID as an idempotency key, so nobody is paid twice. The job still does the work twice and logs a failure every time.

Recommendation

Take a row-level lease before submitting, and keep the idempotency key.

Remediation and verification

Open

Security impact

The IndexedDB session signer is keyed by address and is not removed when the user switches wallet. Wardkey rejects its signatures for the new wallet, so we found no exploit. It is key material with no owner.

Recommendation

Delete the session signer on wallet switch and on sign-out.

Remediation and verification

Open

Security impact

The price-impact warning divides by the output value instead of the input value, so it understates impact on thin pools and the warning threshold triggers late.

Recommendation

Compute impact against the input value at the reference price.

Remediation and verification

Open