← All posts

Insights6 min read

From Out-of-Scope to Critical: Turning One Rejected Bug Report Into a 50-Organization Research Methodology

How an unauthenticated endpoint in a third-party feedback widget led to account takeover across dozens of companies — and a reusable methodology for finding it, called TBDSR.

Every bug bounty hunter learns the same reflex early: if it's a third-party service, it's out of scope, move on. That instinct is usually correct. This is the story of the one time it wasn't — and what happened when a rejected report got dragged back into scope by the vendor's own words.

The dismissal

While testing a mature application under a public bug bounty program, I found nothing. Authentication held. Authorization survived every horizontal and vertical probe. Business logic did exactly what it advertised.

At the bottom of the page sat two links I'd skipped all day: Feedback and Changelog. A board opened on a separate subdomain, and in the footer: "Powered by Featurebase." Third-party vendor, someone else's code, not my program — I almost closed the tab.

Days later, reviewing saved proxy history out of habit, one request stopped me.

The finding

POST /api/v1/user/identify
Host: [REDACTED].featurebase.app
Content-Type: application/json

{"organization":"[REDACTED]","email":"attacker@example.com","userId":"[CHOSEN-ID]"}

HTTP/2 200 OK
Set-Cookie: featurebase-access-[ORG-ID]=jwt-token; ...

{ "success": true, "user": {...}, "access": { "token": "jwt-token", "orgId": "[ORG-ID]" } }

On a correctly configured deployment, this call must be cryptographically signed by the integrating application's backend before Featurebase trusts the asserted identity. On this deployment, identity verification hadn't been enabled. The platform accepted whatever identity the browser handed it and minted a valid, server-signed session for it.

Tested only against two accounts I controlled (one attacker, one victim), the impersonated token worked for real authenticated actions — profile edits, comments, votes. The problem was never the token. A correctly signed token asserting an unverified identity is worse than no token at all: it looks trustworthy to everything downstream.

Rejected, then reversed

The program's first response was a decline: third-party surface, vendor's problem, out of scope. Reasonable, on the facts they had.

So I went to the vendor. Featurebase's security team confirmed the platform behaved as designed — identity verification exists specifically to prevent this, and enabling it is the integrator's responsibility. The insecure state existed because the customer had deployed the integration with signing disabled.

That single clarification reframed the question. Not "is Featurebase vulnerable?" — no, out of scope. But "who controls the configuration that makes this exploitable?" — the integrator, in scope. The vulnerability hadn't changed by one byte. Only who owned it had.

I resubmitted with the vendor's confirmation attached. The program reversed:

"...the Featurebase identify call from our application should be signed with a server-generated identity verification hash, and currently it isn't. That makes the impersonation vector real and the remediation ours."

They shipped server-side signing, enforced verification, and I confirmed the unsigned path was rejected on retest.

The bigger question

If one experienced engineering team deployed this insecurely, how many others had made the same mistake?

That question turned a single accepted report into an ecosystem-wide investigation. A Featurebase deployment fingerprints itself — *.featurebase.app hosting, the "Powered by Featurebase" marker, predictable feedback/changelog/roadmap subdomains. None of that is the vulnerability; it's the address. It only tells you where to ask the one real question: is identity verification enabled here, or not?

Trust-Boundary–Driven Security Research (TBDSR)

Component-oriented testing — endpoints, parameters, auth, business logic — is why the primary application held up in the first place: every component was individually sound. But it has no dedicated step for the moment one system delegates an identity decision to another. That handoff isn't an endpoint. It's a relationship, and relationships don't live inside any single component's box.

TBDSR reframes the unit of analysis from component to trust relationship, in ten phases that loop back on each other:

  1. Observe — inventory every embedded/third-party surface the target depends on.
  2. Architecture Review — read the vendor's own integration and security docs first.
  3. Integration Mapping — find where identity, authorization, or trusted state crosses the boundary.
  4. Trust Analysis — who is trusting whom, and on what evidence?
  5. Identity Verification Analysis — is identity proven, or merely claimed?
  6. Configuration Review — does the secure mode exist, and is it turned on here?
  7. Repeatability Assessment — individual mistake, or population-level pattern?
  8. Responsible Validation — confirm impact using only researcher-controlled identities, one non-destructive request per target.
  9. Mass Discovery — where a VDP or bounty program authorizes it, identify other affected deployments non-destructively.
  10. Responsible Disclosure — report to whoever owns the fix (usually the integrator, not the vendor), with root cause, an accurate CVSS vector, and remediation guidance.

The central, portable question, applicable anywhere identity crosses an organizational boundary: is trust proven, or merely claimed?

Scale and severity

On deployments where the impersonated identity fronted real user content or data, the impact was High severity:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L → 8.6 (High)

An unauthenticated attacker could obtain a valid session as an arbitrary user, no privileges or user interaction required.

Applying TBDSR responsibly — testing only organizations with a published bug bounty program, VDP, or responsible disclosure policy, and validating with one non-destructive request per target — the results across the ecosystem: 50+ organizations reported, 16 rewards, 3 Hall-of-Fame acknowledgements, with several more fixed silently.

Remediation

  • Enable Featurebase identity verification and require it in production.
  • Generate the identity signature (HMAC/JWT) server-side; never expose the secret to the client.
  • Reject any identify call that is unsigned or fails signature verification.
  • Reference: help.featurebase.app — Secure your installation

Root cause: a default/insecure installation pushed to production — the integration trusted client-supplied identity instead of verifying a server-generated signature. Secure installation must be completed before production use.

The takeaway

Third-party doesn't mean someone else's responsibility. In bug bounty programs, "third-party" often gets read as "ignore it." In reality, the vendor's platform may not be vulnerable at all — the failure can live entirely in how the target configured and trusted it. A surface that looks permanently out of scope can become a valid, in-scope finding the moment an organization misconfigures the trust relationship between its own application and an external service.

Don't stop at "is this out of scope." Ask how the target trusts the thing it embedded, and what happens if that trust is set up wrong.

This is a condensed account of an original research paper. Companies are anonymized, all identifiers and tokens sanitized, and all proof-of-concept testing was performed exclusively against researcher-controlled accounts — one attacker, one owned victim. No real user or administrator account was accessed, altered, or deleted. Findings are published post-remediation.

Research by Sujan Thapa Magar — Independent Security Researcher, Trinity Technology Pvt. Ltd. trinitytech.com.np · LinkedIn · Twitter/X