Back to the challenge. Opens in 94 hours.

Cheat Sheet

Want the market context before the attack map? Read the companion analysis on IDV attacker economics and why the challenge focuses on server-recorded, device-bound completion.

Welcome to the Pulse Honeypot.

This page is public on purpose. It is our attack map, not fine print. We are showing you how we think the system should be attacked because we want the gate tested hard, not because we want a narrow legal argument afterward.

The payout rule is narrower than this red-team map and has two tiers. The $10,000 prize is governed by the Rules of Engagement and pays for a server-recorded accepted /apply completion for a synthetic profile without a genuine bonded phone session. The $2,500 tier pays for a confirmed, reproducible relay path or completion-binding break that the Operator can independently replay. Browser-only success, UI tricks, and reports that do not create a server-side accepted outcome are not payout conditions.

If you find a payload-swap, wrong-device, relay, webhook, or Action Commitment weakness, we want the report and we will treat it seriously. It belongs in the $2,500 tier when it satisfies the Qualifying Relay or Binding Break definition in the rules. It belongs in the $10,000 tier only when it also produces the qualifying no-phone completion defined there.

We know the standard bypasses: RPC injection, session fixation, copied IDs, missing cookies, stale sessions, cross-origin calls, replay, and TOCTOU. We have tried to lock those down. If there is still a path, show us exactly where we were wrong.

Before opening this challenge we ran a full pre-launch audit — static analysis, full-history secret-scanning, dependency-CVE review, templated misconfiguration scanning, and a transport-layer audit — with no findings. The software perimeter is hardened on purpose, so the only way through is the one this page describes. See the security posture for exactly what we checked and why the lone TLS scanner flag (LUCKY13) is not the door.

Pulse Full-Spectrum Red-Team Brief

This is the public red-team brief for the Pulse Bond Challenge. It intentionally covers more than the payout tiers because strong systems need broad attack pressure. The payout contract is still the Rules of Engagement: a finding pays only when it satisfies the Qualifying Bypass definition or the Qualifying Relay or Binding Break definition there. Everything else in this brief is welcome as a security report and hardening input, not an automatic bounty claim.

1. Mission

You are an advanced offensive-security operator in a sanctioned red-team engagement. Your job is not confirmation. Your job is to falsify the security claims, discover the path the builders missed, and show exactly how a determined attacker could cause unauthorized trust, verification, or completion.

Treat every comment, test, UI state, SDK claim, and architectural description as a claim to verify, not as truth.

2. Approved targets

The challenge is scoped to the assets the Operator publishes at the challenge entry point:

Primary target: the loan-application flow on this site (the public /apply challenge) and the server endpoints it calls.
Web / gate origins: the web origin this site is served from and the hosted Pulse gate widget it loads.
API origins: the challenge backend that records /apply completions, and the Pulse bond and verification endpoints those flows call.
Mobile app: the Pulse iOS beta distributed via the TestFlight link on the challenge page.
Test devices / accounts: your own devices enrolled in that beta.
Test identities: synthetic, fabricated applicant data only — no real personal information, and no staff, vendor, or third-party accounts.
Source access: white-box source review is not offered; treat the System as black-box unless the Operator grants written access.

Anything not described here is out of scope.

3. Core security claims to disprove

The engagement is successful if you disprove any of these claims with reproducible evidence:

A loan/application completion cannot be recorded unless the server can verify device-bound Pulse intent for the correct session, workflow, and action.
A local browser, script, modified SDK, replayed RPC request, forged callback, copied cookie, or synthetic signal cannot substitute for server-verified device intent.
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.
A real but unrelated device cannot be confused, relayed, fixed, swapped, or tricked into bonding the wrong session without the server detecting the mismatch.
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.

4. Finding classes and payout boundary

The $10,000 payout path

The prize pays for one thing: a reproducible path that causes the server to record an accepted /apply completion for a synthetic profile without a genuine bonded Pulse phone session, including any path that forges, replays, or bypasses the required server-held capability. The server log, not the browser UI, is the source of truth.

The $2,500 relay/binding tier

The secondary tier pays for a confirmed, reproducible relay path or completion-binding break that causes the server to accept a completion, verification, or protected-action state for a synthetic profile, but does not meet the no-phone accepted-completion bar. The Operator's server-side records and independent reproduction are the source of truth.

Completion or authorization using the wrong device, a stale assertion, a relayed/confused genuine device, or an assertion bound to a different action/session/user.
Payload-swap or Action Commitment flaws where the phone sees one material action and the server accepts another.
Substitution of OTP, SNA, identity lookup, browser-integrity, address, or other secondary signals for device bond.
Ability to mint, steal, replay, tamper with, or transplant a session/completion capability.
Trust in attacker-controlled verifier responses, provider callbacks, SDK verdicts, or client-side state.

Those reports matter when they are reproducible and server-accepted. They pay the $2,500 tier when they satisfy the Rules of Engagement. They pay the $10,000 tier only when they also create the qualifying no-phone accepted completion above.

A secondary finding is any weakness that materially enables those outcomes: secret exposure, mis-scoped API keys, callback forgery, broken tenant/action binding, race windows, replayable tokens, unsafe CORS/CSRF behavior, SSR/RPC serialization flaws, or observability gaps that hide successful abuse. It is a hardening report only, and not a payout claim, unless it satisfies one of the qualifying definitions in the Rules of Engagement.

5. Rules of engagement

Always allowed inside approved assets

Black-box application testing against the listed target origins.
White-box review of approved repositories and bundles.
Direct invocation of documented or discovered app/RPC/API endpoints.
Client-side tampering: DOM edits, local JS patches, modified request bodies, modified headers, storage/cookie manipulation, SDK shims, and browser automation.
Controlled replay/race testing at low volume.
Static and dynamic analysis of approved test mobile builds and SDK packages.
Controlled relay/confused-deputy testing using only approved test devices, test accounts, and test operators.
Seeded credential/key handling when credentials are intentionally provided for the engagement.

Requires explicit written addendum before execution

Social engineering, phishing, pretexting, or staff interaction.
Testing production employee accounts or customer accounts.
Testing third-party providers beyond the application-owned integration boundary.
Cloud/IAM/CI/CD exploitation beyond read-only validation and evidence collection.
High-concurrency race testing, load testing, or anything that could degrade availability.

Never allowed

Real victim data, real loan applications, real SSNs, real non-consenting phone numbers, or real customer identities.
Destructive actions, persistence, malware, credential theft, extortion, or data exfiltration beyond the minimum evidence needed to prove a finding.
DoS/DDoS, volumetric testing, or resource exhaustion.
Attacks on unrelated infrastructure, DNS, TLS, Apple, Twilio, Vonage, hosting providers, or cloud accounts unless a separate signed scope explicitly names them.
Public disclosure before remediation approval.

6. Adversary model

Think like a capable attacker with time, automation, and patience, but constrained by the rules above. 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.

7. Required exploration areas

These are starting points, not a complete methodology.

Web, RPC, and client trust boundary

Enumerate every route, server function, RPC handler, callback, form action, and API call 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.

8. Evidence standard

Every claimed finding must include:

Impact statement: what security claim was disproven and why it matters.
Exact target asset and environment.
Reproducible request/action sequence, including method, URL, headers, body, cookies, timing, and relevant client actions.
Server response and server-side evidence of completion/verification/state change.
Why the session/action/device was unauthorized, absent, wrong, stale, relayed, or confused.
Root cause and suggested fix.
Blast-radius estimate and constraints used to keep the test safe.

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.

9. Operator notes

The no-phone /apply challenge is the top payout track. It remains valuable because it tests whether the exposed web/RPC layer, session capability, and server sequencing can be bypassed without a bonded phone.

This full brief is broader by design. It also asks whether the architecture, action binding, device intent, provider integrations, webhook chain, and relay resistance survive an advanced authorized adversary. Those questions belong in the $2,500 tier when they satisfy the Qualifying Relay or Binding Break definition in the rules. They belong in the hardening track when they do not create a reproducible server-accepted outcome.