Contacted by the security team. Now what?

Last updated on
22 June 2017

If you have been directed to this page from a security issue, please read the page in full. Do not commit anything until the advisory is written and you have coordinated a release date with the team.

When the security team finds a vulnerability in your module or receives a report detailing so, you will be contacted and asked to investigate it.

What you need to do#

  1. Review the report.
  2. Review your module for similar vulnerabilities.
  3. Create a patch and send it to the security team for review. Do not commit anything until the advisory is written and you have coordinated a release date with the team.
  4. Prepare a draft of the security advisory using the previous Security Advisories as guidelines by creating a new advisory node on It will be private while its content is approved by the maintainer and security team.
  5. Coordinate with the security team a time when you can do the commit and create a new release (see below).
  6. Keep the information a secret to yourself, the security team, and module co-maintainers until the security announcement has been released

It is important to keep the issue confidential during this process, and to coordinate each step with the security team.

Whenever you are not sure what to do, contact security team via your issue on for advice.

What happens if I don't respond?#

If you don't fix the issue in a timely manner or progress on the fix seems to stall then the Security Team will publish an advisory urging users to uninstall the affected module and the project will be marked as unsupported (aka abandoned) to facilitate a user of the module taking it over and fixing it. Depending on the module, a security team member may take over the module and release an SA. Timely progress means that the maintainer responds and makes progress on code within 2 weeks of being contacted. Should you not respond at all, the security team may remove your "opt into security coverage role"

What the security team will do#

  • Help you with questions
  • Ensure timely progress
  • Help with the coordinated release

Coordinated release and announcement#

When a vulnerability has been corrected in coordination with the security team, you have to make a new release. This usually means an increase of the minor version, for example from 7.x-1.0 to 7.x-1.1.

See Managing releases for background information on releases. Any release created to address a security problem should be classified as a Security update release using the Release type category when creating (or editing) the release node. See Types of releases for more information. Release nodes tagged "Security update" do not get published automatically. A member of the team will manually publish it for you.

When you commit the code use a commit message that does not call attention to the security issue. Do not discuss the pending release with anyone outside of the security team and the co-maintainers of the module.

We make releases/announcements public on Wednesdays that are not near a major holiday for our user base (e.g. Christmas, right before Gregorian New Years). We prefer if you commit the code and create the release nodes on an agreed Tuesday after 17:00 UTC. You can then update the security advisory adding links to the release nodes and update the issue on We try not to create new releases after Wednesday 17:00 UTC, so please do not commit a fix after that time without prior approval from a security team member.

To make sure the release and announcement are published at the same time, contact your security team contact via the issue queue or via irc. The list of team members includes their irc nicks where available.