Reporting a vulnerability

Email [TBD]. Please include what you found, where, and enough detail to reproduce it — a request, a sequence of steps, a screenshot. If you have a proof of concept, send it; if it is destructive, describe it instead of running it.

Machine-readable contact details are at /.well-known/security.txt.

1. Acknowledge within three business days.
2. Tell you within ten business days whether we have reproduced it and what we think it is.
3. Keep you updated while it is open, rather than going quiet after triage.
4. Tell you when it is fixed.
5. Credit you publicly if you would like, or not if you would rather not.

We are a small operation. There is no bug bounty and no monetary reward, and we hold no SOC 2 or equivalent certification. What we can offer is a fast, honest answer from someone who reads the code.

If you follow this policy, we will treat your research as authorised, will not pursue civil action or report you, and will say so if a third party raises it.

To stay inside it:

1. use only accounts you own or have written permission to test;
2. stop as soon as you have confirmed a problem — do not read, alter or keep anyone else’s data, and if you access some by accident, tell us and delete it;
3. do not degrade the service: no denial of service, no load testing, no spam;
4. do not place calls or send messages to real people as part of testing, and never dial 9-1-1 — that path is out of scope entirely; and
5. give us a reasonable chance to fix it before publishing.

ringfully.com, app.ringfully.com, admin.ringfully.com, api.ringfully.com, and the Windows desktop softphone.

Particularly interested in:

1. Anything crossing organizations. Reading, writing or inferring one customer’s data from another’s account is the most serious class of bug this product can have.
2. Anything crossing the two session realms. Customer sessions and our operator console are signed with different keys on purpose; a token from one being accepted by the other would matter a great deal.
3. Getting past the call-flow egress firewall. A call flow may make outbound HTTP requests, restricted to an administrator-approved allowlist and validated inside DNS resolution. Reaching an internal address through it is a finding.
4. Authentication, session handling, or permission checks that can be bypassed.
5. Anything letting you place calls or send messages on an account that is not yours.

1. Anything requiring physical access, or a compromised device or mailbox.
2. Social engineering of our people or our customers.
3. Denial of service, volumetric testing, or brute forcing.
4. Missing security headers or a weak TLS suite with no demonstrated impact.
5. Automated scanner output with no working exploit behind it.
6. Findings in a third-party service — report those to Twilio, AWS or Stripe directly.
7. The emergency-calling path. Do not test it in any way. Its known limitations are published on the emergency calling page.

Known gaps we have already published are not findings — the security page lists them, and telling us we have no certification is not news.