The Hacker Who Reached Out to a Food Delivery Startup First

TL;DR

A security researcher found a critical vulnerability in a food delivery startup's app and emailed the team before doing anything malicious. They gave the startup 7 days to fix it before disclosing. The engineering team fixed it in 3, thanked the researcher publicly, and the researcher became an informal advisor. Sometimes the "hackers" are the good guys looking out for you.

The Email

The subject line made the CTO's heart skip: "Security Vulnerability in Your Application."

She expected spam or a scam. Instead, she found a professionally written report:

"Hi, I'm a security researcher. While testing your application, I discovered a server-side request forgery (SSRF) vulnerability in your webhook integration. An attacker could use this to access your internal infrastructure. I have not exploited this beyond confirming its existence. I'm giving you 7 days to fix this before I disclose it publicly, per responsible disclosure practices."

Attached was a detailed write-up: steps to reproduce, potential impact, and suggested fixes.

The Vulnerability

The startup's webhook feature let restaurant partners specify a URL to receive order notifications. The problem: the platform didn't validate those URLs properly.

An attacker could provide a URL like http://169.254.169.254/ (AWS metadata service) or internal network addresses. The server would make the request and return the response, essentially becoming a proxy for accessing things it shouldn't.

With this vulnerability, an attacker could potentially:

  • Access AWS credentials from the metadata service
  • Scan the startup's internal network
  • Access internal services not exposed to the internet

It was serious. Very serious.

The Response

The engineering team took this seriously from minute one:

  1. Hour 1: Acknowledged receipt and thanked the researcher
  2. Hour 2: Verified the vulnerability was real
  3. Day 1: Implemented a fix (URL validation, blocking internal IPs)
  4. Day 2: Tested the fix thoroughly
  5. Day 3: Deployed and notified the researcher

They fixed it in 3 days, well before the 7-day deadline.

The outcome: No exploitation. No data breach. No customer impact. Just a vulnerability found and fixed before anyone could abuse it.

The Thank You

After deploying the fix, the CTO sent the researcher a thank-you email. She asked if there was anything the team could do in return.

Their response surprised her: "A public acknowledgment would be great. It helps my reputation as a researcher and shows other companies that responsible disclosure works."

The startup did better than that:

  • Published a blog post thanking the researcher by name
  • Created a security.txt file with contact info for future reports
  • Offered them 6 months of free delivery credits (they declined but appreciated the gesture)
  • Added them to a security credits page

Why This Went Well

1. The Researcher Acted Responsibly

They didn't exploit the bug. They didn't sell it. They didn't publicly shame the startup. They gave the team time and information to fix it.

2. The Team Responded Quickly and Professionally

No defensiveness. No denial. No weeks of silence. They acknowledged, verified, fixed, and thanked.

3. They Made It Easy to Report

Even though the startup didn't have a formal security contact at the time, the general support email was responsive. The researcher's email didn't get lost in spam.

The realization: Not everyone looking for vulnerabilities is malicious. Many are ethical researchers who want to help. How you respond determines whether they become allies or adversaries.

What the Startup Changed

Security.txt File

The team added a /.well-known/security.txt file with contact information, making it easy for researchers to know how to reach them.

Clear Response Process

They documented how to handle security reports: who gets notified, expected response times, and communication templates.

Public Acknowledgment Policy

The startup created a policy to publicly thank researchers who report vulnerabilities responsibly, with their permission.

Ongoing Relationship

The researcher who found the SSRF became an informal advisor. They've since flagged two more minor issues. The startup built a relationship based on mutual respect.

What is responsible disclosure?

Responsible disclosure is when a security researcher reports a vulnerability to a company privately, gives them time to fix it, and only goes public after the fix is deployed (or a reasonable deadline passes).

How should I respond to a security researcher report?

Respond quickly, even just to acknowledge receipt. Thank them for the report. Verify the issue. Provide a timeline for fixing it. Keep them updated. Thank them publicly (with permission) after the fix.

Should I offer bug bounties?

Formal bug bounties work for larger companies but require resources to manage. For smaller companies, simple acknowledgments, swag, or free service can show appreciation without the overhead of a formal program.

What if a researcher is aggressive or unreasonable?

Most researchers are professional, but if someone is threatening or demanding unreasonable payments, document everything and consult legal counsel. Don't engage in hostility, but don't be extorted either.

Find Issues First

Discover vulnerabilities before researchers (or attackers) do.

Security Stories

The Hacker Who Reached Out to a Food Delivery Startup First