“I found that I could access over 181,000 private meeting recordings by simply changing a number in the URL.”
This isn’t a sophisticated breach. It isn’t a zero-day in some complex encryption layer. It is a textbook case of an Insecure Direct Object Reference (IDOR) vulnerability—the kind of mistake that usually gets you laughed out of a first-year computer science lab. The fact that this happened at scale in a tool designed to record the most sensitive parts of corporate communication is a special kind of failure.
The mechanics here are embarrassingly simple. As detailed in the write-up by bobdahacker, the application failed to verify if the user requesting a recording actually had permission to see it. If you had the URL for a meeting, you could just increment the ID in the request and move linearly through the database. It’s essentially like finding a hotel where the room keys are just pieces of cardboard with numbers on them, and the staff never asks for your ID at the front desk.
(I suspect this happened while the team was chasing a VC milestone). When you’re racing to ship features to keep up with the AI hype cycle, the “boring” stuff—like authorization middleware—is often the first thing to get truncated. You don’t see this in legacy enterprise software because the legacy software was built by people who were terrified of getting fired for a data leak. Modern “move fast and break things” culture has just extended “break things” to include “break the privacy of 181,000 customers.”
We are talking about meeting recordings. In a corporate context, these aren’t just chats about where to go for lunch. These are strategy sessions, salary negotiations, product roadmaps, and internal vents about the CEO. The sheer volume of data—nearly 200,000 recordings—means that for a significant chunk of their user base, the “private” nature of their meetings was a total fiction.
Who actually audits this stuff before it goes live? The vulnerability was so blatant that it didn’t require a specialized toolkit to find, just a curious mind and a browser. This is a complete failure of basic engineering.
There is a recurring pattern here. Most of these AI note-takers are effectively wrappers around a few core APIs. The “value add” is the UI and the prompt engineering, but the infrastructure is often bolted together with duct tape and hope. They are treating security as a feature to be added in v2.0 rather than a prerequisite for v1.0. It’s the same energy as a restaurant that opens for business before they’ve installed a working sink in the kitchen.
This isn’t an AI problem; it’s a CRUD problem. The “AI” part is just the shiny object that distracts the developers (and the investors) from the fact that the underlying API is a sieve. We’ve seen this movie before with every gold rush in tech—the tools that promise the most “productivity” usually have the most holes in their hull.
Absolutely not. Not until they can prove they have a security posture that extends beyond “we hope nobody notices the URL parameters.” If you are a developer or a manager plugging these bots into your Zoom calls, you are effectively inviting a stranger into your boardroom and hoping they don’t decide to start recording everything for the public.
The industry has traded security for time-to-market, and the cost is now being paid in plaintext. I suspect we will see at least three more high-profile IDOR leaks from “AI productivity” tools before the end of Q4. Until these companies move away from the “ship first, patch later” mentality, they are liabilities, not assets.
The risk is simply too high for the reward of a slightly better meeting summary.
