I found a Vulnerability. They found a Lawyer. | Blog | Yannick Dixken [email protected]:~/blog/i-found-a-vulnerability-they-found-a-lawyer [home] cd .. I’m a diving instructor. I’m also a platform engineer who spends lots of his time thinking about and implementing infrastructure security. Sometimes those two worlds collide in unexpected ways. A Sula sula (Frigatebird) and a dive flag on the actual boat where I found the vulnerability – somewhere off Cocos Island. While on a 14 day-long dive trip around Cocos Island in Costa Rica, I stumbled across a vulnerability in the member portal of a major diving insurer – one that I’m personally insured through. What I found was so trivial, so fundamentally broken, that I genuinely couldn’t believe it hadn’t been exploited already. I disclosed this vulnerability on April 28, 2025 with a standard 30-day embargo period. That embargo expired on May 28, 2025 – over eight months ago . I waited this long to publish because I wanted to give the organization every reasonable opportunity to fully remediate the issue and notify affected users. The vulnerability has since been addressed, but to my knowledge, I have not received confirmation that affected users were notified. I have reached out to the organization to ask for clarification on this matter. This is the story of what happened when I tried to do the right thing. The Vulnerability To understand why this is so bad, you need to know how the registration process works. As a diving instructor, I register my students (to get them insured) through my account on the portal. I enter their personal information with their consent – name, date of birth, address, phone number, email – and the system creates an account for them. The student then receives an email with their new account credentials: a numeric user ID and a default password. They might log in to complete additional information, or they might never touch the portal again. When I registered three students in quick succession, they were sitting right next to me and checked their welcome emails. The user IDs were nearly identical – sequential numbers, one after the other. That’s when it clicked that something really bad was going on. Now here’s the problem: the portal used incrementing numeric user IDs for login. User XXXXXX0, XXXXXX1, XXXXXX2, and so on. That alone is a red flag, but it gets worse: every account was provisioned with a static default password that was never enforced to be changed on first login. And many users – especially students who had their accounts created for them by their instructors – never changed it. So the “authentication” to access a user’s full profile – name, address, phone number, email, date of birth – was: Guess a number. Type the same default password that every account shares on account creation. There’s a good chance you get in. That’s it. No rate limiting. No account lockout. No MFA. Just an incrementing integer and a password that might as well have been password123 . I

Source: Hacker News | Original Link