Security & vulnerability disclosure

How to report a security issue to sprintrr — and what to expect back.

See also our Trust page for the broader security program, our Sub-processors list, and our Privacy Policy. RFC 9116 machine-readable contact lives at /.well-known/security.txt.

Reporting a vulnerability

Please do not file a public GitHub issue, post on social media, or open a support ticket for security reports — those channels are public and may expose other users.

Email support@sprintrr.ai with Security report in the subject. The inbox is monitored by the founder/security lead; security-flagged messages are triaged ahead of general support. Include:

  • A description of the issue and its impact.
  • Steps to reproduce (a proof-of-concept is appreciated).
  • The affected URL / endpoint / component / version.
  • Your name and a contact channel for follow-up (optional but appreciated).

Response targets

  • Acknowledgement: within 2 business days.
  • Initial assessment: within 5 business days.
  • Mitigation: driven by CVSS severity — critical issues are prioritized for same-week patching; lower-severity items are tracked in our internal backlog with a documented remediation target.
  • Confirmed personal-data breaches: we notify affected customers within 72 hours per our DPA and our Privacy Policy.

Scope

In scope

  • sprintrr.ai and *.sprintrr.ai web properties.
  • The hosted MCP API at https://www.sprintrr.ai/api/mcp.
  • The @sprintrr/mcp-server npm package.
  • Our source code, CI workflows, and dependencies.

Out of scope

Please do not test against these — report to the upstream owner instead:

  • Third-party services we depend on (Supabase, Vercel, Anthropic, OpenAI, Google, Polar, Resend, Cloudflare, Upstash) — report to the vendor.
  • Denial-of-service or volumetric attacks.
  • Social engineering of our staff, contractors, or users.
  • Physical attacks against infrastructure, staff, or devices.
  • Attacks requiring physical access to a victim’s device.
  • Reports from automated scanners without a working proof-of-concept.
  • Missing security headers / cookie flags without a demonstrated impact.
  • Outdated TLS / cipher suites that are already disabled at the edge.

Safe harbor

We will not pursue legal action against researchers who:

  • Make a good-faith effort to comply with this policy.
  • Avoid privacy violations, destruction of data, and interruption or degradation of our services.
  • Only interact with accounts they own or accounts with the explicit permission of the account holder.
  • Do not exfiltrate data beyond what is necessary to demonstrate the vulnerability.

Coordinated disclosure

We follow the principle of coordinated disclosure. Please give us a reasonable window — typically 90 days — to remediate before publishing details. We will credit you in any related advisory unless you prefer to remain anonymous.

What this is not

This is a vulnerability disclosure policy. It is not a paid bug bounty — we do not currently offer monetary rewards. We may revisit that decision as the security program matures.

Other channels

General support / privacy / data subject requests: support@sprintrr.ai

RFC 9116 contact file: /.well-known/security.txt

Effective May 17, 2026. This policy may be revised; the version on this page is always current.