Post cover image

August 31, 2026

How an IDOR + OSINT Investigation Exposed a Company

How an unauthenticated IDOR on a vehicle sales platform leaked corporate Invite Codes and broke the intended eligibility model for bespoke…

By foorw1nner

3 min read

How an unauthenticated IDOR on a vehicle sales platform leaked corporate Invite Codes and broke the intended eligibility model for bespoke pricing.

Summary

redacted.com operates a vehicle sales and customization platform where access to certain pricing is tied to a company's employee benefit scheme.

A key part of that flow is the company Invite Code.

That code is not meant to be public or generally accessible. The platform itself explains that it should be provided directly by the user's HR team, and that users without it can still browse vehicles but cannot access bespoke pricing.

In practice, this makes the Invite Code part of the application's business trust model: receiving it is what distinguishes a regular visitor from someone who is supposed to have access to company-specific pricing.

The issue we found broke that assumption.

A value intended to stay within the relationship between the company, its HR team, and eligible employees could be obtained by someone outside that flow and then reused during registration.

The result was a direct bypass of the platform's intended eligibility model for bespoke vehicle pricing.

The IDOR

The vulnerable endpoint behaved like this:

POST /api/get-driver-by-email HTTP/2
Host: redacted.com
Content-Type: application/json
{
  "email": "user@redacted.com"
}

Changing the email address was enough to retrieve information associated with other users.

For a regular user, the response contained data similar to:

{
  "getDriverByEmail": {
    "driver": {
      "company": {
        "inviteCode": null,
        "quoteJourney": "standard"
      }
    },
    "message": null,
    "statusCode": 200
  }
}

At this stage, the impact still looked limited.

The interesting detail was that inviteCode was always present, even though it was null for every normal account we tested.

Looking at the Registration Flow

The next clue came from the registration process.

At one point, the application asked the user for a company Invite Code and explained that the code should be provided by the user's HR team.

Users without a code could continue with limited access, but bespoke vehicle pricing was not available to them.

This meant the inviteCode field was not just another piece of account metadata.

It was connected to a business rule.

The question then became simple:

If regular users always have inviteCode: null, who actually has a real value there?

Testing a Different Class of Users

Because the endpoint accepted arbitrary email addresses, we used OSINT to identify publicly available employee email addresses belonging to companies using the platform.

We tested several of them.

Most responses were exactly the same as before:

"inviteCode": null

Then one account returned something different:

None

That changed the meaning of the bug completely.

The code was not something we obtained from an email, an HR platform, or an internal company system.

It came directly from the vulnerable API.

The only thing we needed was the employee's email address.

Using the Leaked Code

The leaked value could then be entered into the application's registration flow:

https://redacted.com/your-salary-sacrifice-scheme/invite-code

This was the same place where the application told users that the Invite Code should be obtained from HR.

Without a valid code, the user could browse the available cars but would not have access to bespoke pricing.

With the leaked code, that restriction could be bypassed.

Turning Point

At that point, the issue was no longer just about reading another user's data. The IDOR was exposing a value that the application itself treated as proof that the user had legitimately received access through their company.

Impact

The practical impact came from chaining a few simple observations together.

The endpoint allowed arbitrary email lookups.

Public sources made employee email addresses discoverable.

Some of those accounts contained a real Invite Code.

And that Invite Code controlled access to functionality that normal users could not use.

An attacker could therefore identify employee email addresses, query them through the vulnerable API, find an account with a non-null Invite Code, and reuse that code during registration.

This exposed a trust boundary in the application.

The platform expected the Invite Code to come from the company's HR team, but the same value could be recovered from another user's account through the IDOR.

Because possession of the code was enough to unlock bespoke vehicle pricing, the vulnerability crossed from a data exposure issue into a business-logic bypass.

Why This Was Interesting

What made this finding interesting was that the impact was not obvious from the first request.

If testing had stopped after checking only regular accounts, the issue would have looked much less important.

Every response showed the same thing:

"inviteCode": null

The difference came from asking what that field represented, who might have a different value, and what the application did with it elsewhere.

That small change in perspective turned a basic IDOR into a much more meaningful business-impact issue.

Timeline

  • Discovered & reported: vulnerability identified and submitted through HackerOne.
  • Triage: confirmed and validated by the security team.
  • Resolved: October 7, 2025–11:37 UTC.
  • Reward: $500 USD.

Contacts