Home

Security Issue Reporting

Security issue reporting guidelines

Looking for help with your Fastmail account, like a login issue? Please contact our support team. Received an email that you’re not sure is from us? Learn how to recognise and report phishing in our help, or contact our support team if you’re still not sure. This page is only about reporting security vulnerabilities and bugs in Fastmail’s code and infrastructure.

If you’ve found a security vulnerability in Fastmail, please report it to us straight away by emailing security@fastmailteam.com. Please follow the format described in How to write your report below. We encourage responsible disclosure (as described below), and we promise to investigate all legitimate reports in a timely manner and fix any issues as soon as we can.

How to write your report

Every report is read by our senior staff. To help us understand yours quickly, your report must follow the format below. If it doesn’t, we’ll close it with a note saying what was missing, and you’re welcome to send a corrected report.

One problem per report: each report must describe exactly one problem. If you’ve found four problems, send four emails.

Subject: name the problem in a few words, such as “Script in contact name runs when contact is opened”. Don’t use subjects like “Critical vulnerability found in Fastmail”.

Body: describe the problem in four short bullet points:

  • If a user (or attacker) is in some situation: If an attacker shares an address book containing a contact whose name includes an HTML <img> tag
  • and they do something: and the victim opens Contacts and clicks that contact
  • then something should happen: then the name should be shown as plain text
  • but instead something else happens: but instead the attacker’s script runs on app.fastmail.com

Your bullets must name the specific parts of Fastmail involved. In the web or mobile app, that means the screens, menu items and settings you used, such as Settings → Privacy & Security. For other access, give the protocol and the command or method, such as a JMAP Email/set call or an IMAP APPEND. A report that could describe any email provider, or code that you haven’t shown Fastmail actually runs, is not enough.

Don’t put anything else in the body. In particular, don’t include a severity rating or CVSS score. We assess severity ourselves.

Attachments: you may attach a proof of concept, request and response captures, screenshots, source analysis or a longer write-up. Attach them as files, not in the body of your email. We’ll read them once your four bullets have told us what to look for.

We do read all reports within 24 hours, but as all reports are reviewed and personally investigated by our senior staff, it may take up to 10 business days before you hear back from us.

Responsible disclosure policy

We ask that during your research you make every effort to maintain the integrity of our users’ data, avoiding violating privacy or degrading our service. You must give us reasonable time to fix any vulnerability you find before you make it public. In return we promise to investigate reports promptly and not to take any legal action against you.

Bug bounty

As a measure of our appreciation for security researchers, we are happy to give full credit in any public postmortem after the bug has been fixed, and we offer a monetary bounty for certain qualifying bugs. To qualify for the bounty, you must:

  • Follow our responsible disclosure policy (see above).
  • Report the bug to us first, and give us reasonable time to fix the issue before making it public.
  • Be the first person to report the issue to us.
  • Send a report in the format described in How to write your report (see above).
  • Use a test account (a free trial account is fine), or an account that you control. Never interact with other accounts without the owner’s consent. The security team cannot help you acquire or activate a trial account, so don’t ask.
  • Find a bug that could allow access to private user data, or enable access to a system running Fastmail infrastructure.

Examples of valid vulnerability types include:

  • Authentication or session management issues
  • Cross-Site Scripting (XSS) (only on *.fastmail.com — e.g. app.fastmail.com — not on user.fm or fastmailusercontent.com; see below)
  • Cross-Site Request Forgery (CSRF/XSRF)
  • Remote Code Execution
  • Privilege Escalation

The decision of whether a bug qualifies for a bounty is solely at the discretion of Fastmail. Any qualifying bug will be eligible for a bounty of a minimum of US$100 and a maximum of $5,000. The exact value will be determined by Fastmail after taking into account the severity of the vulnerability, the number of users potentially affected etc. We normally process bug bounty payments once a month, and any taxes or fees are the sole liability of the recipient.

Specific exclusions

People seem to report these regularly, so we’re putting them up front to make it clear we do not regard these as bugs

  1. Email spoofing bugs do not qualify. We are quite aware that users can set arbitrary From addresses on emails, that our SPF records allow arbitrary hosts to send email as our domains, and that our DMARC policy is not enforcing passes. These policy decisions are by design, and we track the actual sender in a separate header.
  2. CSV Excel Macro Injection bugs via address book exporting do not qualify. The user has complete control over their address book. We regard convincing someone to add a particular address to their address book, export and download it as a CSV, open it in Excel, click through a warning dialog as exceedingly unlikely user interaction. If you can get them to do that, just get them to run cmd from the Start menu and paste some arbitrary command.

General Exclusions

  1. Denial of Service (DOS) and social engineering attacks do not qualify and must not be attempted against Fastmail or our users under any circumstances.
  2. Bugs that require exceedingly unlikely user interaction or are caused by insecurities in browser extensions do not qualify.
  3. Brute force log in attempts.
  4. The domains user.fm and fastmailusercontent.com are used to host potentially unsafe user content. By keeping this content in completely separate domains, we avoid any security issues with our corefastmail.comdomain. As such, any Cross-Site Scripting (XSS) attacks on these sites are not of interest to us. Please note that if you go to a user web site such as testuser.fastmail.com it immediately redirects to testuser.fastmail.com.user.fm and is thus in theuser.fmsecurity domain, not the fastmail.com domain.
  5. Bugs on sites associated with Fastmail but not run by Fastmail do not qualify. This includes www.fastmailfbl.com. We are grateful for any reports on issues with these sites, and we will pass on the bugs to the relevant company, however they do not qualify for a bounty.
  6. Anything related to enumeration of usernames does not qualify.
  7. Bugs related to unpatched, out of date or exceedingly rarely used browsers or other client software out of our control.
  8. We are public about the software we run. We are not interested in reports about “leakage” of the fact we run nginx, or the version number, or Perl module names or file paths.

Hall of fame

We’re grateful to the security researchers who have reported issues to us. They’re listed in our bug bounty hall of fame.