Final update [5/29/14] – We've finished re-enabling links we know couldn't have been vulnerable. If links to some of your files are still disabled, you may receive an email prompting you to either create new, secure links, or re-enable the previous links. Again, thanks for your patience as we work to keep your stuff safe.
Update [5/8/14] — We wanted to let you know that you now have the option to re-enable all your disabled links.
Please keep in mind that re-enabling the same link means that whoever received it in the past can use it again to view your document. If you don’t want to re-enable all your links at once, you can create new ones by following these instructions.
Update [5/7/14] — A quick update on what we’re doing to get you back to your normal workflows.
For now, shared links to file types that might contain a hyperlink (such as PDF or Word docs) created before May 5 remain deactivated. Over the coming days, our team will gradually begin re-enabling shared links that aren’t susceptible to the vulnerability. You can re-create your own links now by following these instructions. If you’d prefer to re-enable all disabled links — either because you know your files contain no sensitive info, or because you’re less concerned about the potential vulnerability we outlined above — we’ll be offering you this option in the next couple of days. Update [5/6/14] — We're aware of a second issue that's been reported about shared links. This involves a user entering a shared link into a search engine and the search engine passing that link on to ad partners. This is well known and we don't consider it a vulnerability. We urge everyone to be careful about providing shared links to third parties like search engines (read more in this help center article).
We wanted to let you know about a web vulnerability that impacted shared links to files containing hyperlinks. We've taken steps to address this issue and you don't need to take any further action. For background, whenever you click on a link in any browser, the site you're going to learns where you came from by something called a referer header. The referer header was designed to enable websites to better understand traffic sources. This is standard practice implemented across all browsers. Dropbox users can share links to any file or folder in their Dropbox. Files shared via links are only accessible to people who have the link. However, shared links to documents can be inadvertently disclosed to unintended recipients in the following scenario:
- A Dropbox user shares a link to a document that contains a hyperlink to a third-party website.
- The user, or an authorized recipient of the link, clicks on a hyperlink in the document.
- At that point, the referer header discloses the original shared link to the third-party website.
- Someone with access to that header, such as the webmaster of the third-party website, could then access the link to the shared document.
While we're unaware of any abuse of this vulnerability, for your safety we’ve taken the following steps to make sure this vulnerability can't be exploited:
- For previously shared links to such documents, we've disabled access entirely until further notice. We're working to restore links that aren't susceptible to this vulnerability over the next few days.
- In the meantime, as a workaround, you can re-create any shared links that have been turned off.
- For all shared links created going forward, we've patched the vulnerability.
- Additionally, if you’re a Dropbox for Business customer, you have the option to restrict shared link access to people in your Dropbox for Business team. Links created with those access controls were not affected.
We realize that many of your workflows depend on shared links, and we apologize for the inconvenience. We'll continue working hard to make sure your stuff is safe and keep you updated on any new developments. Updated: April 16, 2015
