Drupal Core RCE in Entity List and Field UI Modules: Detection and Remediation Guide for Rapid Exploitation Risk

Drupal's security team has issued a warning that a critical remote code execution flaw in Drupal core — impacting the Entity List and Field UI modules — is likely to be weaponized quickly, with viable attack paths also existing through contributed modules. If you operate Drupal sites, especially anything internet-facing with authenticated administrative or content-management workflows exposed, this is a patch-now event, not a patch-this-quarter event.

History is unambiguous here. Every time a critical RCE lands in Drupal core, automated mass exploitation follows within hours of advisory publication. Scanners operated by botnet herders and initial-access brokers poll Drupal security releases continuously, diff patched code, and weaponize before most organizations have even queued the change request. The explicit warning from the Drupal security team about fast exploitation risk should be read as: the exploit path is understandable from the patch diff, and the window between disclosure and in-the-wild abuse is measured in hours to days.

This post breaks down what we know, how the flaw is exploitable from a defender's perspective, and — most importantly — what you should be hunting for in your environment right now.

Technical Analysis

Affected Components

Based on the advisory reporting:

• Drupal core — Entity List module: a core subsystem responsible for rendering and handling entity listings. Flaws here are dangerous because entity handling touches nearly every administrative and content workflow in a Drupal site.
• Drupal core — Field UI module: the administrative interface used to manage fields on content types, taxonomy, users, and other entities. Field UI processes complex, structured user input and has historically been a rich source of input-validation and object-handling bugs.
• Contributed modules: the advisory notes that attack paths exist through contrib modules. This matters — even sites with a patched core may have exposure via contributed code that interacts with the vulnerable core APIs. Your remediation scope must include contrib, not just core.

How the Vulnerability Works (Defender's View)

While full technical detail is constrained until sites are patched (standard Drupal security team practice), RCEs in Drupal administrative UI modules typically follow a recognizable pattern:

1. Attacker submits crafted input to a route handled by the vulnerable module — often via the administrative interface or an entity/field configuration endpoint. Depending on the required permissions, exploitation may be unauthenticated or require a low-privilege authenticated session (which is trivially obtained on sites with open registration, or via credential stuffing).
2. Insufficient validation or unsafe object handling in the module's form/render pipeline allows attacker-controlled data to reach a code execution sink — in Drupal's PHP ecosystem this commonly means unsafe deserialization, render array injection (#lazy_builder, #pre_render callable abuse), or template injection reaching eval-equivalent behavior.
3. Code executes in the context of the web server process (php-fpm, Apache mod_php, or the container's PHP runtime), giving the attacker the ability to drop a webshell, read settings.php (database credentials), pivot to the database, and establish persistence in the web root.

The post-exploitation pattern we consistently observe in Drupal RCE incidents: a PHP webshell written into sites/default/files/ (which is web-accessible and often misconfigured to execute PHP), a callback for second-stage payloads, and credential theft from settings.php followed by database dumping.

Exploitation Status

• The Drupal security team has explicitly warned of rapid exploitation risk, which they only do when they assess the flaw as straightforwardly weaponizable from the patch diff.
• Treat this as imminently exploited for planning purposes. Historical precedent (critical Drupal core RCEs) shows scanning and exploit attempts beginning within 24–72 hours of disclosure, often faster.
• Monitor CISA KEV for addition — Drupal core RCEs with active exploitation are routinely cataloged, which triggers Binding Operational Directive remediation deadlines for federal agencies and serves as a forcing function for everyone else.

Detection & Response

Assume compromise is possible if your site was unpatched and internet-facing after disclosure. The detections below target the most reliable post-exploitation observables: the PHP process doing things it never should, and attacker artifacts in the web-accessible files directory.

Sigma Rules

---
title: Web Server PHP Process Spawning Shell or Downloader
id: 3f8a1c94-7b2d-4e51-9c06-8a1f5d2e7b30
status: experimental
description: Detects PHP-FPM, Apache, or Nginx worker processes spawning shells, interpreters, or download tools — a hallmark of post-exploitation following Drupal/PHP CMS remote code execution.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Rare — some legitimate Drupal modules (e.g., image processing, PDF generation) invoke system binaries, but shells and download tools from the PHP process are almost never legitimate
level: high
---
title: PHP File Created in Drupal Web-Accessible Files Directory
id: 9d2e4b17-6c3a-4f82-b510-1e9c7a4d8f26
status: experimental
description: Detects creation of PHP files in the Drupal public files directory (sites/default/files), the most common webshell drop location after Drupal RCE exploitation. PHP should never be written to or executed from this path.
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_creation
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '/sites/default/files/'
      - '/sites/*/files/'
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
      - '.php5'
      - '.php7'
  condition: selection
falsepositives:
  - None expected — Drupal does not write executable PHP to the files directory during normal operation
level: critical
---
title: Suspicious HTTP POSTs to Drupal Field UI and Admin Configuration Endpoints
id: 5c1f7a38-2d9e-4b64-a873-6f2b8e1c4d59
status: experimental
description: Detects inbound POST requests to Drupal Field UI and administrative entity configuration paths from external sources. A spike in these requests, especially from IPs with no authenticated admin session history, is consistent with exploit probing against Drupal core administrative modules.
references:
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    c-request-method: 'POST'
    cs-uri-stem|contains:
      - '/admin/structure/types/'
      - '/admin/structure/entity'
      - '/field-ui/'
      - '/admin/config/'
  filter_known_admin:
    c-ip|contains:
      - '10.'
      - '192.168.'
  condition: selection and not filter_known_admin
falsepositives:
  - Legitimate administrators working remotely — tune the filter to your known admin egress IPs and VPN ranges before enabling alerting
level: medium

KQL Hunt (Microsoft Sentinel)

This query hunts two angles: suspicious child processes of PHP/web server processes reported via Syslog, and external requests hitting Drupal administrative paths in your WAF/proxy logs ingested via CommonSecurityLog. Run it against the window starting at your patch date and working backward at least 14 days.

// Hunt 1: PHP/web server processes spawning shells or download tools (Syslog process events)
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName in~ ("php-fpm", "apache2", "httpd", "nginx")
   or SyslogMessage has_any ("php-fpm", "apache2", "httpd")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "nc -", "python -c", "base64 -d")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

// Hunt 2: External requests to Drupal Field UI / admin config endpoints (WAF, proxy, or firewall CEF logs)
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where RequestMethod == "POST"
| where RequestURL has_any ("/admin/structure/types/", "/admin/structure/entity", "/field-ui/", "/admin/config/")
| where not (SourceIP startswith "10." or SourceIP startswith "192.168." or SourceIP startswith "172.16.")
| summarize RequestCount = count(), DistinctURLs = dcount(RequestURL) by SourceIP, RequestURL, bin(TimeGenerated, 1h)
| where RequestCount > 5
| order by RequestCount desc;

// Hunt 3: Endpoint telemetry — web server processes with unexpected children (MDE-covered hosts)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any ("php-fpm", "apache2", "httpd", "nginx")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python", "python3", "perl")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact to sweep your Drupal fleet for webshell indicators: recently created PHP files in the files directory and PHP files anywhere in the web root modified after the advisory date.

-- Hunt for webshell artifacts in Drupal web roots
-- Adjust WebRoot glob to match your document root layout
LET web_roots <= "/*/{var/www,srv/www,home}/*/sites/default/files/**.php"

SELECT FullPath,
       Size,
       Mtime,
       Ctime,
       hash(path=FullPath).SHA256 AS SHA256
FROM glob(globs=web_roots)
WHERE Mtime > "2026-01-01"
ORDER BY Mtime DESC

-- Hunt for PHP processes with active outbound network connections (possible reverse shells / C2)
SELECT Pid,
       Name,
       CommandLine,
       Exe,
       Username
FROM pslist()
WHERE Name =~ 'php-fpm|apache2|httpd|nginx'

Cross-reference the PIDs from the second query against netstat() output to identify worker processes holding unexpected outbound connections — PHP-FPM workers should be talking to the database and upstream caches, not establishing egress to unfamiliar external IPs.

Remediation and Verification Script

Run on each Drupal host to confirm patch status, apply updates, sweep for webshells, and enforce PHP execution denial in the files directory.

#!/bin/bash
# Drupal Core RCE — verification, patch, and webshell sweep
# Run as a user with permission to execute drush/composer and write web root configs

DOCROOT="/var/www/html"   # Adjust to your Drupal docroot
FILES_DIR="$DOCROOT/sites/default/files"

echo "=== [1] Current Drupal core version ==="
cd "$DOCROOT" || exit 1
drush status --field=drupal-version 2>/dev/null || php web/core/scripts/drupal --version 2>/dev/null

echo "=== [2] Composer audit for outstanding core/contrib security updates ==="
composer outdated "drupal/*" 2>/dev/null | head -50
composer audit 2>/dev/null

echo "=== [3] Apply security updates (core + contrib) — review output before deploying to prod ==="
# composer update drupal/core-* --with-all-dependencies
# composer update --with-all-dependencies   # includes contributed modules
# drush updatedb -y && drush cache:rebuild

echo "=== [4] Webshell sweep: PHP files in the files directory ==="
find "$FILES_DIR" -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -ls 2>/dev/null

echo "=== [5] Recently modified PHP files across the web root (last 30 days) ==="
find "$DOCROOT" -type f -name "*.php" -mtime -30 -ls 2>/dev/null | sort -k11

echo "=== [6] Check for suspicious strings in recently modified files (eval/base64/assert) ==="
find "$DOCROOT" -type f -name "*.php" -mtime -30 -print0 2>/dev/null | \
  xargs -0 grep -lE 'eval\(|base64_decode\(|assert\(|preg_replace\(.*/e' 2>/dev/null

echo "=== [7] Enforce PHP execution denial in files directory (nginx) ==="
# Add to your server block, then reload nginx:
# location ~* ^/sites/default/files/.*\.php$ { deny all; }
# location ~* ^/sites/[^/]+/files/.*\.php$   { deny all; }

echo "=== [8] For Apache: drop this .htaccess into the files directory ==="
cat > "$FILES_DIR/.htaccess" <<'EOF'
<FilesMatch "\.(php|phtml|phar|php5|php7)$">
  Require all denied
</FilesMatch>
EOF

echo "=== [9] Verify file permissions ==="
find "$DOCROOT/sites/default" -type f -name "settings.php" -exec chmod 440 {} \;
chmod 440 "$FILES_DIR/.htaccess"

echo "=== Done. Review section [4]–[6] output for artifacts before trusting this host. ==="

Remediation

1. Patch core immediately. Apply the security release referenced in the Drupal advisory for your major version branch (check https://www.drupal.org/security for the SA-CORE advisory covering your branch). Use composer update drupal/core-* --with-all-dependencies followed by drush updatedb -y && drush cache:rebuild. Do not defer — the vendor has explicitly flagged rapid exploitation risk.

2. Patch contributed modules in the same change window. The advisory flags attack paths through contrib. Run composer audit and composer outdated "drupal/*" to enumerate every module with an outstanding security release. A patched core behind an unpatched contrib module that exercises the same vulnerable API is not a remediated site.

3. Audit user registration and authentication exposure. If the exploit path requires an authenticated session, sites with open or weakly controlled registration are effectively unauthenticated targets. Disable open registration if not required, enforce MFA for all accounts with administrative permissions, and review the user list for accounts created after the disclosure date.

4. Restrict administrative interface exposure. Field UI and entity administration endpoints should never be reachable from arbitrary internet sources. Enforce IP allowlisting or VPN-only access to /admin/* at the WAF/reverse proxy layer. This is a durable control that reduces exposure to the next Drupal admin-module RCE as well.

5. Deny PHP execution in the files directory. Enforce the nginx/Apache rules from the script above on every site. This single hardening step neutralizes the most common Drupal webshell persistence pattern.

6. Hunt before you trust. If the site was unpatched and internet-facing after disclosure, assume a dwell window exists. Run the Sigma/KQL/VQL content above, sweep the web root, review web access logs for anomalous POSTs to administrative paths, and check for unexpected outbound connections from PHP workers. If you find artifacts, treat it as an incident: rotate database credentials (they're readable in settings.php), rotate all admin passwords and API keys, and rebuild from known-good code rather than cleaning in place.

7. Monitor CISA KEV. Drupal core RCEs under active exploitation are reliably added to the Known Exploited Vulnerabilities catalog, which carries BOD remediation deadlines for federal agencies and is a defensible forcing function for private-sector SLA acceleration.

8. Reduce future blast radius. Run PHP-FPM under a dedicated low-privilege user per site, mount the files directory with execution disabled, restrict egress from web servers to an allowlist (updates, package repos, payment gateways), and centralize web server logs into your SIEM so detection content like the above actually has telemetry to run against.

Related Resources

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