November 2, 2026
Responsible Disclosure: the art of the “Silent Patch” and bad faith
A few weeks ago, I stumbled upon a critical configuration flaw (RLS — Row-Level Security) on an online platform’s Supabase instance. The…

By ShadowScanner
1 min read
A few weeks ago, I stumbled upon a critical configuration flaw (RLS — Row-Level Security) on an online platform's Supabase instance. The vulnerability exposed their entire database: tens of thousands of users, emails, messages, and internal data.
True to my ethics, I decided to initiate a responsible disclosure process. What followed is a textbook example of what a company should not do when dealing with a security researcher.
October 5th: First Contact I sent an email to their support team to report the discovery and ask for a secure communication channel. I immediately received a reassuring automated reply: "A real person reads every message and we reply within one business day."
November 1st: The Awakening Almost a month passed without a single word. Then, I finally received an email from the person in charge: "Sorry for the slow reply. Please send the full details. We take reports seriously and fix confirmed issues quickly." They also mentioned in passing that they don't run a paid bug bounty (which wasn't my goal anyway).
I found the 28-day delay a bit rich for a company claiming to address issues "quickly," but I sat down to prepare my report.
The Plot Twist (Caught Red-Handed) Before sending my explanation, I ran a quick check on their endpoint to verify the current state of the vulnerability. And there, the system returned a beautiful error message:
"hint": "Your legacy API keys (anon, service_role) were disabled on 2026-10-06T06:15..."
You read that right. On October 6th, exactly one day after my initial alert email, they quietly revoked their API keys and scrambled to patch the vulnerability in the background.
They knowingly used my alert to silently plug the holes, only to reach out a month later, playing innocent and asking for details as if they were completely unaware. It was a blatant display of bad faith — or perhaps a clever way to get me to QA their fixes for free.
The Final Blow (and Ethics) The most ironic part of their October 6th panic? In their rush to patch the system, they created a brand-new administration table… and forgot to secure it. This new table, still publicly accessible, happily exposed administrator roles, password hashes, and the new API keys.
Because I make it a point to maintain strict ethics, I replied to them anyway. I reported this newly left-open vulnerability, while casually letting them know I had caught their October 6th "silent patch." I also strongly recommended that, in the future, they be a bit more transparent and respectful of security researchers' time.
The Moral of the Story If a researcher contacts you to help prevent a massive data leak: don't play games. Thank them, be transparent about your actions, and don't pretend to be responsive a month after you quietly panicked in the backend. Ethics goes both ways.