A Drupal Security Advisory is a public notice that identifies a vulnerability in Drupal core or a covered contributed project and explains how to fix it. It matters because the notice helps site owners determine exposure, urgency, and the required release. The Drupal Security Team usually directs administrators to install a corrected version, according to its security advisory process and permissions policy. Acting on that guidance can prevent a disclosed flaw from remaining open after technical details become public.
Table of Contents
- What an advisory tells you
- How coordinated disclosure works
- How to judge the security risk
- What Drupal advisories do not cover
- Turning an advisory into an update plan
What an advisory tells you
An advisory lists the affected versions, vulnerability type, security risk, and releases containing the fix. It often includes a CVE identifier, which provides a common reference for tracking the vulnerability. Start by comparing the affected-version range with the exact version installed on your site.
Then identify the fixed release that matches your supported drupal core or contributed-project branch. Do not treat the advisory title alone as an exposure test. A serious flaw may not affect your installed version, while a less dramatic notice still requires action if your version falls within its affected range.
How coordinated disclosure works
Drupal uses coordinated disclosure. The security Team keeps a valid report private while maintainers prepare, review, and test a correction, then publishes the fixed release and advisory together, as described in Drupal.org's general Security Team information. This process gives administrators a practical remedy when the vulnerability becomes public. It does not provide unlimited preparation time because most technical details remain private until the release.
Contributed-project advisories normally appear on Wednesdays. Core advisories usually appear on one Wednesday each month, although Drupal may publish outside that schedule for unusually severe or actively exploited vulnerabilities. For critical or highly critical issues likely to lead quickly to automated attacks, Drupal may publish a public-service announcement beforehand. That warning lets site owners reserve maintenance time without revealing the vulnerability details early.
How to judge the security risk
Drupal scores advisory risk from 0 to 25. Its security risk model considers access complexity, authentication, confidentiality impact, integrity impact, known exploitation, and the distribution of likely targets.
Scores from 20 through 25 are labeled "Highly Critical." The score summarizes several dimensions, so administrators should also read whether anonymous access is possible and what an attacker could accomplish. SA-CORE-2026-004 shows why those details matter. Drupal's core advisory index describes a highly critical PostgreSQL SQL-injection flaw that anonymous users could exploit, with possible data disclosure, privilege escalation, or remote code execution.
What Drupal advisories do not cover
Coverage applies to supported stable releases of covered projects hosted on Drupal.org. It excludes development snapshots, alpha and beta versions, release candidates, sandbox projects, and projects hosted elsewhere. A missing advisory therefore does not prove that every component on a Drupal site is secure.
Custom modules, unsupported releases, and externally maintained code fall outside the normal advisory process. Drupal also generally does not issue an advisory for a separately installed external library or plugin. Site owners must identify those dependencies and monitor their maintainers' security channels separately.
Turning an advisory into an update plan
Use the advisory as a release decision document rather than a general warning. A compact response workflow is: If the site runs an unsupported or excluded release, the advisory may not provide a compatible fix. The concrete next action is to move to a supported stable release or obtain security guidance from that component's maintainer.
- Record the installed core, module, or theme version.
- Compare it with the advisory's affected-version range.
- Confirm the correct fixed release for the supported branch.
- Review authentication requirements and potential impact.
- Test the update through the site's normal deployment process.
