What to Do Before Drupal’s Critical RCE Patch Drops: A Practical Checklist

What Drupal maintainers need to assume right now

Drupal has pushed out a highly critical patch, and the safest assumption is that exploitation will follow quickly once details are public. I would treat this as a remote code execution class event until the advisory proves otherwise.

That changes the order of operations. You do not start with “patch when convenient.” You start with inventory, containment, and a fast rollout plan. If you wait for release day and then begin figuring out where Drupal is installed, you are already late.

Why this kind of critical patch changes your threat model

The key detail is timing, not just severity. When a CMS vendor signals a critical issue and hints at quick exploitation, you should assume attackers are doing the same prep work you are: fingerprinting versions, watching release notes, and waiting for proof-of-concept code.

That means:

• exposed admin endpoints are higher risk than usual
• stale staging sites turn into real targets
• unmanaged installs are easy to miss during emergency patching
• old backups may be the only clean recovery path if the first response fails

Build a fast inventory before the patch lands

Map every public Drupal instance

Start with the sites you already know about, then work outward from DNS, load balancers, and shared hosting accounts. I usually ask for three lists at once: known production sites, known non-production sites, and anything someone thinks is “probably dead.”

A simple inventory table is enough:

Separate production, staging, and unmanaged installs

This matters because the patch plan is different for each one. Production needs a controlled rollout. Staging can be used to validate the patch. Unmanaged installs are where emergency response usually breaks, because nobody knows who has SSH access or whether the code is current.

Record current version, modules, and deploy method

Before the patch drops, capture:

• Drupal core version
• contributed modules with a history of security impact
• theme overrides
• whether updates happen through Composer, Drush, or manual file replacement
• whether the site is containerized or running on a shared VM

If you wait until release day, you will spend your patch window answering basic questions instead of reducing risk.

Check the parts that usually get missed

Composer-based installs versus manual updates

Composer-managed sites are easier to update cleanly, but only if the lockfile and deployment pipeline are healthy. Manual installs are often faster in the short term and worse in every other way, because they leave room for partial updates and forgotten files.

You want to know which of these is true before the patch lands.

Custom modules, themes, and patched vendor code

The vulnerability may live in core, but the outage often comes from custom code that assumes old behavior. Watch for:

• custom upload handlers
• direct calls into internal APIs
• brittle bootstrap or cache logic
• vendor patches that were never merged upstream

Backups, restore time, and maintenance windows

A backup only helps if you can restore it quickly. Test one now, not after the patch. I care less about “we have backups” than about “we restored a full site in under an hour last month.”

What to do during the patch window

Apply the core update first

Patch core before you spend time on cleanup tasks. The goal is to remove the exposed code path as soon as possible. If you use Composer, keep the change minimal and review the resulting lockfile. If you update manually, verify that every changed file matches the release package.

Verify file integrity and cache state

After rollout, check:

• core file hashes if your process supports them
• web server and PHP error logs
• Drupal cache rebuild status
• whether opcode caches or reverse proxies are still serving old code

A patch that is deployed but not actually active is a common failure mode.

Watch logs for exploit attempts and failed requests

During the patch window, scan for spikes in:

• unusual POST requests
• requests to admin or form endpoints
• malformed path traversal attempts
• repeated 4xx and 5xx responses from the same sources

You are looking for proof of scanning and failed exploitation, not just successful compromise. That evidence helps you decide whether to expand incident response.

Practical containment if patching is delayed

Reduce exposure at the edge

If you cannot patch immediately, reduce the blast radius:

• restrict public access where possible
• add IP allowlists for admin paths
• put the site behind a WAF rule set tuned for CMS abuse
• disable unused virtual hosts and forgotten subdomains

Limit admin access paths

Admin exposure is often the easiest route for attackers once a flaw is known. If your workflow allows it, require VPN access or a jump host for /user/login, /admin, and related endpoints.

Disable risky integration points only if you can test the impact

Do not blindly switch off modules in production without a rollback plan. That can create a second incident. If you need to disable a risky integration, test the site flow first and document the user impact.

A minimal incident-response checklist for Drupal teams

1. Identify every Drupal instance you own.
2. Confirm version, ownership, and update method.
3. Test backup restore on one representative site.
4. Prepare the core patch in staging.
5. Patch production as soon as the release is available.
6. Verify file integrity, caches, and logs.
7. Review signs of scanning or failed exploitation.
8. Rotate credentials if you see suspicious activity.
9. Document any site that could not be patched and why.
10. Schedule a follow-up review of custom modules and deployment hygiene.

Conclusion

The right response to a critical Drupal patch is not panic; it is speed with structure. If you know where every instance lives, how it is updated, and how quickly it can be restored, you can move before exploitation does. If you do not, the patch release becomes the start of your incident.