Account Takeover Across Multiple Programs via Featurebase Integration

I discovered this issue during a bug bounty engagement in October 2025. I discovered an IDOR leading to Account Takeover (ATO) in a third-party provider that works with many organizations.

before this Let me clear the concept first:

The provider is: https://featurebase.app/

Featurebase provides a feedback and feature request platform used by many organizations.

The common way to figure out if your target is using this provider or not is by visiting the following subdomain on target

feedback.example.com

feedback.example.com

You can identify many deployments using Google dorks or Shodan

site:feedback.*.*

site:feedback.*.*

This is how the page will look

Now the Question arises how we are going to exploit this vulnerability.

Step 1 (Via IDOR)

We have to register an account on any target feedback.example.com
Check for the following endpoints

POST /api/v1/user/identify

POST /api/v1/user/identify

and also, in request body it should be

{
  "organization":"example",
  "email":"victim@example.com",
  "name":"Jeet Pal",
  "userId":"733244",
  "profilePicture":"https://..."
}

{
  "organization":"example",
  "email":"victim@example.com",
  "name":"Jeet Pal",
  "userId":"733244",
  "profilePicture":"https://..."
}

Here we have to modify the userId for the someone else to takeover account via email change functionality.

In response then you can view the Email changed after that you can ask for reset password and then takeover the account.

( it was consider as medium due to third party)

After this I got to know about that if we just change the name from the Setting page or make a request towards the following path

POST /api/v1/user (during account modification)

POST /api/v1/user (during account modification)

We can have the access token of the user too. which you can use to make a request for modify the settings at

PATCH /api/v1/user

PATCH /api/v1/user

From here you have the access token of user and takeover the account too.

Currently the vulnerability is not totally being fixed via feature base as their reply was this is not our issue instead it should be fix by websites owner. but here is alternative path which feature base provide to secure the site using JWT you can read more about them here Secure your installation (required by default) — Featurebase

Root Cause

The application trusted client-controlled identity attributes without validating whether the supplied userId actually belonged to the authenticated user. This allowed an attacker to impersonate another Featurebase account.

New articles Dropping soon

Connect with me Linkedin: https://www.linkedin.com/in/jeet-pal-22601a290/ Instagram: https://www.instagram.com/jeetpal.2007/ X/Twitter: https://x.com/Mr_mars_hacker

And here's something special for you! 🚨

Join a community of 4000+ security researchers on our Discord server, where we discuss Web3 vulnerabilities, audits, and much more! 🚀 👉 Join the server here! : https://discord.gg/Y467qAFM4X

Contents

And here's something special for you! 🚨