Drupal Security Team
Drupal.org's security group, whose SA-CORE and SA-CONTRIB advisories and PSAs tell site owners which releases fix a vulnerability.
The Drupal Security Team is the group that decides what happens after someone reports a security hole in Drupal. It is made up of community volunteers. It keeps the report private, works with the maintainer on a fix and announces the result in a security advisory. Its scope is Drupal core and the contributed projects that opted in to coverage.
How the Security Team works
Drupal.org lists these goals for the team: resolving reported issues through a security advisory, helping maintainers of contributed modules fix problems, documenting how to write secure code and secure a site, and helping keep the Drupal.org infrastructure secure.
A report enters through the private issue tracker or by email. The team and the project maintainer then prepare the fix. The problem stays confidential until an advisory is ready, and for critical and highly critical issues the team may publish a public service announcement (PSA) on the Monday before a Wednesday release.
The Drupal.org policy sets the limits. A contributed project must opt in, and then its stable releases are covered. Development snapshots, alpha, beta and release candidate versions are not, and neither are sandbox projects or code hosted elsewhere. Vulnerabilities that need a very powerful permission, such as one defined with restrict access, are outside the policy as well. Advisories appear at /security on Drupal.org, with filters for core, contributed projects and PSAs. The IDs start with SA-CORE, SA-CONTRIB or PSA, and each SA-CORE and SA-CONTRIB advisory carries a risk score out of 25.
Timing for core follows the public release cycle. Security release windows usually fall on the third Wednesday of the month and start at 12:00 New York time. Not every window contains a release. In rare cases a security release comes outside the windows, and a PSA is published first. This was checked on 26 October 2026. The security update term covers what happens on your site afterwards.
Example
SA-CORE-2026-014 was published on 14 October 2026. It covers a remote code execution problem in Drupal core, rated Critical at 19 out of 25. Its Solution section told sites to move to 11.4.10, 11.3.19 or 10.6.19, and offered a stopgap: uninstall the core Field UI module until the update is possible. The advisory credits reporters, fixers and coordinators by name, and several of them are team members.
Common mistakes
- Expecting help with a hacked site. Drupal.org says the team is unlikely to be able to help find the root problem of a defaced site. It still wants to hear about such cases.
- Treating a PSA as background noise. A PSA is the warning that a fix is coming, sometimes outside the usual windows. Use the days before the release to prepare and test the update path.
- Assuming a project is covered because it is on Drupal.org. Check that the project page shows the security advisory coverage notice for its stable release.
For marketing and content teams
You will rarely deal with the team directly, but its schedule affects your calendar. Agree with your technical contact who follows the advisories and who can approve an update on short notice. Ask how fast a critical fix would go live on your site and whether a staging copy is ready to test it. If a visitor or an agency tells you they found a vulnerability, point them to the private reporting route, not to a public post, and keep the details inside the team until an advisory is published. For ongoing updates, the same people should handle both the routine release and the urgent one.
Sources
Questions about Drupal Security Team
Cite this definition
"Drupal Security Team." DXPR Drupal glossary, https://dxpr.com/hc/documentation/learn-drupal/drupal-glossary/drupal-security-team. Last updated October 26, 2026.