Available on: Mac, Windows, iOS, Android
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.
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
Report security vulnerabilities via email to security@wisprflow.ai.
Note: There is no in-app vulnerability reporting path — researchers must email directly.
When submitting a report, you must include all of the following. 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
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 hallucinated 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
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.
All timelines below are measured from the acknowledgment date, except remediation targets, which begin after final classification & payout.
Stage | Timeline | Clock starts |
Acknowledgment | Within 3 business days | Date report received |
Initial triage | Within 10 business days | Acknowledgment |
Final classification & payout | Within 30 business days | Acknowledgment |
Remediation — Critical | Within 7 days | Final classification & payout |
Remediation — High | Within 30 days | Final classification & payout |
Remediation — Medium | Within 90 days | Final classification & payout |
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)
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
Android note: Limited functionality vs other clients. Core surfaces: dictation, floating bubble, transcript history, account profile. No privacy mode toggle, no in-app subscription, no language selection UI, no dictionary/snippets, no feature flags. Enterprise users have privacy mode auto-enabled server-side.
Third-party services on non-Wispr domains (stripe.com, supabase.com, AWS console)
Subdomains not owned/managed by Wispr Flow
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
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 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.
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.
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.
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.
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.
Rewards are based on actual impact, exploitability, and report quality. All awards granted at Wispr Flow's discretion following internal validation.
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.
Wispr Flow classifies severity based on what we independently verify, not what the reporter claims.
Informational / Best Practice — $0
Missing CAA records, non-critical security headers
General security advice
Theoretical attacks without demonstrated exploitability
Working-as-designed behavior behind proper auth controls
Token storage in localStorage without XSS chain
Low — $0 (acknowledgment only)
Limited information leakage (non-sensitive data, stack traces)
Predictable session tokens with short TTL
Minor auth flaws without account takeover
Reflected XSS in limited contexts
Medium — $500 to $2,000
Authorization bypass on non-sensitive accounts
OAuth redirect token theft requiring social engineering
CSRF with sensitive state-changing actions
Stored XSS requiring victim interaction
SSRF reaching internal metadata with mitigations
Wispr example: OAuth redirect_to manipulation leaking tokens to attacker server after victim clicks crafted link.
High — $2,000 to $5,000
Authenticated RCE
Direct privilege escalation (regular user → enterprise admin)
Persistent XSS impacting many users without victim interaction
Significant PII exfiltration
Wispr example: Bypassing X-Impersonate-Enterprise middleware to perform write operations as impersonated enterprise.
Critical — $5,000+
Unauthenticated RCE in production
Full database exfiltration of PII/credentials
Active credential leaks enabling large-scale ATO
Supply-chain compromise of auto-update infrastructure (dl.wisprflow.com)
Wispr example: Unauthenticated access to Supabase admin API enabling bulk user data export.
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 reward (lower end of range) may be issued when:
Vulnerability is valid but actual impact is lower than tier suggests
PoC is incomplete but vulnerability can be independently confirmed
Finding is a novel variant of a known issue adding meaningful new info
Reports that remain unreproducible after clarification will be closed.
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/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.
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
Warning: Wispr Flow reserves the right to deny safe-harbor if testing is reckless, destructive, or violates this policy.
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: *
Are missing CAA records eligible for a bounty?
Informational only — bounty-eligible if combined with real certificate misissuance.
Are subdomain takeovers in scope?
Yes, if the takeover allows control of a Wispr Flow domain (e.g., dangling CNAME).
Are client-side issues eligible?
Yes, if they result in remote compromise or user data leakage beyond expected behavior.
Are Low-severity findings bounty-eligible?
No. As of April 2026, bounty requires minimum Medium severity (CVSS 4.0+). Valid Low findings may receive hall of fame recognition.
Can I use AI tools in my research?
As research assistants, yes. But the submission must reflect hands-on testing you performed. AI-generated reports without manual verification will be closed.
What if my finding is a duplicate?
Only the first reporter is eligible for a bounty. If you believe your finding is a novel variant of a previously reported issue, include a clear explanation of how it differs.
Is there a submission limit?
5 bounty-eligible reports per month per researcher. Critical findings are exempt.
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 CA validation (macOS System Roots, Windows root store)
OAuth redirects: strict domain allowlist (wisprflow.ai, *.wisprflow.ai, platform.flowvoice.ai, localhost, Vercel previews)
API keys: stored hashed (SHA-256), Redis cached (300s TTL); JWTs support server-side revocation
CORS: /api/v1/dash/* permissive; all other endpoints restricted allowlist
Admin impersonation: X-Impersonate-Enterprise header enforces read-only (mutations return 403)
Rate limiting: four strategies — user ID, install UUID, client IP, email from body
Desktop subscription: cached on disk, refreshed hourly, stale cache when offline
Premium validation: iOS treats past_due/paused as premium; desktop does not
Word usage limits: client-side only — no server-side enforcement on transcription API
Audio: gRPC streaming (primary), HTTP fallback; Android rejects >10MB on HTTP fallback
Transcription data: stored locally only — only metadata uploaded to server