Security & Responsible Disclosure

Soul Cage is a security product operated by security people. We take vulnerability reports seriously and respond to them quickly. This page covers how to report a finding, what we store, how long we keep it, and what we do not collect.

Reporting a vulnerability

Email [email protected] with the subject line [VULN]. Include a clear description of the issue, reproduction steps, and your assessment of impact. We do not require a formal template — a clear write-up is enough.

We will acknowledge your report within 48 hours and provide a resolution timeline within 7 days. Critical findings get same-day acknowledgement.

We ask for 90 days to remediate before public disclosure. If we cannot fix within that window we will coordinate with you on timing. We will not pursue legal action against researchers acting in good faith under this policy.

Critical

RCE on the game server or website, authentication bypass, PSK plaintext exposure via API, SQL injection against user data

High

BSSID deanonymisation below H3 cell resolution, privilege escalation between user accounts, fleet worker receiving BSSID/GPS data it should not

Medium

IDOR on non-sensitive resources, reflected XSS without persistent state, rate-limit bypass on public endpoints

Low / Informational

Missing security headers, verbose error messages, minor logic issues with no direct user impact

In scope

  • ✓soulcage.win — website and all API endpoints
  • ✓The distributed cracking fleet worker protocol
  • ✓The pet firmware (AGPL — source available at launch)
  • ✓The Android companion app
  • ✓The opt-out / scope verification flows

Out of scope

  • ✗Denial of service attacks
  • ✗Social engineering of Soul Cage staff
  • ✗Physical attacks against infrastructure
  • ✗Attacks against third-party services we depend on (Stripe, Railway, etc.)
  • ✗Issues already known and tracked (check the changelog first)

What we store

For each access point seen by a Soul Cage pet:

AP MAC (BSSID)

Stored in hashed form for opt-out matching. Raw BSSID never in a public API response.

SSID

Stored in truncated/hashed form. Not exposed publicly. Used only for internal deduplication.

Approximate location

H3 hex-cell (res-5, ~8.5 km²). No street-level coordinates ever stored against a BSSID.

Signal strength (RSSI)

Stored per-capture for fleet quality scoring. Not publicly queryable.

Capture timestamp

Date and hour of first and most recent capture. Used for territory recency logic.

WPA handshake / PMKID hash

Stored in the cracking queue. Deleted after the PSK is confirmed cracked or after 90 days, whichever comes first.

Cracked PSK (plaintext)

Stored in the shared fleet wordlist (passwords only — no BSSID, SSID, or user identity attached). This is the fleet.txt network-effect moat.

What we do not store

  • ✗Raw GPS coordinates of any individual router
  • ✗Street addresses or physical location below H3 cell resolution
  • ✗Device identifiers of the pet owner who submitted a capture
  • ✗Any payload or data from inside the captured network
  • ✗Browser history, cookies, or any data from connected clients
  • ✗Personally identifiable information linked to a BSSID

Data retention

Uncaptured BSSID (passive scan only)Indefinite — forms territory layer
Uncracked handshake hash90 days, then deleted
Cracked PSK in fleet wordlistIndefinite — password only, no context
Opted-out BSSID blacklist entryIndefinite — required to enforce the opt-out
User account dataUntil account deletion request
Bounty scope recordsDuration of scope + 12 months for audit trail

Abuse reports

To report misuse of the platform — a user attacking out-of-scope networks, submitting forged captures, or harassing other users — email [email protected]. Include the username or pet ID involved and a description of the behaviour. Confirmed abuse results in account termination and fleet blacklisting.

Remove your WiFi from the map →Legal framework →Opt-out documentation →API reference →