July 12, 2026

Unauthenticated PII Disclosure on a Major Automaker’s B2B Auction Portal — Enabled by a Missing…

Assalam o alaikum muslims and hello for non muslims i hope all of u are doing great and keep learning every day, i am back with another…

By Be nice insabat

6 min read

Assalam o alaikum muslims and hello for non muslims i hope all of u are doing great and keep learning every day, i am back with another story so lets start the main topic without wasting any time

FREE LINK https://medium.com/@InsbatArshad/unauthenticated-pii-disclosure-on-a-major-automakers-b2b-auction-portal-enabled-by-a-missing-24a980f66729?sk=595d694fa53a95fc92b7ae153a6f3890

A writeup of a sensitive data exposure finding on a large enterprise bug bounty program, and the twists it took to get properly triaged.*

While testing a used-machinery/industrial-equipment auction platform run by a large automotive manufacturer (redacted here at my own discretion, though the finding is public on Bugcrowd), I came across a public-facing subdomain hosting a B2B marketplace where the company auctions off surplus factory equipment — CNC parts, drivetrain components, tooling, and similar.

The public interface only shows currently active, published auction listings. Nothing unusual there. But the listing detail endpoint told a different story once I looked at how it actually built its URLs — and that route ended up leading somewhere more serious than exposed listings: an unauthenticated path to a real employee's personal contact information.

The Endpoint

Every listing was reachable at a pattern like:

https://<target>/gmb/machineAnonymousList/view/{id}

Where {id} was a plain sequential integer. The lowest ID visible anywhere in the public UI was in the ~191,241 range. Nothing unusual about that either — until I started requesting IDs below that visible floor, with no session, no cookies, no authentication at all.

curl -s "https://<target>/gmb/machineAnonymousList/view/180000" \
 -H "User-Agent: Mozilla/5.0 (X11; Linux x86_64)" \
 -w "\nHTTP Status: %{http_code}\n"

HTTP 200. Full listing detail, unauthenticated:

<h4 class="modal-title">
 gm_180000: [equipment description redacted], Auction Ref. #19830
</h4>
<td>Minimum price per unit (€):</td>
<td>700,00</td>
<td>Plant:</td>
<td>[Plant location]</td>

This listing didn't exist anywhere in the public listing index. It was either delisted, expired, or never meant to be publicly reachable — yet the server happily returned it in full, including its minimum reserve price, to anyone who guessed the ID.

Confirming It Wasn't a One-Off

I checked a second ID further into the range:

curl -s "https://<target>/gmb/machineAnonymousList/view/191000"

Same result — full listing, reserve price of €7,620.00, plant location, internal auction reference number. Same pattern, same lack of any access check.

To rule out "maybe the whole ID space is just open by design," I tested an ID in between that I expected to behave differently:

curl -o /dev/null -s -w "%{http_code}\n" "…/view/190000"
# → 302 (redirects to login)

curl -o /dev/null -s -w "%{http_code}\n" "…/view/180000"
# → 200 (full data, no auth)

curl -o /dev/null -s -w "%{http_code}\n" "…/view/191000"
# → 200 (full data, no auth)

That inconsistency — some IDs correctly redirecting to a login wall, others returning full data with zero authentication — is the tell. This isn't intentional public access to an archive. It's a missing authorization check: the endpoint pulls a row by ID and renders it, without ever asking "should this specific request be allowed to see this specific listing?"

The Real Issue: Unauthenticated Exposure of Employee PII

Each listing could have attached documents — internal procurement paperwork, spec sheets, sale terms. Those lived at a sibling endpoint:

https://<target>/gmb/machineAnonymousList/download/{listingId}/{docId}

Same story:

curl -s "…/download/191100/320203" -o document.docx

HTTP 200. A real internal .docx file, downloaded with no session at all. Running it through a converter to check the contents, it wasn't just equipment specs — it contained an internal employee contact block: a name, a direct mobile number, a corporate email address, and a specific plant/hall location. That's a real person's personal contact information, disclosed to anyone on the internet who could guess a two-integer path, with no authentication of any kind.

This is the core of the finding: not "an ID returned data it shouldn't," but a concrete, unauthenticated PII disclosure — a named individual's direct phone number and email address, extractable from a document the platform believed was access-controlled. The IDOR was simply the vehicle that got me there.

Impact, Summarized

  • Unauthenticated employee PII exposure: a real employee's name, direct phone number, and email address, extracted from an internal document served with zero access control — the most serious impact of this finding.
  • Full enumerability: because IDs were sequential integers with no rate limiting tied to this behavior, the entire historical document/listing set was walkable with a simple loop, meaning this wasn't a one-off leak but a systemic path to more PII across other listings' attached documents.
  • Unfair market advantage: anyone — including competing bidders — could enumerate unlisted or delisted auctions and learn their minimum reserve prices ahead of time, undermining the integrity of the bidding process.
  • Internal data exposure: auction reference numbers, plant/factory locations, and equipment details that were never meant to be public.

Root Cause

At its core, this is a PII disclosure vulnerability enabled by a missing authorization check. The /view/{id} and /download/{id}/{docId} endpoints fetched and served data purely based on the IDs in the URL, with no server-side check confirming the requester was authorized to see that specific listing or document, or that the listing was even in a published/active state. The application was relying on the obscurity of "the ID isn't shown in the UI" rather than an actual authorization boundary — and because one of the exposed document types happened to contain a real employee's direct contact information, that missing check translated directly into unauthenticated personal data disclosure, not just "extra" business information.

The Triage Rollercoaster

This is the part I think is genuinely worth sharing, because it's a good example of why a "Not Applicable" close isn't always the end of the story.

My initial submission was closed same-day with a fairly boilerplate response: "the observed access falls within allowed system access patterns… findings that reveal only information… without demonstrable impact are not eligible."

I didn't think that response actually engaged with what I'd shown — sequential IDs returning full reserve prices and downloadable internal documents, with zero authentication, is not "allowed access patterns" by any reasonable read. I filed a Request for Response laying out the concrete impact again. That request expired without action, which could easily have been the end of it.

Except it wasn't. Four months later, a different triager on the program picked the submission back up — unprompted, as far as I know — re-reviewed it, updated the VRT classification (first to Sensitive Data Exposure, then settled on Broken Access Control / IDOR), and marked it Triaged, confirming Bugcrowd's own team had reproduced the issue and handed it to the company's internal security team for review.

Lessons

  1. A same-day "Not Applicable" isn't always correct — if you're confident the impact is real and clearly demonstrated, it's worth pushing back once with a clear, evidence-first rebuttal rather than assuming the first answer is final.
  2. Sequential integer IDs are still everywhere, even on large, mature enterprise platforms. Always test just below and around the visible range, not just within it.
  3. Chain the "boring" finding into something concrete. "This ID returns data it shouldn't" is a fine start, but "this ID returns a downloadable document containing a real person's contact information" is what actually moves a triager.
  4. Patience matters. Triage queues on large programs can sit for a long time, and a stale, expired Request for Response doesn't necessarily mean the submission is dead — sometimes it just needs the right reviewer to look at it again.
  5. Keep mapping the neighborhood after the first fix lands. A confirmed root cause (missing authorization check on one endpoint) is a strong hint the same gap exists on sibling endpoints. Going back and checking the broader module — rather than considering the job done after one accepted finding — is what turned a single-record PII exposure into a bulk, dedicated-database exposure worth a real severity escalation.

Update: This Was Bigger Than One Document

While waiting on a status update for the original submission, I went back and mapped the surrounding endpoints on the same platform more broadly — specifically, the parts of the application responsible for listing contacts and enumerating auction entries from the very start of the flow, not just the individual view/download endpoints already reported.

What I found was a bulk, unauthenticated contact-listing endpoint that returns what appears to be hundreds of individual contact records — names, phone numbers, and email addresses — in a single request, with no authentication required. Alongside it, the main listing enumeration entry point showed the same pattern of exposing data that should have required a session.

This changes the shape of the finding considerably. The original report demonstrated a single employee's contact details, incidentally embedded inside one internal document that happened to be reachable without authentication. What this follow-up shows is a dedicated contact database being served in bulk, with no access control in front of it at all — not PII as an unintended byproduct of a document leak, but a listing endpoint that appears purpose-built to return contact data, doing so to anyone who requests it.

I recorded a short screen capture walking through the live enumeration and attached it to the existing report rather than filing a new submission, since the root cause is identical: the same class of missing server-side authorization check, just present across more of the module than initially scoped. I've also asked the triage team to reconsider the severity in light of the scale — moving from "one confirmed record, reachable via a specific document" to "an open, unauthenticated door to a large contact database" is a meaningful jump, not just more of the same.

I'll update this writeup with the final resolution and severity once the client's review concludes.

— -

  • This finding is currently in the Triaged state, pending final review and severity assignment by the program owner. This writeup will be updated once it reaches a final resolution.*

Stay curious, and keep your scripts clean.

If you learned something new, dont forget to leave claps and your thoughts below