Northstar Custody

The console posts approvals to the policy engine as JSON containing request_id, approver_id and the WebAuthn assertion. RecordApproval verifies the assertion against the session's registered credential, then stores the approval under body.ApproverID. The verified credential is never compared with approver_id.

An approver can therefore submit their own valid assertion several times with different approver_id values. Each one is stored as a distinct approval, and the quorum check counts distinct approver_ids, so a 3-of-5 policy can be satisfied by one person.

The researcher programme for Northstar lists this outcome as high severity. It does not by itself allow signing outside policy, because whitelists and limits still apply, but quorum is the main control for large or unusual transfers.

A single approver can authorise transactions that require several, defeating separation of duties.

Derive the approver identity from the authenticated session and the credential verified in the assertion; ignore any identity in the request body. Include the request ID and transaction digest in the WebAuthn challenge.

Fixed and verified. The approver is resolved from the verified credential and must match the session; the challenge binds the request and digest. Property P3 holds on the remediated model.

The policy engine evaluates whitelists and velocity limits when a request is created and stores the result. When the quorum is later reached, Authorise issues the signing authorisation based on that stored result. Approval rounds can stay open for days.

If a client removes an address from its whitelist, or lowers a limit, during that window (typically because the address is believed to be compromised), the pending request is still signed. Velocity limits are similarly checked against usage at creation time, so several requests created together can each pass and together exceed the limit.

Transfers to addresses the client has explicitly removed, or beyond velocity limits.

Re-evaluate the full policy, against current usage, inside Authorise and reserve velocity usage atomically when the authorisation is issued.

Fixed. Policy and usage are evaluated again inside a serialisable transaction when the authorisation is issued.

A signing session starts with a message from the coordinator containing the authorisation ID and the 32-byte digest to sign. Each node checks that the authorisation ID exists and is unused, then signs msg.digest. Nodes do not fetch the authorised transaction, rebuild the digest themselves, or verify the policy engine's signature over the authorisation.

The coordinator is meant to be a scheduler and relay, but in this design it can choose what is signed. A compromised coordinator can attach any digest to a valid, unused authorisation, for example one for a transfer of the full balance to an attacker address.

The MPC threshold protects against compromise of individual nodes; this finding is about the component in front of them, which was implicitly trusted.

Arbitrary signatures from any wallet with a pending authorisation, bypassing policy.

Have each node verify the policy engine's signature over the authorisation, fetch the authorised transaction, rebuild the digest independently with chain-specific encoding, and refuse to sign on mismatch.

Fixed. Each node verifies the authorisation signature and rebuilds the payload to sign; the coordinator can no longer influence what is signed.

Key shares are refreshed (re-randomised without changing the public key) on a 90-day schedule. Replacing a node adds a new node through resharing but does not trigger a refresh, so the share held by the removed node remains compatible with the current shares until the next scheduled run.

The runbook wipes the removed node's volume, but backups and snapshots of that volume are kept for 30 days. Anyone with access to those snapshots holds a valid share that, combined with threshold minus one current shares, can sign.

Lowers the effective number of compromises needed to sign during the refresh window.

Run a proactive share refresh as part of every membership change and exclude signing-node volumes from general backups.

Fixed. Membership changes trigger an immediate refresh, and signing-node volumes are excluded from snapshot policies.

Clients sign requests with HMAC-SHA256(secret, method + path + body). The signature has no timestamp or nonce, and transaction-creation requests have no idempotency key. A captured request can be resent indefinitely and each copy creates a new transaction request.

Replayed requests still need policy approval, so this does not lead to unauthorised signing on its own. It does create duplicate requests that approvers may approve in bulk, and it lets an attacker with log or proxy access exhaust velocity limits to block legitimate transfers.

Duplicate transfers if approvers do not notice, and denial of service through velocity-limit exhaustion.

Include a timestamp and a random nonce in the signed string, reject requests outside a short window or with a seen nonce, and require idempotency keys on creation endpoints.

Fixed. Signatures cover timestamp and nonce with a five-minute window; creation endpoints require an idempotency key.

The webhook settings page loads the signing secret with GET /v1/webhooks/{id}?reveal=true&secret=... when testing a webhook, so the secret appears in browser history and in the access logs of the API gateway. Anyone who can read those logs can forge webhooks that clients use to update their own ledgers.

Forged webhook notifications; no effect on signing.

Send secrets only in request bodies, show them once at creation, and support rotation.

Fixed. Secrets are shown once, test calls use a POST body, and logs were purged.

Velocity limits are configured per asset (for example 500,000 USDC per day). A wallet holding many assets has no aggregate limit, so an attacker who can pass approvals can move far more value in one day by spreading transfers across assets than any single limit suggests. Clients may not realise this when configuring policies.

Limits give less protection than clients expect.

Offer an aggregate limit in a reference currency and warn about policies without one.

Acknowledged. Aggregate limits and policy linting are planned; in the meantime the console shows the combined daily exposure.

cargo audit reported an unmaintained crate pulled in by a logging dependency. No vulnerability was known in it, but unmaintained code in the signing node increases long-term risk.

Supply-chain hygiene.

Replace the dependency and run cargo audit and cargo deny in CI.

Fixed; dependency replaced and checks added to CI.