Loop Wallet Audit & Penetration Test

The account restore flow did not reliably prove that a caller had completed the required verification step, and account unlock could be driven by key material supplied in the same request rather than the account's stored key. This weakened the security meaning of account lock, deletion, and recovery.

Fix binds restore to server-issued, single-use state and validates signatures against the stored account key before issuing tokens.

Token validation verified cryptographic validity but did not consistently check server-side revocation state, so logout, refresh-token rotation, and revocation did not reliably terminate existing sessions.

Fix adds an application-state validation layer after signature validation.

Issued session authorization tokens could remain usable at some surfaces after lock.

Fix makes active-account state part of the central authorization boundary and revokes existing sessions on lock or delete.

Connect and Server SDK credential paths were not consistently tied to current account-lock state, so credentials associated with a locked account were not reliably rejected.

Fix makes Connect and Server SDK credential issuance and use lock-aware.

The backend used a single generic validation routine at both the access-token and refresh-token boundaries, so the two token classes were not strictly separated.

Fix enforces type-specific validation at each boundary.

Sign-in challenges were not persisted as server-issued, single-use state, which created a replay exposure in the authentication flow.

Sign-in challenges are persisted server-side and bound to a single use.

A successful one-time passcode was not reliably consumed on use, violating the “one-time” constraint.

OTP tokens are now atomically consumed, with the operation scoped by purpose and account.

The token audience claim was parsed but not compared against the expected audience for the validation context.

Fix enforces the expected audience at every validation boundary

The backend accepted a third-party OAuth identity without fully validating that the token was issued for the wallet's own client and that the associated email was verified, which could allow a foreign-issued token to influence signup identity.

Fix centralizes identity validation with strict audience, issuer, and verified-email checks before the identity is accepted.

Authentication challenges were generated with a non-cryptographic, time-seeded random source rather than a cryptographically secure one.

Remediation switches challenge generation to a cryptographically secure source.

Connect tickets and auth tokens were modeled as durable records without a lifecycle, so they lacked expiry, revocation, and rebinding protections and were not revoked on account lock or deletion.

Fix gives Connect tickets an explicit, enforced lifecycle with expiry, revocation, and single-use approval.

The Connect WebSocket path treated a routing identifier as if it were a session authority, weakening authorization controls of that channel.

Lifecycle checks, origin validation, token comparison, periodic revalidation, and active client ownership checks have been added to the WebSocket path, substantially reducing the exposure.

The wallet reused one signature format across unrelated security domains, so a signature obtained in one context could be accepted in another.

Wallet authentication is now bound to server-issued, single-use challenges, and the Server SDK credential action is presented with clearer consent.

Approval and delivery steps were ordered such that an approval could persist even when the handshake was not delivered to a live session.

Approval code paths have been reordered so that authorization does not survive a failed handshake.

The Connect ticket creation flow exposes authentication material before the wallet user approves the connection. This authentication material belongs to the approved Connect session lifecycle, but it is made available before the approval boundary.

The impact window has been reduced and connection handling made thread-safe.

Repeated approvals of a ticket did not invalidate previously issued tokens for that ticket.

Fix makes ticket approval single-use and rotates or invalidates tokens on authorization changes.

An API-style bearer token could be constructed for tickets whose session identifier was empty.

Fix removes the affected token-processing path in favor of standard, state-validated authorization.

An API call leaked sensitive information necessary for the construction of server sdk authorization tokens.

The leaked information has been removed and server sdk authorization was migrated to JWT.

A ticket-ID derivation scheme for the server sdk reused the JWT signing key across domains with unrelated purposes.

A separate, domain-specific, rotatable secret has been implemented for server sdk derivation schemes.

Reuse of a request identifier within a short window could cause a new fee-bearing transaction to inherit a prior fee-tracking record instead of creating a fresh one.

Fix binds fee tracking to server-side state for the exact request and rejects stale or mismatched records.

The dApp fee settlement flow can treat transaction metadata as sufficient evidence that a required fee was paid. Fee state should only advance after the committed transaction is verified against the expected fee payment terms.

Recognized fee payloads are now rebuilt server-side before preparation.

A failure path could select and terminalize a fee record based on a client-supplied request identifier rather than a proven server-side record.

Validation on the primary path has been tightened.

An ambiguous execution error could terminalize a fee record before ledger finality was known.

Acknowledged.

A preparation step could affect the timestamp used by the unpaid-gas enforcement gate, temporarily affecting when unpaid gas was treated as blocking.

Fix separates enforcement from mutable bookkeeping so preparation no longer affects the gate.

A preparation failure could terminalize an unpaid-gas record based on caller-supplied identifiers.

The enforcement gate now uses durable state and validates prepared records. A narrower residual path remains and is scoped for the planned native fee architecture.

Fee classification relied on process-local cache state, so a delayed execution could fall back to a flat fee rather than the correct fee.

Acknowledged.

Execution did not bind a signed prepared transaction to a single-use server-side prepare record, which affects backend accounting and request-state integrity rather than ledger signature verification.

Acknowledged.

The transaction review surface did not always render every material field of a transaction before signing, so the primary approval text could understate what was being authorized.

Multi-command and malformed requests are now rejected, the acting party is forced to the authenticated wallet, and the full payload is available for inspection.

Responses from an external swap provider were treated as authoritative without validating them against the authenticated request, which could influence a signed deposit.

Fix validates provider responses against the authenticated request before the user signs.

The signed object was derived from backend parsing of an uploaded file, while the review preview was produced separately, so the two could diverge.

Acknowledged. The client treats the uploaded file as user-supplied input and constrains it by rejecting invalid, duplicate, unapproved, and oversized entries. No further change is planned under the current product design.

Some wallet prepare flows cache backend-prepared submissions in a way that is not sufficiently bound to the approved operation, authenticated party, or intended execution lifecycle. This can allow prepared submissions to remain reusable outside the user’s intended approval context.

Acknowledged.

Certain burn operations could be presented in the review surface under a generic withdrawal label rather than as the specific operation

Fix replaces the broad classification with strict decoders and dedicated review summaries.

In some native flows the user reviewed locally displayed context while signing an opaque prepared hash, so the review was not always bound to a backend-authoritative summary of the prepared transaction.

The review surface has been improved.

A redirect parameter was not validated before navigation, which could allow script execution in the wallet's origin. Working payloads were additionally blocked in production by a web application firewall at the time of testing.

Fix strictly validates the redirect target and rejects dangerous schemes.

Key material capable of decrypting the private key was stored alongside the encrypted key, so local access to browser storage could bypass the password.

Fix stops storing derived encryption key material and derives it from the password at unlock time.

Passkey-based encryption derived key material from a stored identifier rather than a hardware-backed secret, so the passkey ceremony was not strictly required to derive the key.

Fix moves passkey key derivation to a hardware-bound mechanism.

The vault is stored under the same origin as the wallet UI, which reduces defense-in-depth against frontend-level compromise such as cross-site scripting, supply-chain issues, or malicious browser extensions. The specific frontend and key-material issues that would combine with this weakness have been fixed (see findings 1, 2, and 3 in this section).

Acknowledged.

The password-based key-derivation work factor was lower than current guidance for private-key encryption.

Fix raises the work factor and introduces versioned key-derivation parameters.

The Content Security Policy permitted inline scripts, reducing the protection the policy is intended to provide if an injection path reached the origin.

Fix removes the unsafe-inline allowance from the script policy.

A transfer-details lookup did not require the requesting account to be a party to the transfer, allowing an authenticated user to read transfer metadata for transfers they did not own. It did not allow moving funds or executing transactions.

Fix scopes the lookup to the authenticated party.

A missing uniqueness invariant on the identity value used as the account boundary could, under certain conditions, allow two accounts to resolve to the same wallet party.

Acknowledged. The client has accepted this as a low-likelihood risk. Their position is that wallet party IDs are assigned through the Canton/validator onboarding flow rather than direct user input, use a randomly generated party hint, and include the signing-key fingerprint.

Backend workers submitted ledger side effects before durably marking the work as processed, so a retry or crash could repeat a backend-controlled side effect. This is not a user-to-user theft path.

Partially fixed. The reward-airdrop portion has been removed from the active code path, which closes the duplicate Backend-funded reward payout surface. The traffic marker worker remains and intentionally uses an at-least-once posting model, where marker batches may be over-posted rather than under-posted. The client has accepted this behavior and plans to remove the marker-posting path as part of the upcoming traffic-based reward replacement.

An admin-only endpoint could queue backend-funded reward grants without budget caps, idempotency, or an immutable audit requirement. The path required admin authorization and was not available to ordinary users.

Fix removes the admin reward-grant endpoint and the reward payout worker from the active code path.

Admin runtime configuration accepted values without typed per-key validation or an immutable audit trail. The path required admin authorization and was not available to ordinary users.

Acknowledged. The client has accepted this admin-only runtime configuration risk, relying on admin-role access plus simple Frontend and Backend validation.

A deposit amount was converted using floating-point arithmetic, which could silently truncate or round the amount shown to the user before signing.

Fix replaces the conversion with exact integer decimal parsing and displays the normalized amount.

The preapproval prepare API accepts an itemized list of instruments, but those instruments are not preserved during transaction preparation. Under the Utility Registry model, this can result in preapproval for all instruments under the given admin.

Acknowledged. The client notes that this behavior is by design and is as intended.

A preapproval created through the generic transaction path did not update the wallet's own preapproval bookkeeping, so backend state could diverge from on-chain state.

Fix keeps backend preapproval state in sync with on-chain preapprovals.

A per-attempt submission identifier was derived from the logical operation identifier rather than generated fresh for each attempt, which affects observability of retries.

Acknowledged. The client confirmed that submissionID is intended for tracking submission attempts and does not represent an urgent security concern.