Drupal Field UI Critical RCE (Patched in 11.4.10 / 11.3.19 / 10.6.19): Detection and Remediation Guide

On October 14, 2026, the Drupal Security Team shipped emergency security releases — Drupal 11.4.10, 11.3.19, and 10.6.19 — to address a critical vulnerability in the core Field UI module that can allow an attacker to execute arbitrary code on the web server hosting the site.

The most important detail for defenders: this is not a pure core exploitation story. Per the Drupal Security Team's advisory, the flaw is not reachable through Drupal core alone — exploitation requires a code path through a contributed module. Several such paths exist, and at least one known path requires no authentication at all. That single sentence changes the risk calculus entirely: any Drupal site running a vulnerable core version with the right (wrong) combination of contributed modules is exposed to anonymous, remote code execution from the internet.

Drupal powers a significant share of government, higher-education, healthcare, and enterprise websites globally. If history is any guide — and Drupalgeddon taught us this lesson brutally — mass scanning and automated exploitation of critical Drupal RCEs begins within hours to days of disclosure. If you run Drupal anywhere in your estate, treat this as a patch-now, hunt-later-in-parallel event.

Technical Analysis

Affected Products and Versions

Any Drupal installation on an end-of-life branch (e.g., 10.5.x or earlier, 9.x, 8.x, 7.x) should be assumed vulnerable-by-omission and upgraded to a supported, patched branch immediately.

How the Vulnerability Works (Defender's View)

The vulnerable component is Drupal core's Field UI module (field_ui), which provides the administrative interface for managing fields on entity types — content types, taxonomy terms, users, and custom entities. Field UI dynamically builds and processes administrative forms tied to field storage and display configuration.

Based on the advisory's language, the flaw sits in how Field UI handles attacker-influenced input when a contributed module exposes a route or form element that reaches the vulnerable core code path. The key exploitation characteristics:

• Core alone is not exploitable. The vulnerable code path is only reachable when a contributed module wires attacker-controllable input into Field UI's handling logic. This means your actual exposure depends on your contributed module inventory — a site with a minimal module footprint may be unreachable, while a site with common field-related contrib modules may be wide open.
• At least one known path is unauthenticated. No valid Drupal session, no user account, no credentials. The attacker only needs network reachability to the site's HTTP(S) endpoint.
• Impact is server-side code execution. In the typical Drupal deployment, that means code running as the web server user (www-data, apache, or nginx) — which is more than enough to drop a webshell, pivot to the database (Drupal's settings.php holds DB credentials in plaintext), harvest content, and stage lateral movement.

The practical attack chain a defender should model:

1. Attacker identifies a Drupal site (version fingerprinting via CHANGELOG.txt, response headers, or passive recon).
2. Attacker probes routes exposed by contributed modules that wrap Field UI functionality — including routes reachable anonymously.
3. A crafted request triggers the vulnerable Field UI code path, resulting in arbitrary code execution in the PHP process.
4. Post-exploitation: webshell drop into the webroot (sites/default/files/ is a classic writable target), credential theft from settings.php, and persistence via malicious module upload or cron poisoning.

Exploitation Status

The advisory confirms that multiple exploitation paths through contributed modules are known to the Security Team, with at least one unauthenticated. While the summary does not confirm in-the-wild exploitation at publication time, defenders should assume weaponization is imminent or already underway. Critical, unauthenticated RCE in a top-tier CMS with publicly documented exploitation paths is exactly the class of vulnerability that gets folded into automated exploitation frameworks within days. Do not wait for a CISA KEV listing to act — patch on the assumption of active exploitation.

Detection & Response

Patching is the primary control, but you must assume exposure predates your patch window. Hunt for the artifacts of successful exploitation: PHP code execution under the web server, webshells in writable directories, and anomalous POST traffic to Field UI and contrib-module routes.

Sigma Rules

---
title: Drupal Web Server Process Spawning Shell or Interpreter
id: 3f8a2c71-9b4e-4d21-a6f5-8c1e7d92b4a3
status: experimental
description: Detects PHP-FPM, Apache, or Nginx worker processes spawning shells or scripting interpreters, consistent with post-exploitation following Drupal Field UI RCE. Web server processes should essentially never spawn interactive shells or system command interpreters in production.
references:
  - https://thehackernews.com/2026/10/drupal-patches-critical-core-rce-flaw.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/14
tags:
  - attack.execution
  - attack.t1059
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php-fpm8.1'
      - '/php-fpm8.2'
      - '/php-fpm8.3'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate Drupal modules executing system commands (e.g., backup or media processing modules) - validate against module inventory
level: high
---
title: Webshell File Created in Drupal Writable Directories
id: 7c2e9f14-5a38-4b60-9d21-3f6a8e15c7b2
status: experimental
description: Detects creation of PHP files in Drupal's publicly writable files directories, a hallmark of webshell deployment following CMS code execution. sites/default/files and /tmp should not receive new PHP files during normal operation.
references:
  - https://thehackernews.com/2026/10/drupal-patches-critical-core-rce-flaw.html
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/10/14
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/sites/default/files/'
      - '/sites/default/files/tmp/'
      - '/var/www/html/tmp/'
      - '/tmp/'
      - '/var/tmp/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.php5'
      - '.phar'
      - '.inc'
  condition: selection_path and selection_ext
falsepositives:
  - Drupal Twig compiled templates writing to a files-adjacent cache directory - baseline and exclude known cache paths
  - Legitimate module installation via UI (rare, change-controlled)
level: high
---
title: Suspicious POST Requests to Drupal Field UI Administrative Routes
id: 1d5b8e36-4c72-4f9a-b218-6e3d7a41f905
status: experimental
description: Detects unauthenticated or anomalous HTTP POST requests targeting Drupal Field UI administrative routes. Field UI management routes are admin-only; POST traffic to these paths without an authenticated admin session is a strong exploitation indicator for the October 2026 critical core flaw.
references:
  - https://thehackernews.com/2026/10/drupal-patches-critical-core-rce-flaw.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/10/14
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri-query|contains:
      - '/admin/structure/types/manage/'
      - '/admin/structure/'
      - 'field_ui'
      - '/field_ui/'
      - 'form_id=field_ui'
  selection_method:
    cs-method: 'POST'
  condition: selection_uri and selection_method
falsepositives:
  - Legitimate administrator field management - correlate with authenticated admin sessions and known admin source IPs
level: medium

KQL Hunt (Microsoft Sentinel / Defender)

This query hunts IIS/Apache/Nginx access logs ingested via CEF or custom logs, plus Syslog process events, for probing and post-exploitation against Drupal Field UI routes:

// Hunt 1: Suspicious POSTs to Drupal Field UI routes (web access logs via CEF/Syslog)
let lookback = 14d;
union isfuzzy=true
    (CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where RequestMethod == "POST"
    | where RequestURL has_any ("/admin/structure/", "field_ui", "form_id=field_ui")
    | project TimeGenerated, SourceIP, RequestURL, RequestMethod, DeviceAction, SourceHostName),
    (Syslog
    | where TimeGenerated > ago(lookback)
    | where SyslogMessage has_all ("POST", "field_ui")
        or SyslogMessage has_all ("POST", "/admin/structure/")
    | project TimeGenerated, HostIP, SyslogMessage, Computer);
// Hunt 2: Web server spawning shells (Syslog process auditing / auditd)
Syslog
| where TimeGenerated > ago(lookback)
| where SyslogMessage has_any ("php-fpm", "apache2", "httpd", "nginx")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "python", "perl", "curl ", "wget ", "base64 -d")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc

Tune Hunt 1 against your legitimate admin source IPs — a sudden POST to Field UI routes from a foreign or datacenter ASN is the signal you're looking for.

Velociraptor VQL Hunt

Use this artifact across your Drupal web tier to surface webshell-like files recently written to writable web directories and suspicious child processes of the web server:

-- Hunt: Recent PHP file writes in Drupal writable dirs + suspicious web server children
LET files = SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/var/www/*/sites/default/files/**/*.php',
                 '/var/www/*/sites/default/files/**/*.phtml',
                 '/srv/www/*/sites/default/files/**/*.php',
                 '/var/www/html/tmp/*.php',
                 '/tmp/*.php', '/var/tmp/*.php'])
WHERE Mtime > now() - 1209600

LET procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username
FROM pslist()
WHERE Username =~ 'www-data|apache|nginx'
  AND (Name =~ 'sh|bash|dash|python|perl|nc|ncat|curl|wget'
       OR CommandLine =~ 'base64 -d|/dev/tcp/|chmod \+x')

SELECT * FROM files
UNION ALL
SELECT FullPath=NULL, Size=NULL, Mtime=NULL, Ctime=NULL FROM procs

For cleaner output, run the two LET bodies as separate artifacts in production; the union above is illustrative for a combined triage sweep.

Verification and Remediation Script

Run this on each Drupal host to inventory core version, list contributed modules that may expose Field UI paths, and sweep for recently dropped PHP files in writable directories:

#!/bin/bash
# Drupal Field UI RCE - exposure verification and webshell sweep
# Run as root or a user with read access to the Drupal docroot

DOCROOT="${1:-/var/www/html}"
echo "=== Drupal Field UI RCE Triage - $(hostname) - $(date) ==="

# 1) Report installed Drupal core version
echo "--- Core version ---"
if command -v drush >/dev/null 2>&1; then
  drush status --field=drupal-version --root="$DOCROOT" 2>/dev/null
else
  grep -r "const VERSION" "$DOCROOT/core/lib/Drupal.php" 2>/dev/null || \
  grep -rn "'version'" "$DOCROOT/core/lib/Drupal.php" 2>/dev/null
fi

# 2) Flag end-of-life / unpatched branches
echo "--- Patch check: fixed versions are 11.4.10 / 11.3.19 / 10.6.19 ---"

# 3) List enabled contributed modules (exposure surface for Field UI paths)
echo "--- Enabled contributed modules ---"
drush pm:list --type=module --status=enabled --no-core --format=csv --root="$DOCROOT" 2>/dev/null | tee /tmp/drupal_enabled_contrib_$(hostname).csv

# 4) Webshell sweep: PHP files created/modified in writable dirs in the last 14 days
echo "--- Recent PHP files in writable directories ---"
find "$DOCROOT/sites/default/files" /tmp /var/tmp -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -mtime -14 -ls 2>/dev/null

# 5) Hunt for common webshell signatures in the docroot
echo "--- Webshell signature sweep (eval/base64/shell_exec in files dir) ---"
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13)|shell_exec\s*\(\s*\$_|passthru\s*\(\s*\$_" "$DOCROOT/sites/default/files" 2>/dev/null

# 6) Check PHP-FPM / Apache for shell child processes right now
echo "--- Suspicious web server child processes ---"
ps auxf | grep -E "(php-fpm|apache2|httpd|nginx)" -A2 | grep -E "(sh|bash|python|perl|nc |curl|wget)" | grep -v grep

echo "=== Triage complete. If ANY hits in sections 4-6: isolate host, preserve evidence, initiate IR. ==="

Remediation

1. Patch immediately — this is the only complete fix.

Upgrade to Drupal 11.4.10, 11.3.19, or 10.6.19 depending on your branch, via Composer:

# Pin and update Drupal core to the patched release (adjust version to your branch)
composer require 'drupal/core-recommended:^11.4.10' 'drupal/core-composer-scaffold:^11.4.10' --update-with-dependencies
composer update drupal/core-* --with-dependencies

# Run database updates and clear caches
drush updatedb -y && drush cache:rebuild

# Confirm the running version
drush status --field=drupal-version

2. If you cannot patch within hours, reduce the attack surface:

• Disable the Field UI module if your operationally can (drush pm:uninstall field_ui). Most production sites manage fields through configuration deployment, not the live UI — uninstalling field_ui in production is a legitimate hardening step even after patching.
• Restrict access to administrative routes at the edge. Block anonymous access to /admin/* paths via WAF rules, nginx location blocks, or .htaccess — allowlisting only corporate/VPN source ranges.
• Audit your contributed module inventory (drush pm:list --no-core --status=enabled) and disable or uninstall any contrib module that is not strictly required, with priority on modules that extend field management, entity forms, or expose custom routes — these are the documented exploitation paths.

3. Hunt before and after patching. Patching closes the door; it does not evict an attacker already inside. Run the webshell sweep above on every Drupal host, review access logs for POSTs to Field UI/contrib routes over the past 30 days, and check settings.php modification times and the user/admin account tables for unauthorized changes.

4. Assume credential exposure on any confirmed-compromised host. Drupal stores database credentials in plaintext in settings.php; a code-execution compromise means those credentials, plus any API keys in configuration, must be rotated. Rebuild from known-good artifacts rather than cleaning in place where feasible.

5. Longer-term hardening:

• Run production Drupal with field_ui and other development-oriented modules (views_ui where possible, update, devel) uninstalled or access-restricted.
• Enforce read-only webroot permissions except for the files directory, and disable PHP execution in sites/default/files via web server configuration.
• Subscribe to the Drupal Security Team's advisories (drupal.org/security) and route SA-CORE announcements into your emergency patch SLA — critical core RCEs warrant a 24-72 hour patch window, not a change-cycle queue.
• Validate your WAF/edge logging actually captures POST bodies or at least full request URIs for Drupal paths; you cannot retroactively hunt what you never logged.

Final Assessment

This is the vulnerability class defenders dread most: critical severity, unauthenticated code execution, in the world's most-attacked CMS ecosystem, with confirmed exploitation paths through common contributed modules. The core-only caveat will tempt some teams to deprioritize — do not. Unless you can positively verify that no enabled contributed module exposes the vulnerable Field UI path (an audit most teams cannot complete quickly), you must assume reachability. Patch to 11.4.10 / 11.3.19 / 10.6.19 now, hunt for webshells and web-server-spawned shells across the exposure window, and uninstall field_ui from production as a permanent hardening measure.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub