From One Tracking URL to Every DoorDash Customer's PII

TL;DR

DoorDash's Drive order tracking flow leaks PII through two separate unauthenticated paths. The first hands out chat-system credentials that enumerate every customer's name and live presence at the rate of thousands per hour. The second is a sequential-integer IDOR on an order-status endpoint that returns customer full names, home addresses, GPS coordinates accurate to the door, dasher full names, and dasher personal phone numbers, again with zero authentication.

The first bug was closed by HackerOne triage as Not Applicable one minute after submission. The second one is worse: HackerOne accepted the original report nine months ago, Bugcrowd independently triaged a re-submission as P1 two months ago, and as of today the endpoint still returns thousands of customer home addresses to anyone with a single HTTP request.

The Two Bugs

Bug #1 — Sendbird chat credentials handed out unauthenticated (CVSS 7.5, High). The Drive tracking page needs to put the customer into a chat with the dasher without making them log in, so it calls a GraphQL mutation that returns full Sendbird user credentials. The mutation does not check anything. Once you have the credentials, you are a real Sendbird user inside DoorDash's chat tenant, and DoorDash uses sequential integer IDs for every customer. From there it is one Sendbird REST call per name. Ten parallel sessions clear ~25,000 customer names per hour from one laptop. The data class is real names plus live online/offline presence.

The credentials are also full Sendbird users, not channel-scoped tokens, which means an attacker can change the nickname on their own account and post into an active delivery chat as “DoorDash Support.” Any in-flight delivery is then a social-engineering surface where a stranger with an authoritative-looking name can ask the customer for confirmation codes, address corrections, or anything else “support” might plausibly ask for. That's a phishing channel that inherits DoorDash's brand trust at zero cost to the attacker.

Bug #2 — an order-status endpoint with a sequential integer identifier and no authentication (CVSS 9.1, Critical / P1). The same Drive tracking experience hits a backend endpoint that maps a sequential tracking_number to a complete order record. No auth, no session, no rate limit. Increment the integer, walk the record set. Each response includes the customer's full name, full street address, GPS coordinates to seven decimal places, internal consumer IDs, the assigned dasher's full name and personal phone number, store details, and in some cases delivery instructions and building entry codes. The currently valid integer range covers roughly the last several thousand active Drive deliveries on a rolling window, enumerable in minutes by a script.

I'm intentionally not pasting the endpoint path, the exact parameter, or the curl. The bug is live and DoorDash customers are still exposed.

The Nine-Month Gap

This is where the writeup stops and I start ranting a bit about the state of security research in the age of AI slop. The whole point of a triage process is that humans with context look at incoming reports and make judgment calls. The whole point of accepting a vulnerability report is that you intend to fix the vulnerability. Both of those points went out the window here, in different ways, at different stages.

The order-status IDOR was originally reported to DoorDash through HackerOne approximately nine months before this writeup. The program accepted it as a valid finding. That means a human looked at it, ran it, and agreed: yes, an unauthenticated attacker can pull every recent customer's home address and the dasher's phone number from a single sequential identifier. Critical, accepted, queued for remediation.

I found it independently while investigating the Sendbird bug. My first HackerOne report on it was closed as out of scope on the backend hostname, the same scope-tag classifier failure mode that killed the Sendbird report. Today, after re-confirming exploitability against fresh, rotating tracking numbers from a different IP, I re-submitted with the framing the program needed: the vulnerable backend serves an in-scope consumer asset, the bug is in the customer namespace, and here is the evidence. That submission was closed as a duplicate of the nine-month-old report, citing the original as “triaged and accepted by the program.”

Same endpoint. Same lack of auth. Same data classes returned. The bug is still live. The original report is still “accepted.” Nothing has changed.

In parallel, after the HackerOne side stalled on both bugs, I was re-routed to DoorDash's Bugcrowd engagement by their own Global Threat Defense Team. Bugcrowd triaged the order-status bug as P1, the highest severity tier, and acknowledged the customer team had been notified. That was about two months ago. I requested an update once. The customer-side response window expired with nothing on it. The bug is still live.

The Triage Nightmare

Bug #1 (the Sendbird credential leak) ran into a different failure mode at the same vendor. Compressed timeline:

My perspective on security research in the current age

Companies like DoorDash process tens of thousands of bug bounty reports a year, and that number is only rising as AI-slop reports pile up. This forces the triage process to lean harder on automation. What used to be a security analyst's judgment is increasingly a classifier, a regex-and-LLM pipeline that sorts incoming reports into real, duplicate, out of scope, or spam. When that pipeline gets it right, programs stay functional. When it gets it wrong, the bug doesn't exist as far as the program is concerned.

The Sendbird close is the textbook failure of that pipeline. A human reading the report (an unauthenticated chain that ends at the real name of every DoorDash customer who has ever used chat) does not close it in sixty seconds with a scope tag and a severity downgrade to None. That close is a classifier firing on the hostname. The hostname is on the ineligible list, so the report gets stamped, the severity gets zeroed, and the queue moves on.

The order-status IDOR is a different failure, and it's the more serious one. The triage classifier got this one right. A human looked at it nine months ago and accepted it. The bug entered the remediation queue. And then it sat there. For nine months. While customer home addresses, with sub-meter GPS, were one HTTP request away from anyone who knew the parameter name.

Whatever broke between “accepted” and “fixed,” it broke for long enough that an independent researcher found the same bug, reported it, was told it was already known, watched a second program triage it as P1 with no remediation, and then confirmed it live two months later. That is not a noise problem. That is not an AI problem. That is a program looking at a finding that exposes the physical location of its customers and deciding, implicitly, that fixing it can wait.

This is a sign of where bug bounty and security research are headed if nothing changes. The volume of reports keeps growing, the automation keeps tightening, and the bugs that need a human to actually read them keep getting auto-closed in sixty seconds. The ones that do get through to a human can still sit in a remediation queue for the better part of a year. The classifiers don't catch the long tail. The long tail is where the bugs that hurt users live. The next one of these won't be reported by someone who writes a blog post about it. It'll be found by someone who sells the data.

I'm not the only one this happened to.

Six weeks ago Lovable got hacked for almost the same reason on the triage side. A researcher reported a BOLA on their HackerOne program, triage closed it without escalation, and the vulnerability sat exposed for 48 days. Source code, database credentials, and thousands of customer records leaked because the first-pass triage decision called the data exposure “intended behavior” and every subsequent attempt to re-report it was marked a duplicate of that close. Same shape as this report on the way in. Now multiply the timeline by six and apply it to physical-safety data.

Where to go from here

We need to take a hard look at what bug bounty triage and remediation have become in the age of AI slop. Programs are drowning in low-quality, LLM-generated reports, so they are leaning harder on automation to keep up. The reports that fall through the cracks are not the noise. They are the bugs that don't pattern-match cleanly against a scope rule or a CVSS template, the ones that need a human to actually read past the hostname — and the ones that, even after a human reads them and accepts them, can sit unfixed for the better part of a year because nothing forces remediation on the clock that the customer-data exposure is running on.

Those are exactly the bugs that hurt users when they get missed and exactly the bugs that hurt users when they get accepted and ignored. The faster triage gets, the more of them disappear before a human reads them. The longer remediation drifts, the more of them remain exploitable after a human reads them. The next one won't land in mine or another researcher's inbox. It will land in a customer's, the hard way, when someone with the data shows up at the door it points to.

On the small chance anyone at DoorDash with context on the Drive order-status endpoint is reading this: the original report you accepted is still exploitable as of today. The right people inside your company already know how to find it.