Summary

  • DoorDash's own security update describes an incident that arrived through a phishing attack on a third-party vendor, not through an intrusion into the delivery platform's own systems.
  • Across the four records examined here, no document states how many people were affected and none publishes a test showing the fix held, which leaves what a victim publishes and whom it contacts as the only auditable part of this kind of failure.

The first move was a text message. Twilio's account of the August 2022 campaign describes employees targeted with SMS-based phishing, credentials harvested, and unauthorised access to internal systems, with roughly 125 of its customers caught in the aftermath (Twilio). DoorDash appears in that account as one of the affected customers, and the company's own newsroom update describes the same route from the other end: a phishing attack on a third-party vendor that exposed user information and prompted direct notice to the people involved (DoorDash security update).

The intruder never needed to reach DoorDash. The identity channel that the platform rented was compromised at the supplier, and the access that followed was to records DoorDash had handed over in the ordinary course of business. That is the shape of the incident: not a wall breached, but a courier reading the parcel.

What the update actually states. The categories are specific. Names, email addresses, delivery addresses, order history and partial payment information were accessed. The exclusions are equally specific: no full payment card numbers, no passwords, no account login credentials. The company says it notified affected users directly and worked with the vendor to secure the environment.

The retained record places that update in November 2022. It carried no publication timestamp, so the month is what the documents say rather than a dated byline, and nothing in the four records reviewed here fixes a calendar day. Readers who need the day will not find it here; they will find the month.

Detection credit belongs to the supplier. This matters more than it sounds. The intrusion was found and described by the vendor whose employees were phished, not by the platform whose data moved. DoorDash's document is a notification: it tells people what was taken, what was spared and what the company did next. Nowhere in it is a claim that DoorDash detected the campaign. The supplier published its own account; the platform's document reads like what a customer writes after being told.

That is not negligence. It is the geometry of supplier-routed failure. A company cannot monitor an environment it does not operate, cannot rotate credentials it does not hold, and cannot see a login it never receives. What it can do is publish and contact. Those two acts are the whole of its controllable conduct, and therefore the whole of what the public record can fairly be used to audit.

The notification test. Judged on that narrower standard, a disclosure of this kind has four auditable parts. Quantity: does the victim say how many people were affected? Inventory: does it name what was taken and, just as usefully, what was not? Verification: does anything in the record test whether the fix held, rather than describe the intention to fix? Attribution of detection: does the account say who found the intrusion?

DoorDash's update passes inventory and notification cleanly. It names the data categories, names the exclusions, and states that users were contacted directly. Detection credit is properly the supplier's, and the supplier published its own account. Quantity is missing. Verification is missing. Two independent reports from late November 2022 describe the same vendor-phishing route and both note that the public notifications did not carry a specific count of affected individuals (TechCrunch) (BleepingComputer).

To be precise about the boundary: across the four records I read for this piece — DoorDash's security update, Twilio's account of the campaign, and those two reports — no document gives a number of affected DoorDash users, and none publishes an audit result, attestation or measured control change that would show the repair held. That is a statement about four documents, not about the world. A regulator filing with a count may exist outside them; it was not read here, and no inference should be drawn from its absence in this file.

What would change the classification. A notification becomes a demonstrated repair when three things appear beside it. A number, because exposure that cannot be sized cannot be provisioned against. An attestation or a tested control, because "worked with the vendor to secure the environment" is a description of activity, not evidence of outcome. And a named subprocessor, because a customer cannot assess a risk that the supplier list hides.

None of the three is exotic. Regulators in several jurisdictions already require the first. Contract renewals already carry the second, in the form of security schedules with audit rights. The third is a procurement question, and it is the cheapest of the lot.

This desk has written about DoorDash before, on a different document. The earlier case file examined a 2019 access event that also arrived through a third party; the November 2022 update is a separate disclosure about a separate mechanism, and the distance between the two is itself informative. Both incidents travelled the same kind of road. Neither public account tells a reader how many people were on it.

A notification is not a remedy. It is the receipt for one. The number and the test are what turn the receipt into a record a board can rely on — and on this incident, in the four documents reviewed here, both are still owed. If you want to know how a platform behaves when the failure is outsourced, do not ask whether it detected the intrusion. It could not. Ask what it disclosed, whom it told, and whether anyone ever proved the door had been shut.

Directory record: DoorDash, Inc.