On July 15, 2026, Drupal published several core security advisories. If an organisation's website, portal or service platform runs on Drupal, now is the time to check not only the version number, but the whole update process.

# Drupal core July security updates: what site owners should check now

On July 15, 2026, Drupal published several core security advisories. According to Drupal.org, the issues include cross-site scripting, commonly known as XSS, and information disclosure risks. The relevant fixes point to Drupal 11.4.4, Drupal 11.3.14 and Drupal 10.6.13.

This does not mean every Drupal site is automatically under attack. It does mean that Drupal cannot be treated as a platform to look at "later". For a school, municipality, public-sector body, university, NGO or larger institutional organisation, there should be a clear answer to four questions: who follows Drupal security advisories, who applies updates, where updates are tested and how editorial workflows are checked after the change.

Drupal.org published several moderately critical Drupal core security advisories on July 15, 2026.

SA-CORE-2026-010 describes an information disclosure issue related to the Image module and image style derivatives when private derived images are served through certain non-core file schemes. Drupal.org recommends updating Drupal 11.4 sites to 11.4.4, Drupal 11.3 sites to 11.3.14 and Drupal 10.6 sites to 10.6.13.

SA-CORE-2026-011 concerns the HTMX JavaScript library integrated into Drupal 11.2 and later. The advisory says Drupal core's XSS filter did not sufficiently sanitize certain HTMX attributes. Drupal 10 core is not directly affected according to the advisory, but a Drupal 10.6 hardening fix is included because some contributed modules may be affected.

SA-CORE-2026-012 concerns Layout Builder block labels in certain scenarios. The risk is cross-site scripting and is especially relevant for sites where editors or administrators use the Layout Builder editing interface.

Version support matters as well. Drupal 11.4.0 release notes say that Drupal 11.4.x includes new functionality and should be the target for new site development. Drupal 11.4.x receives security support until June 2027, while Drupal 11.3.x continues to receive security support until December 2026.

A security update can look simple from the outside: update core and move on.

For a larger Drupal platform, the real question is broader:

• is the site running a supported Drupal branch;
• are dependencies managed in a controlled way with Composer;
• are updates tested in a staging environment before production;
• are editor workflows checked after the update;
• do custom modules and the theme work with the new version;
• do logs, cron, permissions, forms, views and search still behave correctly;
• does the organisation know who is responsible for responding to security advisories.

When these answers exist, a security update is a normal maintenance step. When they do not, every advisory becomes a small operational crisis.

The first step is to know the exact state of the site. Not "probably Drupal 10" or "some version of Drupal 11", but the actual core version, contributed module versions, PHP version and hosting environment. The WebPro Drupal scanner gives a quick first picture from public signals, but the exact state is only visible from inside the site.

A practical checklist:

• confirm whether Drupal core is at 11.4.4, 11.3.14 or 10.6.13, depending on the branch in use;
• check whether the site is on a supported Drupal branch;
• identify whether 11.2.x, 10.5.x or older versions are still in production;
• confirm that security updates can be tested in a staging environment;
• check whether the site uses Layout Builder;
• check whether the site uses private files, custom file schemes or special image delivery logic;
• review whether editors have permissions or workflows that affect HTML, blocks or layouts;
• test the public site, the admin interface and the main forms after the update;
• make sure there is a change log.

This checklist is not meant to create panic. It is meant to make the update manageable.

Many Drupal risks are not limited to the public website. They can be connected to how content is entered, which fields editors use, how blocks are managed and how permissions are configured.

With SA-CORE-2026-012, one detail from Drupal.org is important: the issue is connected to the Layout Builder editing interface. A site owner should therefore ask more than "does the public site work?". The better question is: who can edit layouts, and what blocks can they create or change?

In larger organisations, the admin interface often grows over years:

• new roles are added;
• old permissions are not reviewed;
• some users retain broader access than they need;
• content blocks are used in workflows the original architecture did not anticipate;
• custom modules are added without later audit.

That makes a security update a good moment to review roles, permissions and the editorial workspace.

For a public-sector body, educational institution or large organisation, a Drupal site is often more than a communications channel. It may support service delivery: forms, notices, documents, contacts, self-service flows, events, applications or integrations with other systems.

That is why updates need to be controlled.

A healthy update process looks like this:

1. Versions and risks are mapped.
2. The update is applied in a staging environment.
3. Main user journeys are tested.
4. Logs and error messages are reviewed.
5. The production update is scheduled for a suitable time.
6. After deployment, the public site, admin interface and critical functions are checked.
7. The change is documented.

If an organisation already has this rhythm, a security advisory is not a surprise project. If the rhythm is missing, a small technical audit is a sensible place to start.

Drupal 11.4.0 release notes say that 11.4.x should be the target for new site development. At the same time, 11.3.x continues to receive security support until December 2026, and 11.4.x until June 2027.

That matters for planning.

If an organisation expects new development, a major feature, a migration or an admin interface rebuild in the coming months, the work should not be planned on an older branch simply because it feels convenient. It is better to decide early which Drupal version should be the target, which modules support it and whether custom code is ready.

This is especially important for sites with:

• many content types and roles;
• multilingual content;
• document handling or private file logic;
• Layout Builder or another page-building workflow;
• integrations with external systems;
• custom modules;
• accessibility requirements;
• a long-term maintenance and development plan.

If the site has been updated recently, is documented and has a working staging environment, a normal security update with testing may be enough.

An audit is useful when:

• the exact Drupal version or module state is unclear;
• updates have been delayed for months or years;
• the site uses old or weakly maintained modules;
• the admin interface is slow or confusing;
• permissions have grown without review;
• there is no staging environment;
• production changes are made manually;
• previous updates have caused errors;
• the organisation is planning a larger development or migration.

An audit does not have to be a large project. Often the first technical review only needs to answer three questions: what is risky now, what needs to be fixed immediately and what can be planned as part of the next development step.

The July 15, 2026 Drupal core advisories are a useful reminder: Drupal is a strong platform when it is maintained in a controlled way.

A site owner does not need to solve every technical detail personally. But they should know:

• which Drupal version is in use;
• whether that version is supported;
• who follows security advisories;
• where updates are tested;
• how the admin interface and editorial workflows are checked;
• when routine maintenance should become a deeper audit.

WebPro supports Drupal sites through maintenance, security updates, audits and further development. The goal is not only to change a version number. The goal is to keep the platform secure, maintainable and reliable for everyday work.

Kaido Toomingas WebPro Company OÜ

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.