Bug bounty hunting is all about carefully looking at applications, finding small mistakes, and turning them into big security wins. Recently, I participated in the Bug Bounty Village CTF at DEF CON, and I'm excited to share that I ranked 19th on the offline leaderboard!

The CTF felt like a real bug bounty site, packed with unique flags and challenges. To top it off, my prize was none other than Labubu 🐰, a quirky and fun reminder of the amazing experience.

Big thanks to Bug Bounty Village, DEF CON for building such a welcoming community space, and to CTF.ae for creating a unique, world-class CTF experience unlike anything I've seen before.

While participating, I came across two particularly interesting vulnerabilities in the GeneQuest challenge application. Both bugs could have serious real-world impact if left unfixed. Let's dive into the details.

🐞 Bug #1 — Default Credentials in JavaScript File

🔍 The Discovery

While analyzing the GeneQuest login page, I inspected the JavaScript files loaded by the application. One file (page-adcba167c0921bff.js) contained something unusual: hardcoded default credentials.

Username: support@genequest.io
Password: GeneQuest123!
None

These credentials were openly visible in client-side code, which is accessible to anyone with a browser.

🛠 Steps to Reproduce

  1. Open the login page: https://internal-0c63e5ebfeed0d2b.genequest.io/login
  2. Open Developer Tools → Network tab.
  3. Reload the page and locate the JS file: /static/chunks/app/(auth)/login/page-adcba167c0921bff.js
None
  1. Open the file and observe the credentials.
  2. Use them to log in successfully.
None

⚠️ Impact

With these credentials, any attacker could directly log in as a privileged user, gaining access to sensitive data or internal tools.

✅ Remediation

  • Never hardcode credentials in client-side code.
  • Use secure vaults or environment variables.
  • Immediately rotate and invalidate exposed credentials.

🐞 Bug #2 — Sensitive Data Exposure in Registration API

🔍 The Discovery

While testing the registration API, I noticed that the response contained more data than it should. When creating a new user account, the API returned an internal flag value in the first_name field.

🛠 Steps to Reproduce

Send a registration request with curl:

curl -X POST "https://api-e033d93e9a1757d0.genequest.io/api/v2/auth/register" \
-H "Content-Type: application/json" \
-d '{
  "username": "testuser",
  "email": "test@test1.com",
  "password": "test1!",
  "confirm_password": "test1!",
  "name": "Test User"
}'

📥 Response

{
  "username": "testuser",
  "email": "test@test1.com",
  "id": "3ef53fb8-a8a3-4301-848c-78fcc2a6f4db",
  "first_name": "flag{3bfb8b28cbe01f67}",
  "last_name": "",
  "role": "CUSTOMER",
  "subscriptions": [],
  "balance": 6000,
  "waived_hipaa": false
}
None

Notice the first_name field — it contains a flag value instead of a user's name. This should never be exposed in production.

⚠️ Impact

  • Any unauthenticated attacker could repeatedly register accounts to harvest internal flags or secrets.
  • Could lead to privilege escalation or other data leaks.

✅ Remediation

  • Limit API responses to only necessary fields.
  • Sanitize and validate all returned data.
  • Audit all endpoints for accidental information disclosure.

🎯 Key Takeaways

  • Never expose secrets in client-side code — attackers can (and will) look through JavaScript files.
  • APIs should return only what's needed — the principle of least privilege applies to responses too.
  • Both vulnerabilities fit into well-known security categories:

CWE-798: Use of Hardcoded Credentials

CWE-200: Information Exposure

🚀 Final Thoughts

This experience at Bug Bounty Village, DEF CON was more than just about solving CTF challenges. It was a reminder that real-world vulnerabilities often hide in plain sight, waiting for someone to notice.

None

Ranking 19th was a proud moment for me, and winning Labubu 🐰 made it extra fun. More importantly, the CTF community — from the organizers to fellow hunters — made this an unforgettable learning journey.

None

I'm looking forward to more challenges, more hunts, and more chances to keep the internet a little safer.