Imagine receber um e-mail de phishing que não é falso. Uma vulnerabilidade DoorDash permitia exatamente isso, permitindo que cibercriminosos enviassem mensagens fraudulentas a partir do endereço oficial [email protected], tornando o golpe praticamente impossível de ser identificado pelo usuário comum. A falha foi corrigida, mas revelou algo ainda mais preocupante, a polêmica sobre a divulgação, que gerou um conflito de 15 meses entre o pesquisador doublezero7, a DoorDash e a plataforma HackerOne.
Este artigo explica como a falha técnica funcionava e analisa o conflito que envolve acusações de negligência, má gestão de bug bounty e suposta tentativa de extorsão, um caso que está repercutindo fortemente na comunidade de cibersegurança.
O que era a vulnerabilidade de phishing na DoorDash?
A falha, embora séria, não era tecnicamente complexa. Ela estava localizada na plataforma empresarial DoorDash for Business, usada por empresas que oferecem créditos de refeição para funcionários. O pesquisador doublezero7 descobriu que era possível injetar HTML personalizado no campo “nome do orçamento”. Esse HTML era renderizado diretamente no corpo do e-mail enviado ao funcionário, permitindo ocultar ou substituir o conteúdo legítimo e inserir qualquer mensagem maliciosa, como um falso cupom ou um link fraudulento. O ponto crítico, que amplificava o risco da falha de segurança DoorDash, era que o e-mail vinha de servidores oficiais da empresa, passando normalmente por filtros de spam e serviços de autenticação como SPF, DKIM e DMARC. O resultado, na prática, era um phishing “perfeito”, enviado por um domínio legítimo e praticamente indistinguível de uma comunicação oficial.
A longa espera, 15 meses de silêncio e a versão do pesquisador
Do ponto de vista do pesquisador, o caso é um exemplo clássico de falha na gestão de um programa de bug bounty. Depois de identificar a vulnerabilidade, doublezero7 a reportou ao programa oficial da DoorDash, que é administrado pela plataforma HackerOne. O relatório, identificado como 2608277, foi classificado pela empresa como “Informativo”, o que significa que a falha foi considerada sem impacto direto e não gerou ação imediata. Para o pesquisador, isso foi um erro grave. Segundo ele, por mais de 15 meses, a vulnerabilidade permaneceu ativa, sem que o caso fosse escalado, revisado ou corrigido. Ao perceber que nada estava sendo feito, doublezero7 decidiu pressionar a empresa. Primeiro tentou reforçar o contato via HackerOne, e depois buscou a DoorDash diretamente, algo que ele próprio classificou posteriormente como uma abordagem “menos ética”, ao mencionar pagamento em troca de prazos de divulgação. Em posts públicos, ele afirmou que só adotou essa postura após mais de um ano de silêncio, e que a vulnerabilidade teria continuado ativa se ele não tivesse pressionado. Como disse o pesquisador, “Sem a minha pressão pública, essa vulnerabilidade ainda estaria ativa hoje.”
A tentativa de extorsão, o que diz a DoorDash?
A DoorDash, porém, apresenta uma versão radicalmente diferente. Na resposta oficial, a empresa afirma que o pesquisador tentou extorquir pagamento atrelado a prazos rígidos de divulgação, algo que viola tanto as diretrizes de disclosure responsável quanto o próprio Código de Conduta da HackerOne. De acordo com a empresa, depois de meses sem contato, o pesquisador teria retornado com exigências de pagamento e ameaças de divulgar detalhes da vulnerabilidade em prazo curto caso não fosse recompensado. A empresa também declarou que o problema estava “fora do escopo” do programa de bug bounty, mesmo tendo corrigido rapidamente a falha após o ultimato público do pesquisador. A HackerOne, por sua vez, apoiou a decisão e baniu doublezero7 da plataforma, reforçando que sua conduta violou regras fundamentais do ecossistema de bug bounty. Para o pesquisador, porém, o banimento teria sido uma retaliação após a divulgação pública da negligência da empresa.
O dilema ético, quem está certo na disputa do bug bounty?
O caso expõe uma zona cinzenta que há anos é debatida por profissionais de segurança. O que acontece quando uma empresa classifica como “Informativo” um relatório que deveria ser tratado como crítico? Pesquisadores frequentemente se veem em um limbo, sem resposta, sem recompensa e sem garantia de que a vulnerabilidade será corrigida. Por outro lado, a pressão direta com exigência de pagamento e prazos agressivos pode facilmente ser interpretada como tentativa de extorsão, mesmo quando a intenção do pesquisador é apenas acelerar a correção. A polêmica bug bounty DoorDash revela como a falta de comunicação transparente pode transformar um simples relatório de vulnerabilidade em uma crise pública. Um ponto especialmente sensível neste caso é a chamada “correção silenciosa”. A DoorDash corrigiu completamente a falha poucas horas após o ultimato de doublezero7, o que confirma a gravidade da vulnerabilidade, mas não ofereceu crédito nem recompensa ao pesquisador. Na comunidade de segurança, esse tipo de situação gera preocupação, porque desestimula pesquisadores independentes e incentiva métodos mais agressivos de divulgação, aumentando o risco de conflitos semelhantes.
Conclusão, uma falha corrigida, uma relação quebrada
A boa notícia é que a vulnerabilidade da DoorDash foi corrigida, eliminando um vetor gravíssimo de phishing que poderia ter sido explorado em larga escala. Para milhões de usuários dos aplicativos de entrega, esse incidente não representa mais um risco imediato. A má notícia é que o caso expõe falhas profundas nos processos de bug bounty e na relação entre empresas e pesquisadores. A combinação de má comunicação, classificações equivocadas e respostas tardias criou um cenário onde ambos os lados saíram prejudicados. A DoorDash foi criticada por negligência e má gestão, enquanto o pesquisador foi banido e acusado de violar regras éticas. Para o público geral, a lição permanece clara, sempre desconfie de e-mails, mesmo quando parecem vir de fontes legítimas, porque falhas desse tipo podem surgir em qualquer serviço. Para empresas, o episódio serve como alerta, uma má gestão de vulnerabilidades pode se transformar não só em risco de segurança, mas também em prejuízo reputacional e atritos com a comunidade que deveria ajudar a proteger seus usuários.
