Vulnerability Disclosure & Bug Bounty Policy

Found a security vulnerability in Wispr Flow? This policy explains how to report it, what qualifies for a bounty, and the legal protections offered to researchers who follow responsible disclosure practices.

What this policy covers

This policy is designed to:

• Encourage responsible security research and disclosure

• Provide a clear reporting process for security vulnerabilities

• Define what is in scope and out of scope for testing

• Establish triage timelines for reported issues

• Outline reward and severity guidance

• Offer safe-harbor legal assurances for researchers who follow the policy

How to report a vulnerability

Report security vulnerabilities via email to security@wisprflow.ai.

Required information

Include all of the following when submitting a report. Submissions missing required fields will be returned for completion before triage begins.

• Concise summary: Title and short description

• CVSS vector string: A full CVSS 3.1 or 4.0 vector (not just a score). Example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• CWE classification: The relevant CWE ID. Example: CWE-601 (URL Redirection to Untrusted Site)

• Proof-of-concept: A functional, independently reproducible exploit — curl commands, scripts, or video walkthrough with timestamps. Must be reproducible at least 50% of the time.

• Affected systems: Domains, application versions, and platforms

• Evidence of testing: Specific HTTP response headers, status codes, timestamps, or server identifiers from Wispr's actual production systems

• Testing details: Time window and relevant IP addresses

• Contact information: Preferred method for follow-up

Submission quality & original research

Submissions must reflect original, hands-on security research performed by the submitter against Wispr Flow's actual production systems.

Reports that are primarily generated by AI tools without demonstrated manual verification and testing will be closed without review.

Indicators that may result in immediate closure:

• Generic vulnerability descriptions not specific to Wispr Flow

• Fabricated or fictitious technical details (e.g., referencing technologies Wispr doesn't use)

• No evidence of actual interaction with Wispr systems

• Scanner output (Burp Suite, Nessus, Nuclei) submitted without manual analysis

• Internally inconsistent CVSS vectors

• Submissions substantially identical in structure to other reports

Submission limits

Researchers may submit a maximum of 5 bounty-eligible reports per calendar month. Additional submissions beyond this limit will be queued but not eligible for bounty. This limit resets monthly and does not apply to Critical-severity findings.

Response timeline

All timelines below are measured from the acknowledgment date, except remediation targets, which begin after final classification & payout.

Scope

In-scope assets

• Domains: *.wisprflow.ai and associated production domains/subdomains (excluding roadmap.wisprflow.ai — third-party hosted, see Out-of-scope)

• Production backend APIs: api.wisprflow.ai and dl.wisprflow.com (auto-update CDN)

• Production backend dependencies: Supabase (*.supabase.co) and Baseten (*.api.baseten.co) are backend dependencies, though these are third-party hosted services

• Client applications: Electron, macOS, Windows, iOS, and Android clients — issues affecting confidentiality, integrity, or availability beyond normal user operation

• High-impact issues: Auth/authz flaws, data leakage, RCE, cryptographic misuse, serious misconfigurations, client-side enforcement bypasses where server-side validation is absent, auto-update supply-chain integrity

• Infrastructure: Servers, containers, production databases, public S3 buckets, public cloud services

Out-of-scope items

Infrastructure & third-party:

• Third-party services on non-Wispr domains (stripe.com, supabase.com, AWS console)

• Subdomains not owned/managed by Wispr Flow

Attack categories:

• Social engineering / phishing targeting Wispr employees

• Social-engineering-dependent attack chains: Vulnerabilities whose exploitation relies on social engineering of any person (including non-Wispr users) under constraints that are highly unlikely in real-world conditions may be classified at lower severity than the hypothetical impact suggests. Severity is assessed based on realistic exploitability, not best-case attacker assumptions. For example, an attack requiring a victim to perform a complex, unusual sequence of actions in a narrow time window will be treated as lower severity than one requiring a single click.

• Denial-of-service (DoS/DDoS) or load-testing

• MITM attacks against HTTPS endpoints, including claims based on missing certificate pinning

Low-impact / theoretical findings:

• Self-XSS: XSS that only fires in the submitter's own session (e.g., HTML injection in support forms visible only to internal staff)

• Missing/non-critical security headers unless part of a working exploit chain

• Clickjacking on pages with no sensitive state-changing actions

• Software version disclosure without demonstrated exploit chain

• SSL/TLS configuration issues without practical attack (BEAST, POODLE on non-vulnerable configs)

• Missing CAA DNS records unless combined with real certificate misissuance

• CSRF on unauthenticated or low-impact forms

Rate limiting & brute force:

Rate limiting or brute force without a demonstrated complete attack chain resulting in account compromise or data exposure. IP rotation to bypass IP-based rate limits is an inherent limitation of IP-based rate limiting, not a vulnerability. Reports must show end-to-end impact.

Authentication token storage:

Token storage in browser localStorage or cookies — this is the default behavior of Supabase Auth. Without a demonstrated XSS chain leveraging stored tokens for session hijacking, this is Informational.

Third-party dependency issues:

Vulnerabilities in third-party dependencies without a demonstrated exploit path specific to Wispr Flow. Reporting a CVE without showing exploitability in Wispr's context is not bounty-eligible.

Submission quality:

• Scanner output (Burp, Nessus, Nuclei) submitted without manual validation

• Non-security bugs / UX issues — submit via product feedback

• Local-only issues unless they reveal a systemic problem

If unsure whether an issue is in scope, report it anyway — Wispr Flow will triage it.

Duplicate reports

Only the first reporter of a given vulnerability is eligible for a bounty. Wispr Flow tracks all reported findings internally. If your submission describes an issue that has already been reported, you will be notified that it is a duplicate and no payout will be issued. If you believe your finding is a novel variant of a previously reported issue, include a clear explanation of how it differs.

Reward and severity guidance

Rewards are based on actual impact, exploitability, and report quality. All awards are granted at Wispr Flow's discretion following internal validation.

Minimum bounty eligibility

Bounty payments require a minimum severity of Medium (CVSS 4.0+ or equivalent). Low and Informational findings are accepted and acknowledged but not eligible for monetary reward.

Severity levels

Wispr Flow classifies severity based on what is independently verified, not what the reporter claims.

Severity decision factors

• User interaction? None (Critical/High) → Single click (Medium) → Complex chain (Low)

• Scale? Mass/bulk (Critical) → Multiple users (High) → Single user (Medium/Low)

• Auth required? Unauthenticated (Critical) → Unauth + user interaction (Medium) → Authenticated (varies)

• Requires victim to grant access first? If attacker must be invited/onboarded before exploitation → Informational (insider threat, not a vulnerability)

Partial rewards

A partial reward (lower end of range) may be issued when:

• The vulnerability is valid but actual impact is lower than the tier suggests

• The PoC is incomplete but the vulnerability can be independently confirmed

• The finding is a novel variant of a known issue adding meaningful new information

Reports that remain unreproducible after clarification will be closed.

Responsible disclosure

Researchers are asked to avoid public disclosure until:

• Wispr Flow has remediated the issue, or

• A mutually agreed disclosure date has been reached

Standard window: 90 days from acknowledgment.

Exceptions: May be shortened or extended if actively exploited or if legal/regulatory obligations require earlier disclosure.

If you plan to publish, notify Wispr Flow at least 7 days before public disclosure. When possible, Wispr Flow will publish a coordinated advisory.

Safe harbor and legal protection

If you follow this policy and act in good faith, Wispr Flow will not initiate legal action against you, provided you:

• Avoid unnecessary data exfiltration beyond what demonstrates impact

• Do not publicly disclose details before coordination

• Do not perform DoS or service-degrading tests

Report template

All fields marked * are required.

• Title: *

• Affected component(s) / domain(s): *

• CVSS 3.1 vector string: *

• CWE ID: *

• Summary (1–2 lines): *

• Impact (what an attacker can do): *

• Steps to reproduce (curl commands, scripts, or video with timestamps): *

• Evidence of testing (response headers, timestamps, server identifiers): *

• Evidence (screenshots, logs, exploit code):

• Remediation suggestion:

• Test time window & IP(s): *

• Confirmation: "I confirm this report reflects original research performed by me against Wispr Flow's production systems." *

• Contact information: *

FAQs

Researcher notes

• API keys: 35 characters starting with fl-

• Electron CSP: Allowlisted domains, includes unsafe-eval and unsafe-inline in script-src (production builds only)

• Auth token caching: Short delay between revocation and enforcement

• Platform differences: iOS vs desktop authorization logic varies

• Electron renderer: sandbox: false, contextIsolation: true, nodeIntegration: false

• Certificate pinning: System root CAs (macOS via mac-ca, Windows root store via win-ca) filtered by isRootCA() (self-signed + CA flag), merged with Node.js built-in Mozilla root certificates. Windows only queries root store (not ca store).

• OAuth redirects: Strict domain allowlist (wisprflow.ai, *.wisprflow.ai, platform.flowvoice.ai, localhost, Vercel previews)

• OAuth callbacks: Tokens (access_token, refresh_token, email, name, user_id) passed as URL query params in redirects — exposed to server logs, browser history, referrer headers

• API key storage: Stored hashed (bcrypt), Redis cached (300s sliding TTL); SHA-256 used only for cache key derivation; last-4-char pre-filtering for DB lookups; JWTs support server-side revocation with DB expiry check

• CORS: /api/v1/dash/* permissive; all other endpoints restricted allowlist

• CORS dash endpoints: /api/v1/dash/* allows credentialed requests from any origin (allow_credentials=True with wildcard)

• Admin impersonation: X-Impersonate-Enterprise header enforces read-only (mutations return 403)

• Internal admin endpoints: /api/v1/internal — publicly routable, no IP allowlist; protected by @wispr.ai email check only (TODO: add role check, affects ~40 endpoints). Superadmin endpoints require both email + SuperAdmin role

• Rate limiting: Four strategies — user ID, install UUID, client IP, email from body

• Email signup rate limiter: 3 attempts per email per hour (Redis-backed); fails closed (HTTP 503) on Redis failure

• Install UUID rate limiter: Malformed UUIDs bucketed under shared 'install:invalid' key

• Redis API key cache TTL: Sliding (resets on every hit) — frequently-used keys stay cached indefinitely

• LLM rate limiter: 3 concurrent + 5/10s per user (in-process, non-Redis)

• Desktop subscription: Cached on disk, refreshed hourly, stale cache when offline. Retries once with 2s delay before cache fallback. Enterprise past_due treated as active; personal past_due treated as non-premium.

• Premium validation: iOS treats past_due/paused as premium; desktop does not

• Enterprise SSO: Enforcement disabled if subscription lapses, even if setting is ON

• Word usage limits: Client-side only — no server-side enforcement on transcription API

• Audio transport: Android/iOS: gRPC streaming primary, HTTP REST fallback (Android rejects >10MB). Desktop: WebSocket primary (gRPC rolling out via feature flag), WebSocket fallback. gRPC failure triggers 3-hour cooldown on desktop. Android retries up to 3x on auth errors.

• Transcription data: Storage depends on privacy mode and enterprise settings. Privacy mode OFF (default): data stored server-side. Privacy mode ON or enterprise ZDR enabled: zero data retention. Desktop also has local data policy (StoreNormally/DeleteAfter24h/NeverStore) configurable per-user or enterprise-enforced.

• Desktop auth tokens: Stored in file-based electron-store, not browser localStorage

• Auto-update: 3 release channels (prod, beta, override). Safety: random stagger up to 1h, exponential backoff, 20-min post-dictation cooldown, max 3 retries then 24h pause

• API key revocation on org removal: All keys created by removed user are auto-deleted

• JWT validation: DB-stored expires_at checked independently of JWT signature expiry

• Production infrastructure: Includes Supabase (dodjkfqhwrzqjwkfnthl.supabase.co) and Baseten (chain-o232k03l.api.baseten.co) — not listed in domain scope

• hCaptcha: Uses wispr.ai domain (not wisprflow.ai)

• DevTools: Disabled in production builds