DoorDash Email Spoofing Sparks Heated Security Disclosure Feud

A significant security vulnerability within DoorDash’s corporate platform recently came to light, enabling unauthorized individuals to dispatch emails that appeared entirely legitimate, originating directly from the company’s official no-reply@doordash.com address. This flaw opened the door for highly deceptive phishing attacks, as anyone could create a DoorDash for Business account, add fictitious employees, and generate custom emails using the platform’s built-in administrative tools. These messages arrived in recipients’ inboxes looking completely authentic, bypassing spam filters and carrying the full branding and layout of genuine DoorDash communications.

The issue was identified by a security researcher operating under the pseudonym doublezero7, who demonstrated how an attacker could inject arbitrary HTML into email content. By manipulating a budget name field stored as plain text in the database, it became possible to alter or hide portions of the email and insert malicious content. Although certain event handlers were blocked by email clients, the vulnerability still allowed for the creation of convincing fraudulent messages. This method closely resembled a previously reported weakness in Uber’s email system, showing that such risks are not isolated.

Frustrated by what they described as a prolonged period of inaction, the researcher decided to escalate the situation after more than fifteen months had passed without a resolution. According to their account, the initial report submitted through HackerOne was closed without being properly escalated, leaving the security gap wide open. Only after the researcher began sending direct emails to DoorDash, some of which included demands for payment, did the company deploy a patch, reportedly within hours of receiving what was characterized as an ultimatum.

DoorDash, however, disputes this version of events. A company spokesperson stated that the individual involved attempted to extort payment and was subsequently banned from their bug bounty program. They emphasized that the reported issue fell outside the scope of the program and maintained that their security team acted appropriately once the matter was brought to their attention. HackerOne, the platform managing the bug bounty program, confirmed that all actions taken were consistent with their code of conduct and the customer’s policy, though they did not comment on why the original report was labeled “Informative.”

The researcher acknowledged using what they termed a “less ethical” approach in their final communications with DoorDash, including a conditional offer to sign a compensated non-disclosure agreement. They defended this by pointing to the company’s extended neglect of the vulnerability, arguing that public pressure was the only reason a fix was implemented. While the flaw did not directly expose user data or provide access to internal systems, its potential for enabling convincing phishing campaigns made it a serious concern.

This incident underscores the often delicate and contentious relationship between security researchers and the companies they try to assist. Disagreements over compensation, response times, and communication protocols can quickly turn cooperative disclosure into a public dispute. In this case, both sides accuse the other of acting unethically, the researcher claims they were ignored and then silenced, while DoorDash alleges the researcher crossed a line by demanding money.

Ultimately, the vulnerability is now resolved, but the disagreement surrounding its disclosure highlights broader challenges within the bug bounty ecosystem. It serves as a reminder that clear communication, mutual respect, and well-defined program guidelines are essential for effective and ethical security collaboration.

(Source: Bleeping Computer)