One Vendor, $100, and a Breach That Reached Every School That Trusted Them

How a routine graduation photo platform exposed student data across Ontario and Quebec, and what it took to get a response.

I uncovered a serious security flaw in a graduation photo company's platform. It could expose personal student data at every university and college that uses them across Ontario and Quebec. I reported it the right way. For three months, they didn't answer a single email, call, or voicemail. After I escalated to the universities, they fixed it quietly — and paid me $100.

Here's the part that should actually worry you: I have no idea how long that door was open before I found it, or who else walked through it first.

How I found it

In April 2026, I graduated from a university in Ontario. Like thousands of students, my grad photos went through a third-party vendor.

While using their platform, I found a broken access control vulnerability — one that could let a user view another user's personal data instead of their own.

The information exposed included:

• Full name
• Email address
• Phone number
• Full home address
• Graduation photographs
• Institution attended
• Payment receipts

This wasn't a theoretical bug. It was a live door into the personal records of students at multiple colleges and universities, across two provinces — and there was nothing stopping anyone who found it from walking through, before me, after me, or instead of me.

I tested only the minimum necessary to confirm it was real. No enumeration, no bulk extraction, no retained data. Then I reported it responsibly and gave the company every chance to fix it quietly and professionally.

The technical root cause, for those who want to know: this was a broken access control / insecure direct object reference (IDOR) issue, one of the most common and well-documented vulnerability classes in web applications. In short, the platform determined which user's data to return based on a client-supplied value, rather than properly verifying server-side whether the requesting session was actually authorized to view that specific user's record. That gap was enough to retrieve another user's profile data.

How it worked, at a high level: the profile endpoint identified "which account am I serving" using a client-supplied identifier sent back on every request, rather than deriving that from a server-validated, authenticated session. Change the identifier, and the server handed back a different user's record — no ownership check in between. This is the textbook shape of an IDOR: the server trusts the client to say who it's asking for, instead of checking who it's actually talking to.

The three months of silence

Here's what "responsibly" got me:

• [June 3, 2026]Full disclosure sent, offering a technical walkthrough and proposing a standard 90-day coordinated disclosure window.
• [June 10, 2026]Follow-up requesting acknowledgment. Silence.
• [September 8, 2026]Third email, plus repeated phone calls and a voicemail. Still nothing but an automated receipt.

Three months. A vulnerability sitting wide open on a platform handling the personal data of students at institutions across two provinces. And the company responsible for protecting it did not respond to a single email, call, or voicemail.

Going to the universities

At that point, I had a choice: keep waiting, or make sure the institutions whose students were actually at risk knew what was going on. I chose the latter — not to cause a scene, but because the students actually at risk deserved to know their vendor wasn't responding to a legitimate security warning about their own data.

That's what worked. Two days after university security teams received my email, the CEO reached out personally — explaining that my reports had apparently been sitting in a spam/deleted folder the entire time.

The quiet fix

We began arranging a call so I could demonstrate the issue directly, with written terms covering good-faith treatment, authorization, data handling, and confidentiality — standard practice in vulnerability coordination.

Before that call ever happened, the vulnerability was patched — quietly, over a weekend. No notice to me. No notice, as far as I know, to the universities I'd warned. No explanation of how long it had been live. No audit of who may have accessed it. Nothing.

I followed up to ask for an update. The CEO still didn't mention the fix was already live:

I've since independently verified that the fix is in place. That part is genuinely good news.

But let's be clear about what we still don't know: nobody — not me, not the universities, and, based on what they've told me, not even the vendor — knows how long this was exploitable, or whether someone with far less restraint than me already has that data sitting in a folder somewhere. Without an audit, that question stays open.

The reward

When I asked what their process was for recognizing security researchers who report vulnerabilities in good faith, this is the reply I got:

For a flaw affecting student data across two provinces, reported responsibly, and unresolved for over three months.

Why this matters beyond me

This isn't really about me, or about $100. It's about:

• Universities need to vet their vendors' security posture before signing contracts. A vendor's responsiveness to a security report is part of that posture.
• A quiet fix without an audit leaves an open question. If a vendor doesn't know how long a flaw existed, they can't say whether data was accessed before it was patched.
• Responding to good-faith security reports matters. A disclosure that goes unanswered for months gives a researcher fewer options than one that gets a timely reply.

I followed the disclosure process I outlined from the start. The fix came after the universities were contacted, three-plus months after my first report.

Students trusted this platform with their personal information. I hope this account helps other researchers and institutions think about how disclosures like this one get handled.

Timeline of events referenced in this post is based on my own email records. Screenshots and correspondence above have been redacted to remove personally identifying information not relevant to the public interest in this disclosure.