Skip to content

Find the path we missed.

This is the public research brief for the Pulse Bond Challenge. Treat every comment, test, UI state, and architectural claim as something to verify.

Read the Rules of Engagement before testing. They govern authorized conduct, qualifying findings, eligibility, and payment. This brief is research guidance and does not expand those terms.

Contact the Operator for challenge access. Confirm current availability, the entry point, designated targets, and the required agreement before any testing. This marketing and documentation site is not automatically an authorized target.

Mission

Within the Operator’s authorized scope, find the path the builders missed. Test whether an attacker can cause unauthorized trust, verification, or completion. Show a reproducible result.

Authorized targets and materials

Use only assets currently designated by the Operator through its current challenge entry point and governing rules. The research concerns the challenge application, its approved integration endpoints, and approved test app builds and devices.

  • Use fabricated applicant data and approved test accounts/devices. No real consumer information or non-consenting sessions.
  • Third-party services and unrelated infrastructure remain outside the scope described in the rules.
  • Source review requires materials expressly supplied or approved by the Operator. This brief does not grant repository, cloud, account, or private-log access.
  • A broader research question does not authorize broader testing. Obtain the Operator’s written scope for any additional engagement before proceeding.

Payout boundary

The governing rules define a USD $10,000 Qualifying Bypass tier and a USD $2,500 Qualifying Relay or Binding Break tier. The first concerns a qualifying no-phone Accepted Completion; the second concerns a qualifying server-accepted relay or binding defect. Read the exact definitions, exclusions, first-confirmation conditions, and non-cumulative payment rule in the payout contract.

A browser-only indication is insufficient. The Operator’s records and independent reproduction determine whether the published conditions are met. Other findings can be useful hardening reports without being automatic bounty claims.

Claims to test

These are intended security properties, not assurances that testing has established them. A finding must meet the governing rules to qualify for a payout:

  1. A loan/application completion cannot be recorded unless the server can verify device-bound Pulse intent for the correct session, workflow, and action.
  2. A local browser, script, modified SDK, replayed RPC request, forged callback, copied cookie, or synthetic signal cannot substitute for server-verified device intent.
  3. OTP, silent-network-auth, identity lookup, address lookup, browser-integrity signals, or other non-device checks cannot promote a user into a completed / Human Verified / accepted state by themselves.
  4. A real but unrelated device cannot be confused, relayed, fixed, swapped, or tricked into bonding the wrong session without the server detecting the mismatch.
  5. Secrets, completion capabilities, API keys, provider callbacks, session state, and verification results cannot be replayed, transplanted, leaked, or overwritten across users, devices, actions, or environments.

Adversary models

Think like a capable attacker with time, automation, and patience, but constrained by the governing rules and approved scope. Do not limit yourself to the builder’s checklist. Build your own attack tree.

Model at least these adversaries:

  • Malicious browser user trying to bypass the app gate.
  • Scripted attacker invoking RPC/API endpoints directly.
  • Malicious merchant or relying party attempting to over-trust Pulse outputs.
  • Attacker with a copied QR/session link attempting session fixation or transplant.
  • Attacker with an approved test device attempting relay/confused-deputy flows.
  • Attacker with a modified SDK/app bundle attempting to fake local success.
  • Attacker with access to old logs, leaked client config, stale cookies, or replayable tokens.
  • Network-adjacent attacker limited to their own client and approved test infrastructure.

Exploration areas

These are starting points within authorized assets, not additional permission or a complete methodology. Keep requests narrowly bounded; the rules exclude enumeration at scale and availability testing.

Web, RPC, and client trust boundary

  • Map the relevant routes, server functions, RPC handlers, callbacks, form actions, and API calls reachable from the web app and bundled JavaScript.
  • Identify every parameter that names a session, action, workflow, user, phone number, request id, completion state, callback code, or verification result.
  • Test omitted, random, malformed, stale, cross-session, cross-action, cross-origin, and replayed values.
  • Test serializer edge cases, content-type confusion, method confusion, duplicate parameters, oversized-but-bounded payloads, unknown object keys, prototype-looking keys, and response-shape confusion.
  • Force local UI success and prove whether the server did or did not record completion.

Bond lifecycle and server authority

  • Map the full state machine: created, pending, bonded, completed, expired, killed, failed, unknown, and any undocumented states.
  • Try to drive transitions out of order: create to complete, complete twice, complete after expiry, complete after kill, submit before bond, submit during bond, submit after completion.
  • Test action/workflow binding, tenant/origin binding, session id binding, device id binding, and user binding independently.
  • Look for TOCTOU windows between verification and guarded action, including state swap, expiry, kill, replay, and completion races.

Relay and confused-deputy paths

  • Using only approved test devices/accounts, test whether a genuine device can be made to bond a session whose consequence is hidden, swapped, or controlled by the attacker.
  • Test QR/session-link forwarding, session fixation, stale QR reuse, multi-tab reuse, cross-browser handoff, and binding between displayed intent and server-side action.
  • Verify whether the device sees enough human-readable intent to prevent blind approval.
  • Determine whether the server binds device assertion to the exact relying-party action that is later completed.

OTP, SNA, identity, and secondary signals

  • Treat phone-number verification as a separate, weaker signal unless the server proves otherwise.
  • Test whether OTP, SNA, identity match, carrier data, address lookup, browser-integrity signals, or score submissions can set any state later accepted by completion.
  • Test request-id cookies, callback codes, provider statuses, callback replay, provider error handling, and partial-success states.
  • Confirm whether number verification can ever substitute for device possession. If it can, that is a primary finding.

Mobile app, SDK, and local attestation assumptions

  • Analyze approved app/SDK builds for exposed endpoints, keys, debug toggles, bypass flags, local-only trust decisions, logging of secrets, and environment confusion.
  • Test whether modified client code can produce server-accepted assertions or only local UI success.
  • Check replay resistance, nonce binding, action binding, device binding, and freshness assumptions.
  • Do not attack Apple or other platform attestation services; test the application integration and server validation around them.

Server, integration, and configuration review

  • Search approved repositories and bundles for secrets, publishable/private key confusion, environment crossover, dev bypasses, test hooks, mock-verifier paths, overbroad CORS, weak cookie flags, CSRF gaps, SSR/RPC assumptions, webhook/callback trust, and logging of sensitive capabilities.
  • Review provider integration boundaries: what status does the app trust, who can call callbacks, what is signed, what is replayable, and what is merely advisory.
  • Verify that failures fail closed and that malformed or unreachable upstreams do not create success- shaped responses.

Evidence and submission

Every claimed finding must include:

  1. Impact statement: what security claim was disproven and why it matters.
  2. Exact target asset and environment.
  3. Reproducible request/action sequence, including method, URL, headers, body, cookies, timing, and relevant client actions.
  4. Observable server responses, approximate run time, and visible request/session identifiers. The Operator correlates these with its server-side records; private log access is not required or authorized by this brief.
  5. Why the session/action/device was unauthorized, absent, wrong, stale, relayed, or confused.
  6. Root cause and suggested fix.
  7. Impact scope and the constraints used to keep the test bounded.

If no primary bypass is found, do not frame the result as proof that Pulse is secure. Report:

  • Attack tree covered.
  • Strongest paths tested.
  • Exact blocking evidence.
  • Unresolved hypotheses.
  • What additional scope would be needed to test architecture-level relay, social, cloud, provider, or supply-chain risks.

Send the proof package through the submission instructions in the rules. Use synthetic evidence, and include enough information for the Operator to match the run to its records.