In plain English
A public settings file handed over the keys, and the login flow never checked who was actually signing in.
The technical account follows below, for readers who want the detail.
Three lessons any team can use
Secrets shipped to the browser are public secrets.
A login token is only as strong as the check behind it.
Every environment deserves testing, not just production.
The Challenge
A global luxury brand ran an internal admin portal whose frontend build shipped a public config file with Survey API secrets and a LINE login integration ID. The sign on flow behind that ID checked nothing about who was logging in, so any holder of a standard LINE account out of more than 200 million received a valid token, and one internal microservice had no authorization middleware at all.
How We Proved It
Combined the leaked credentials with a freshly minted token to hit the internal survey API, proving forged entries at a pace of 80,000 a day, forged consent flags, and leaked department identifiers, while sibling services correctly returned 401s. Then proved the identical flaw across integration, pre production, and production, so each environment paid as its own asset. Initially scored 8.2, settled at 6.5 on data sensitivity grounds, and patched everywhere by late March with authorization checks now enforced on every login.
Redacted brand
Apr 26, 2026
Bug Bounty
Full Writeup
Researched and disclosed by Ridwan Adebayo. Read every step, payload, and takeaway.
Read on MediumRelated Case Studies
More disclosures from our researchers.
Know your risk. Strengthen what matters.
Tell us where you are, what you rely on, and what you need to protect. We will help you understand what to do next.