Drupal dropped two critical security fixes this week, and its own security team is asking site owners not to wait. The warning was blunt: exploits for flaws like these can appear within hours or days of disclosure. If you run a Drupal website, this is the update you clear your schedule for.
The two vulnerabilities can let attackers run code on your server. Both the core Field UI module and the popular Entity List module are affected. Here is everything we know and exactly how to patch, including what to do if your site sits on an old, unsupported version.
The two Drupal RCE flaws explained
Drupal issued an advance warning at the beginning of the week, then published the details. Both issues carry the worst kind of impact: remote code execution.
- CVE-2026-108097 (SA-CORE-2026-014): A remote code execution vulnerability in Drupal core’s Field UI module. It lets attackers execute arbitrary code on affected servers. Core alone is not enough to exploit it, but contributed modules can open multiple exploitation paths, and at least one of those paths needs no authentication.
- CVE-2026-108099 (SA-CONTRIB-2026-218): A remote code execution flaw in Entity List, a contributed module that creates entity lists without Views. Exploitation here also leans on contributed modules or custom code, and again at least one known path works without a login.
The phrase “at least one path that requires no authentication” is the part that should worry you. It means a scanner hitting your public site could be enough if the right module mix is present. Treat your site as exposed until the patched versions are running.
Every currently supported version of Drupal core is affected. That includes most live sites today, plus Drupal 12 pre-releases before beta2. The final stable Drupal 12.0 release will ship with both flaws fixed.
Which versions are safe
Drupal has published the fixed versions. Update your site to one of these branches:
- Drupal core 10.6.19
- Drupal core 11.3.19
- Drupal core 11.4.10
- Entity List module 3.0.10
Check your version against the support window while you are at it. Drupal says all versions prior to 10.6.x, and all versions of Drupal 11 prior to 11.3.x, are end of life and no longer supported. If your site sits in that range, a patch will not appear for it. You need to plan a version upgrade first.
Drupal runs more than a million websites worldwide, and it is a favourite in government, universities, and non-profits. That mix of high-value targets and shared hosting makes old Drupal installs a regular stop for attackers.
What to do if you cannot update yet
Not every site can take a core update on the same day. Drupal offers a fallback:
- Uninstall the Field UI module. If you disable and remove the core field_ui module, you cut off the attack path for CVE-2026-108097. Most production sites do not need Field UI running all the time anyway.
- Turn on Drupal Steward. The project’s own protection service blocks some known attack vectors for this advisory. Drupal is careful to note it does not cover every possible exploit, so treat it as a stopgap.
- Review your contributed modules. Both flaws lean on other modules or custom code to complete the exploit chain. Anything that touches entity listing or field administration deserves a second look.
These are mitigation measures, not fixes. The patched versions remain the only real solution.
Why Drupal warned everyone in advance
Drupal did something worth noticing. It posted a pre-announcement (PSA-2026-10-12) days before the fixes landed, telling admins to “reserve time for core updates” because “exploits might be developed within hours or days”.
That advice is not theoretical. The recent Magento and Adobe Commerce flaw, known as BlockStrap, was rated CVSS 10.0 and researchers expected attacks almost immediately after disclosure. Content management systems are automated targets. Scanning tooling picks up new advisories within hours, and vulnerable sites get hit before the owners finish reading the news.
Drupal’s pre-announcement also gave teams time to sort out upgrade issues first. The project even suggested updating to the latest bugfix release before October 14, so that ordinary upgrade problems would not block the security update window.
How to protect your Drupal site this week
Run through this checklist in order. It assumes you have shell or hosting panel access to your site.
- Take a backup first. Database and files. Core updates are usually smooth, but a broken update at the wrong time is a bad day.
- Update core. Move to 10.6.19, 11.3.19, or 11.4.10, whichever matches your branch.
- Update Entity List to 3.0.10. Even if you are not sure it is enabled, update it or remove it.
- Check your version support status. Anything below 10.6.x or 11.3.x needs an upgrade plan, not just a patch.
- Test the site after patching. Check node editing, content type screens, and anything using entity lists.
- Watch your logs for a few days. Look for probes hitting field administration paths and unknown POST requests.
- Remove unused modules. Every disabled module is attack surface you do not pay for.
Hosted Drupal platforms often handle core updates for you, but do not assume. Ask your provider which version is running on your site today.
How to check your version and clean up modules
You cannot fix what you cannot see. Three quick checks tell you where your site stands:
- Check the core version. Go to Reports, then Available updates, in the Drupal admin menu. On the command line,
drush statusprints the core version in seconds. - List your contributed modules. Reports, then Available updates shows every module and its version. Look for Entity List anywhere in that list, even if it is disabled.
- Search for field UI usage. If content editors rely on the Manage fields screens, removing field_ui will affect their workflow. Plan the removal window with them, or prioritise the core update instead.
While you are in there, remove any module you do not recognise. Forgotten contrib modules are one of the most common ways attackers chain their way into a CMS.
Why this matters for Indian websites
Drupal powers a large share of Indian university portals, government department sites, and non-profit websites. These sites often run on shared hosting or with small maintenance budgets, which is exactly the profile attackers love. A single unpatched module can expose student data, application forms, and payment pages.
If you manage sites for clients, add this advisory to your weekly maintenance routine. The update takes minutes on a healthy site. Recovering a defaced portal or a database held for ransom takes weeks.
FAQ
Which Drupal versions are affected by these RCE flaws?
All currently supported versions of Drupal core are affected. That includes 10.6.x, 11.3.x, and 11.4.x branches. Drupal 12 pre-releases before beta2 are also affected, while the stable 12.0 release will include the fixes.
Can the Drupal flaws be exploited without a login?
Yes. For both CVE-2026-108097 and CVE-2026-108099, researchers confirmed at least one exploitation path that requires no authentication when certain contributed modules or custom code are present.
What is the fastest fix if I cannot update Drupal core today?
Uninstall the core Field UI module (field_ui) to block the CVE-2026-108097 attack path, and enable Drupal Steward for partial protection. Both are temporary measures until you can install 10.6.19, 11.3.19, or 11.4.10.
Is the Entity List module required for the exploit?
Entity List carries its own flaw (CVE-2026-108099), so it must be updated to 3.0.10 or removed. The core Field UI flaw is a separate issue that can also be reached through other contributed modules or custom code.
Will Drupal 12.0 include fixes for these flaws?
Yes. The final stable Drupal 12.0 release will ship with both vulnerabilities fixed. Only 12 pre-releases before beta2 are affected, and those builds should never run in production.
