Drupal Association members fund grants that make connections all over the world.
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 security.drupal.org (preferred)
- Find the project on drupal.org related to the issue. Either Drupal core or look for modules or themes.
- In the right sidebar of the project page is a link to "Report a security vulnerability" - click that link
- That 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 firstname.lastname@example.org.
Do not post in the public issue tracker or discuss it in IRC. The security team will investigate your report and work with you and the project maintainer to create a fix. When the issue is about a contributed module, the team coordinates with a module maintainer. When 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 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 for 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 drupal.org 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 Drupal.org profile. 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 choose to first report it to security.drupal.org following the process described above so that the security team and module maintainers can be aware of it in private. It is considered good form, especially for modules used on drupal.org, to report security issues on security.drupal.org first.
What if the vulnerability affects a project that is not hosted on Drupal.org?
Contact the project author directly. You may also email email@example.com to advise the Security Team of the issue, but the Drupal Security Team does not handle security advisories for projects hosted elsewhere.