Last updated 17 January 2018. Created on 5 December 2006.
Edited by kala4ek, shijiezhao, amoebanath, smjamil07. Log in to edit this page.

If you discover a vulnerability in Drupal core or contributed project (module, theme, or distribution) that is covered by the Security Advisory policy, keep it confidential.
There are two ways to report:

1. Report directly on (preferred)

  1. Find the project on related to the issue. Either in Drupal core or a module or theme.
  2. In the right sidebar of the project page, there is a link to "Report a security vulnerability" - click on that link.
  3. That link will take you to the Security Team's private issue tracker where your issue will be immediately incorporated into our workflow

2: Send an e-mail
Send an e-mail to

Do not post it in the public issue tracker or discuss it in IRC. The security team will investigate your report and then work with you and the project maintainer to create a fix. If the issue is about a contributed module, the team will coordinate with a module maintainer. If the fix is ready, we will create a release and announce the fix to a wide audience.

Some bugs take time to correct and the process may involve a review of the codebase for similar problems. Coordinating across time zones and work schedules can be time-consuming. We aim to fix issues within 1 months, but we also need to balance that with the available time of our volunteer team and the need to release high quality fixes.

Do not disclose the vulnerability to anyone else before the advisory is issued. If progress on fixing the issue stalls and it cannot be fixed in a mutually agreeable time, we will unpublish the releases and create a Security Advisory detailing the problem.

If the vulnerability is not covered by the Security advisory policy, you can still report it via these channels, but it's also acceptable to post it directly to the project issue queue of that project.

A good security bug report #

Provide a detailed report. Include as many of these items as possible:

  • Drupal version and/or module version affected by the issue.
  • Steps to reproduce the problem starting from a fresh site install.
  • A proposed patch.

Optional: you can indicate the way you would like to be referred to in the advisory about the vulnerability. Our preference is to use full names linked to user ids. If you do not specify we will do our best to find that information. You can also request a pseudonym or having your name withheld.

My site was defaced and I don't know how

Please review and add the information requested from My site was defaced ("hacked"). Now what?. The Drupal Security Team is unlikely to be able to assist in finding the root problem or helping to restore your site, but is always interested in these reports.


If you follow this process to report a previously unknown vulnerability to the Drupal security team, you will be credited in the security announcement with your name and a link to your profile. Note: Individuals who choose to disclose it publicly before the team and module maintainer can coordinate on a release will not be credited in the release.

What if the vulnerability affects a project that is not covered by the Security Advisory policy?

If you are absolutely sure that the project is not covered by the policy, you can report the issue in the public issue queue of the module. You may also choose to first report it to following the process described above so that the security team and module maintainers can be aware of it in private. It is a considered good form, especially for modules used on, to report security issues on first.

What if the vulnerability affects a project that is not hosted on

Contact the project author directly. You may also email to advise the Security Team of the issue, but the Drupal Security Team does not handle security advisories for projects hosted elsewhere.

Looking for support? Visit the forums, or join #drupal-support in IRC.