Not every disclosure ends with a handshake. Some end with silence. This is one of those but I did my part, so it’s my story to tell.
I’ll keep the company anonymous throughout. It’s a large Bengaluru-based health and diagnostics company the kind that runs corporate health checkups and preventive-care memberships, handling lab reports for a lot of people. The point of this post isn’t to name and shame. It’s the pattern, and how the whole thing went.
It Started With a Family Member’s Report
Someone in my family had a checkup done through them. The report came as a link to a PDF. Normal stuff you click it, the report opens.
Old habits. I glanced at the URL. It looked roughly like this:
https://[company].s3.ap-south-1.amazonaws.com/[company]/MemberReportData/LabReport/20260001XXXX.pdfTwo things jumped out immediately.
One: it’s a raw Amazon S3 link. Not behind a login, not proxied through their app the PDF is served straight from an S3 bucket in the ap-south-1 (Mumbai) region.
Two: the filename is a sequential number. ...XXXX.pdf. Just a counter.
If you’ve done this long enough, your stomach drops a little at that combination.
The Part I Was Hoping Wasn’t True
A public bucket plus sequential filenames means one thing: you can change the number and get someone else’s file.
So I changed the last digits. Different report. A different person’s lab results name, tests, values, all of it. Changed it again. Another one.
No login. No token. No permission check of any kind. Just edit the number in the address bar and you’re holding a stranger’s medical record.
I walked the number down to find the range. The counter went up to roughly 19,000. Which means about 19,000 patients’ lab reports were sitting in a bucket that anyone on the internet could read, one incrementing integer at a time.
This is the textbook version of two classic issues stacked on top of each other:
- Public object storage. The bucket was readable with no authentication.
- Insecure Direct Object Reference (IDOR) via enumeration. Sequential IDs mean you don’t even need a leaked link. You can just count.
To be clear about what this was and wasn’t: this was a misconfiguration, not a break-in. I didn’t bypass anything, crack anything, or exploit a clever flaw. The front door was wide open and the files were numbered 1, 2, 3…. That almost makes it worse.
Why This One Actually Matters
Lab reports aren’t a leaked email list. This is health data, about the most sensitive personal information there is, and under India’s Digital Personal Data Protection Act, 2023, an exposure like this can count as a reportable personal data breach with real penalties attached.
But forget the law for a second. This is 19,000 real people who never agreed to have their medical results sitting on the open internet, one number away from anyone who thought to look. I really didn’t want that to become a headline. So I tried to make sure it wouldn’t.
I Wrote to the Founders
I didn’t post anything. I didn’t tweet a screenshot. I found the CEO and CTO and emailed them directly, privately, with enough detail to be taken seriously and enough restraint to be responsible. Redacted, here’s essentially what I sent:
Dear founders,
While viewing a family member’s lab report from your system, I noticed a security issue I wanted to bring to your attention directly.
Your lab report PDFs are stored in an Amazon S3 bucket (region ap-south-1) that is configured as publicly readable, with no authentication, and the files are named using sequential numbers. As a result, changing the number in a report’s URL loads a different patient’s report, meaning the records of what appear to be around 19,000 patients are openly accessible to anyone with a single link, just by editing the number in the address bar.
This is a misconfiguration rather than an intrusion, but an exposure of health data like this may be treated as a personal data breach under India’s Digital Personal Data Protection Act, 2023.
I’d suggest moving from sequential filenames to non-guessable IDs and serving reports only to authenticated users to prevent a recurrence.
I’m happy to walk you or the team through exactly what I found once you’ve acknowledged this, including the specific bucket and an example URL, so we can confirm the fix.
Regards, Ashutosh Shukla
Clear, direct, no drama, and deliberately incomplete. Then I waited.
What Happened Next: Nothing. And Then, Quietly, Everything.
No reply. No acknowledgment. No “thanks, we’re looking into it.” Not a single line back.
But a little while later, I checked. The bucket was locked down. The public access was gone. The reports no longer loaded from a naked S3 link, and the trick of counting through IDs was dead.
So they read it. They understood it. They fixed it. And they decided I didn’t warrant a reply.
Why the Silence, Probably
Let me be clear about my side first: there was no motive here. No bounty program, no payout, no angle. I found something serious by accident, and flagging it was simply the responsible thing to do. So this was never about not getting a thank-you. A one-line acknowledgment is basic courtesy, but courtesy isn’t what I was after.
What I actually think is more telling: the silence may have been deliberate. Acknowledging a health-data exposure in writing creates a paper trail. Under the DPDP Act, confirming that around 19,000 patients’ records were publicly accessible is confirming a reportable data breach, the kind that can carry serious penalties. An email that says “you’re right, thank you, we’ve fixed it” is also an email that documents they knew. Staying quiet, patching it, and acting like it never happened is the path that minimizes their legal exposure, even if it’s the worse one for everyone’s trust. Save-your-own-skin over acknowledge-and-be-decent.
I can’t prove that’s the reason. But it’s the reading that makes the silence make sense.
And it doesn’t change the outcome that matters: the reports are safe now. Around 19,000 people who will never know any of this happened aren’t going to have their medical results harvested one integer at a time. The disclosure did its job, even if the people on the other end never said so.
That’s the part I control. I did my part.
If You’re Building Something That Stores People’s Data
The fix here is unglamorous and completely standard:
- Default-deny your buckets. S3 is private by default for a reason if reports are public, someone made them public. Turn on Block Public Access and keep it on.
- Never use sequential or guessable filenames for anything sensitive. Use long random identifiers (UUIDs) so a URL can’t be enumerated.
- Don’t serve sensitive files straight from storage. Put them behind your app, check that the logged-in user is allowed to see this specific record, and hand out short-lived pre-signed URLs not permanent public links.
- Assume the URL will leak. Links get forwarded, cached, screenshotted. Access control can’t live in the secrecy of the URL.
Any one of those would have prevented this. All four are a boring afternoon of work. The alternative is 19,000 people’s health records one integer apart from anyone who thinks to look.
Company, individuals, and the exact bucket are intentionally anonymized. The exposure has been fixed.
Found something similar and not sure how to report it? Reach out happy to help you do it right.