Ten Drupal Contrib Advisories Split Between Fixes and Unsupported Projects

Site owners received ten contributed-project security advisories from the Drupal Security Team on 22 July 2026. Five projects received fixed releases, while five were marked unsupported because known security issues had not been fixed. Six advisories are rated Critical and four are rated Moderately Critical. None concerns Drupal core.

The advisories require different responses despite appearing in the same release window. Supported projects need upgrades, unsupported projects must be removed or replaced, and a separate public service announcement removes security advisory coverage from QA Accounts. The batch is therefore not simply a list of patches. It also identifies projects for which Drupal’s coordinated-disclosure programme cannot provide a maintained remediation path.

A Drupal Association post published the same day, How Drupal Has Protected Millions of Sites, explains the process behind that release window. Reports enter a private queue, where a Security Team member determines whether each report describes a valid vulnerability within the programme’s scope. The reporter and affected project’s maintainer then work in a confidential issue to prepare and review a fix. The advisory and corrected release are normally published together on a Wednesday after that work is complete.

The five fixed advisories show that process reaching its intended outcome: disclosure accompanied by a supported release. The five unsupported notices show a different possible result. The Security Team can validate an issue and warn site owners, but it cannot guarantee that every contributed project will retain maintainers able to produce a fix. In those cases, the advisory becomes an instruction to stop using the affected project rather than an instruction to install a newer version.

All ten advisories carry the exploit rating E:Theoretical, which records that no public exploit code or documentation was known when they were issued. That classification does not establish that exploitation is impossible. Installed versions, enabled functionality, permissions, server configuration, and the availability of a supported release still determine the response required for an individual site. A theoretical exploit affecting an unsupported dependency can demand more work than a better-documented flaw with a straightforward upgrade path.

Drupal’s 25-point risk system evaluates six factors: access complexity, required privilege, confidentiality impact, integrity impact, exploit availability, and target distribution. The Drupal Association post says the system was developed from the National Institute of Standards and Technology’s Common Misuse Scoring System, although Drupal is considering a move to the more widely adopted Common Vulnerability Scoring System. Each advisory also carries a CVE identifier assigned within Drupal’s role as a CVE Numbering Authority. These mechanisms standardise disclosure, but they do not describe every site’s configuration or maintenance position.

Five Critical advisories mark Development Environment, Lunr exposed filters, Email Login OTP, Commerce Elavon, and PanKM unsupported. Each has a score of 16 out of 25 and the vector AC:Complex/A:Admin/CI:All/II:All/E:Theoretical/TD:All. All versions are affected, and every advisory recommends uninstalling the project.

The matching scores do not establish that the five projects contain the same vulnerability. The advisories do not disclose the underlying technical mechanisms, so their risks cannot be compared by assuming a common defect. Their shared significance is operational: the Security Team has confirmed a known security issue, but no covered release is available to resolve it. The absence of a public technical description also does not provide a basis for treating an installation as safe.

The Drupal Association’s explanation of project coverage helps clarify this outcome. Security advisories cover Drupal core and eligible contributed projects hosted on Drupal.org that opt into coverage, generally for stable releases. Coverage provides access to a coordinated process when an in-scope vulnerability is reported, but it does not guarantee that a project will remain maintained indefinitely. The Security Team can mark a project unsupported when the maintenance conditions needed for covered remediation no longer exist.

Removing an unsupported module may be more demanding than applying an update. A site team must determine whether the project stores data, provides authentication, processes payments, changes deployment behaviour, or supplies functionality used by custom code. Replacement may require data migration, configuration changes, regression testing, and review of integrations built around the abandoned project. The uninstall instruction is therefore the beginning of the remediation process rather than evidence that the issue is operationally simple.

You May Like

Interview

Kristen Pol Explains How Drupal’s Context Control Center Governs AI Context

Interview

Kristen Pol Explains How Drupal’s Context Control Center Governs AI Context

Three fixed vulnerabilities concern access-control boundaries. PhotoSwipe did not sufficiently check image-access permissions when its gallery display formatter rendered an image. The issue applies where the displayed images are intended to remain restricted. Sites using the Drupal 8-compatible branch should upgrade to 3.0.4, while those using the Drupal 9 or Drupal 10 branches should install 3.2.0 or later.

Webform REST did not sufficiently enforce the parent webform’s create, view, and update permissions through its REST resources. Exploitation requires the attacker to already have permission to use the REST resource, and the advisory affects unsupported releases through 4.0.3. Sites using that branch should upgrade to 4.1.0. Version 4.2.0 already contains the fix.

Internationalization Single Sign-On did not sufficiently validate a short-lived token used to authenticate users across language domains. An attacker could potentially authenticate as another user but would need to appear to originate from the victim’s client IP address. Sites should upgrade to 8.x-1.8. The client-IP requirement limits the conditions for exploitation but does not remove the need to update.

The affected features differ, but all three create additional routes to protected Drupal data or identity. PhotoSwipe passes images through a display formatter, Webform REST exposes submission operations through endpoints, and Internationalization Single Sign-On transfers authentication between domains. Each route must preserve the permissions or trust assumptions enforced by the underlying system. Reviewing the original content entity or login form alone would not reveal the full access surface.

The other two fixed advisories concern cross-site scripting. Search API Autocomplete included a test script that anonymous users could access and that did not sufficiently validate input. Exploitation requires the web server to display warning messages to users. Sites should upgrade to 8.x-1.12, while disabling public PHP error display is an additional mitigation for sites that cannot update immediately.

Media Folders did not sufficiently sanitise media and folder names and descriptions before displaying them in the media browser. A user with permission to create or edit those records could introduce stored cross-site scripting. Version 1.0.8 contains the fix. The required permissions reduce the population of potential attackers but can still include editorial users who should not be able to execute code in another user’s browser.

These vulnerabilities show why severity labels cannot replace site-specific review. A formatter becomes relevant only when it displays restricted images, a test script becomes exploitable when diagnostic messages are public, and a stored cross-site scripting flaw depends on who can edit the affected records. REST permissions and cross-domain authentication introduce further conditions that differ from ordinary page access. Prioritisation must therefore combine the advisory score with the site’s enabled features, roles, configuration, and network environment.

The QA Accounts announcement illustrates another boundary of coverage. The module allows users to log in with well-known username and password combinations and is intended only for development or staging systems that are not publicly accessible. Its maintainers have chosen to remove security advisory coverage, and the Security Team directs sites to ensure that the module is not enabled on any publicly available installation. Unlike the advance warnings sometimes issued before Highly Critical releases, this public service announcement communicates a change in project coverage and operating expectations.

Removing coverage does not itself create the module’s known credentials or disclose a new vulnerability. It changes the assurance available to sites that continue using the project. Future security problems will not necessarily receive the confidential handling, coordinated correction, or advisory publication expected from a covered project. Network isolation and environment separation therefore become the principal controls for any development system that retains it.

The Drupal Association post also states that the Security Team is primarily reactive. It responds to submitted reports rather than continuously auditing Drupal core and tens of thousands of contributed projects, and its members contribute limited volunteer time. That model explains why the shield shown on a covered project should not be read as a continuous security certification. It identifies participation in a disclosure programme, not proof that the code is vulnerability-free or guaranteed to remain supported.

For site operators, the immediate actions remain specific. Supported affected modules need upgrades, the five unsupported projects need removal or replacement, and QA Accounts must remain outside publicly reachable environments. Teams should also confirm that their dependency inventories distinguish covered stable releases from obsolete branches, unsupported projects, development-only modules, and external libraries that Drupal’s programme may not cover. These distinctions determine whether the next security notice results in a routine update or an unplanned replacement project.

The unsupported notices do not show that coordinated disclosure has failed. They perform one of its warning functions by identifying where a supported remediation path has ended. The July release window demonstrates that effective Drupal security maintenance requires more than monitoring core updates or sorting advisories by severity. It also requires ownership of contributed dependencies, tested removal plans, permission review, environment separation, and attention to changes in project support status.