It happened. Here's what to do.

• Rotate every key the report named — old values are compromised forever, assume they are already in use.
• Revoke active sessions/tokens so a stolen session can't keep working after you rotate keys.
• Take the leaking endpoint offline (or lock it down) until the fix is deployed.
• Keep a timestamped note of what you did and when — you'll need this for "First day" and "Telling people".

Work out what data was reachable — your report's exposure grade is a good starting point for what a stranger could have seen.

If it was personal data belonging to people in the UK or EU, the 72-hour window under UK/EU data protection law applies to controllers — in plain terms, a "controller" is whoever decides why and how personal data is processed (usually: you, if it's your app and your users). If that's you, the clock most likely started when you first knew.

Report a breach to the ICO here: ico.org.uk/for-organisations/report-a-breach/.

A short, honest email beats a long, defensive one. No blame, say what happened, what you fixed, what they should do.

Subject: Important security update about your [PRODUCT] account

Hi [NAME],

On [DATE] we found that [WHAT WAS EXPOSED, PLAIN LANGUAGE] was reachable
by someone without logging in. We don't have evidence anyone [READ /
DOWNLOADED / MISUSED] it, but we're telling you so you can protect
yourself.

What we did: [WHAT YOU FIXED, e.g. "closed the database access and
rotated every key involved"].

What you should do: [E.G. "reset your password" / "watch for phishing
emails using this data" / "no action needed"].

We're sorry this happened. If you have questions, reply to this email
or contact [CONTACT].

— [YOUR NAME]

• Retest until every affected finding shows VERIFIED — a fix you haven't retested is a fix you're hoping worked.
• Add monitoring so a regression is caught automatically, not by another stranger.
• Write the post-mortem in one page: what happened, why, what changed so it can't happen the same way twice.