TaxJar: org owner could hijack any member's account

What happened

@akashhamal0x01 found that TaxJar (tax management SaaS, part of Stripe's bug bounty program on HackerOne) let an *Organization Owner* modify the email address of any member within their organization.

Attack flow:

1. Attacker creates or controls an org on TaxJar. 2. Victim is a member of that org. 3. Attacker *overwrites the victim's email* with an attacker-controlled address. 4. Triggers a password reset to the new email. 5. Full account access — account taken over.

The member-management API didn't validate whether the `email` field should be writable by an org-level role. TaxJar patched it by blocking Organization Owners from editing email fields on other users' accounts.

Why it matters

This pattern is endemic to B2B multi-tenant SaaS (shared infrastructure serving multiple customer organizations). Org roles tend to inherit too many permissions by design — «owner manages the org» quietly becomes «owner can edit any member attribute,» including identity fields that should never be reachable from that role.

Blast radius: mass account takeover. An org with 500 members = 500 accounts hijackable with legitimate, authenticated API calls. No CVE, no 2FA bypass needed.

Bug class: Broken Access Control — #1 on OWASP (Open Web Application Security Project — the authoritative list of critical web application vulnerabilities). The specific failure: business logic conflated «manage org» with «edit user identity.»

What to do

Hunting on B2B or multi-tenant SaaS targets:

• Map member-management endpoints: `PUT /org/members/{id}`, `PATCH /users/{id}/profile`. Check if they accept `email` or `phone` fields.
• Authenticate as org owner: attempt to change another member's email. Server accepts it? Broken Access Control confirmed.
• Chain the technique: email change → password reset = IDOR (Insecure Direct Object Reference — accessing or modifying another user's data without authorization) + ATO chain (attack chain ending in Account Takeover — full account compromise). A medium-severity bug becomes critical.
• Always test every identity field: phone, username, recovery codes — anything that enables credential reset carries the same impact.

This bug lives at the intersection of business logic and the permission model — exactly where automated scanners miss it. You find it by reading the API and reasoning about what each role *should* be able to do to other users' data.