Patching Drupal Core RCE Flaws: A 72-Hour Playbook

When Drupal warns that "exploits might be developed within hours or days," it's not just boilerplate language. It's a timeline. In October 2024, Drupal disclosed two critical remote code execution vulnerabilities affecting the Entity List module (CVE-2026-108099) and Field UI module (CVE-2026-108097). Both require contributed modules to become exploitable, but at least one known path doesn't need authentication. If your organization runs Drupal, you need a repeatable process to patch core vulnerabilities before exploit code circulates publicly.

This playbook guides you through the complete patch cycle, from triage to validation, with specific commands and decision points.

The Problem: Attack Surface Expands Faster Than Patch Cycles

Drupal's modular architecture increases risk. Core vulnerabilities become exploitable when combined with contributed modules, which your developers install to extend functionality. You don't control the security of these third-party extensions, and you often don't know which combinations create exploit paths until a security advisory lands.

The Entity List and Field UI flaws illustrate this pattern. Neither is exploitable in isolation, but contributed modules provide "serious exploit paths," according to Drupal's advisory. Your exposure depends on your specific module stack, so you can't wait for proof-of-concept code to determine urgency.

The math is unforgiving: if exploit development takes 48 hours and your patch cycle takes five business days, you're operating in a three-day window where attackers have working code and you don't have fixes deployed.

What You Need Before Starting

Access and permissions:

• Shell access to production Drupal instances (via SSH or container exec)
• Database backup privileges
• Web server restart permissions
• Composer access (if managing dependencies via Composer)

Environment inventory:

• Current Drupal core version on each instance
• Complete list of installed contributed modules
• PHP version (must meet requirements for target Drupal release)
• Database type and version

Communication channels:

• Direct line to application owners who can authorize downtime
• Status page or notification system to alert users
• Rollback authority if patches break functionality

Testing environment:

• Staging instance mirroring production configuration
• Ability to restore production database to staging
• At least two hours of testing time before production deployment

Run drush status or check /admin/reports/status to capture your baseline. Document your current Drupal version, PHP version, and database version. You'll need these to select the correct patch target.

Step-by-Step Implementation

Phase 1: Triage and Scope (15 minutes)

Check Drupal's security advisories page immediately when you receive notification. For the October 2024 advisories, look for version-specific guidance.

Determine if you're affected:

• Entity List vulnerability: Does your site use the Entity List module? Check /admin/modules or run drush pm-list --status=enabled | grep entity_list
• Field UI vulnerability: This is part of Drupal core. If you run Drupal, you're potentially exposed if you have contributed modules installed

Assume you're vulnerable unless you can definitively prove otherwise.

Identify your target versions:

• Drupal 11.4.x → upgrade to 11.4.10
• Drupal 11.3.x → upgrade to 11.3.19
• Drupal 10.6.x → upgrade to 10.6.19
• Older versions → no patches available; you must upgrade to a supported branch

If you're running an end-of-life version, escalate immediately as this is now a migration project.

Phase 2: Backup Everything (20 minutes)

Before touching production, create point-in-time recovery options.

Database backup:

drush sql-dump --gzip --result-file=../backups/pre-patch-$(date +%Y%m%d-%H%M%S).sql

Codebase backup:

tar -czf ../backups/drupal-codebase-$(date +%Y%m%d-%H%M%S).tar.gz .

Configuration export (if using config management):

drush config-export --destination=../backups/config-$(date +%Y%m%d-%H%M%S)

Store backups outside the web root. Verify the files exist and contain data before proceeding.

Phase 3: Staging Deployment (90 minutes)

Deploy to staging first. This isn't optional.

For Composer-managed sites:

composer update drupal/core-recommended drupal/core-composer-scaffold drupal/core-project-message --with-dependencies

For non-Composer sites: Download the appropriate release from drupal.org/project/drupal and replace core files manually. Don't overwrite sites/, modules/, themes/, or custom code.

Update Entity List module:

composer require drupal/entity_list:3.0.10
# or manually download and replace in modules/contrib/entity_list

Run database updates:

drush updatedb -y
drush cache-rebuild

Test critical paths:

• User authentication (login/logout)
• Content creation and editing
• Any custom forms or workflows
• Administrative interfaces that use Field UI

If anything breaks, decide whether to investigate the incompatibility or apply the mitigation (uninstall Field UI module) if your site can function without it. The advisory mentions this option for the Field UI vulnerability.

Phase 4: Production Deployment (60 minutes)

Schedule a maintenance window. Even if you're confident, assume 30 minutes of downtime.

Enable maintenance mode:

drush state-set system.maintenance_mode 1
drush cache-rebuild

Apply the same update sequence you tested in staging:

1. Backup (redundant, but do it again)
2. Update core via Composer or manual file replacement
3. Update Entity List module
4. Run drush updatedb -y
5. Clear all caches: drush cache-rebuild

Disable maintenance mode:

drush state-set system.maintenance_mode 0
drush cache-rebuild

Validation: Verify the Patch Worked

Don't assume success. Confirm it.

Check versions:

drush status | grep "Drupal version"
drush pm-list --status=enabled | grep entity_list

Your output should show the target version numbers: 11.4.10, 11.3.19, or 10.6.19 for core, and 3.0.10 for Entity List.

Review status report: Navigate to /admin/reports/status. You should see no security warnings related to core or Entity List versions.

Test exploit paths (if you have security testing tools): If you have a web application scanner, run it against your staging environment to confirm the RCE vectors are closed. This isn't required but adds confidence.

Monitor logs: Watch your web server error logs and Drupal watchdog logs for the next 24 hours. Look for unusual errors, especially around entity operations or field configuration.

Maintenance: Build a Faster Response Loop

You can't compress this playbook into 90 minutes on the first run, but you can get there with preparation.

Automate the inventory: Create a script that pulls Drupal versions, enabled modules, and PHP versions from all instances. Run it weekly. When an advisory drops, you'll know your exposure in seconds, not hours.

Pre-stage your environments: Keep staging synchronized with production. If your staging database is three months old, your testing is worthless. Refresh it weekly or after major content changes.

Establish a security advisory monitor: Subscribe to Drupal's security announcement mailing list. Configure alerts to page your on-call engineer, not just send email. The difference between a two-hour response and a two-day response is often notification latency.

Document your contributed modules: Maintain a register of every contributed module, why it's installed, and who requested it. When an advisory mentions "contributed modules provide serious exploit paths," you need to know which ones you're running and whether you can disable them as a mitigation.

Rehearse the rollback: Once per quarter, practice restoring from backup. Time it. If your rollback takes four hours, that's your downtime floor when a patch breaks production.

The goal isn't perfection. It's predictability. When Drupal publishes an advisory warning of rapid exploitation, you should be able to execute this playbook from triage to production validation in under four hours. That's the threshold where you stay ahead of public exploit code.