psf-drupal-core-check(8)

Script: /opt/psf-security-patches/drupal/drupal-core-check.sh. Tool page: Drupal. Source. With the package installed: man psf-drupal-core-check.

Drupal core Field UI and Entity List remote code execution: checker with mitigation  (v2)
CVE-2026-108097 (SA-CORE-2026-014) and CVE-2026-108099 (SA-CONTRIB-2026-218)

If this software is helpful, consider a donation to our 501c3 nonprofit:
https://privacysafe.foundation

The Field UI module in Drupal core does not properly validate PHP callbacks
while it renders its tables. Drupal rates it Critical, 19/25. Drupal core
alone is not directly exploitable: the callbacks have to be reachable from
data an attacker controls, and that happens through contributed modules or
custom code. At least one such path needs no authentication, which is why the
Drupal Security Team announced it in advance (PSA-2026-10-12) and called for
emergency patching. A research write-up with laboratory artifacts has been
published; at disclosure no public exploit for real sites existed.

  Affected: Drupal core 8.9.0 up to 10.6.19, 11.0.0 up to 11.3.19,
            11.4.0 up to 11.4.10, and Drupal 12 before 12.0.0-beta2
  Fixed:    10.6.19, 11.3.19, 11.4.10 (released 14 October 2026), and
            12.0.0-beta2 for Drupal 12
  Move to:  a supported branch. 10.5.x and earlier, 11.2.x and earlier, 9.x and
            8.9.x are end of life
  Workaround published by Drupal: uninstall the core Field UI module. It covers
            only this advisory. The same release fixes two other core issues
            that only the update fixes.

CVE-2026-108099 is the same story for the contributed Entity List module
(project entity_list), which builds lists of entities without Views. Versions
before 3.0.10 have a critical remote code execution flaw (Drupal rating 19/25).
It is not directly exploitable by itself, but multiple serious exploit paths exist
with other contributed modules, at least one needs no authentication, and custom
code may expose it. Fixed: Entity List 3.0.10 (14 October 2026). UPDATING DRUPAL
CORE DOES NOT REPLACE THE MODULE: it needs its own update. The script checks it on
every site it finds, whatever the core version is.

"check" is read-only; "mitigate" and "rollback" are the only commands that change
anything. "check" finds Drupal sites from core/lib/Drupal.php (and
composer.lock), applies the version rules, reads exported configuration
(core.extension.yml) to see whether Field UI is enabled, and flags the
contributed Entity List module and compares its version with 3.0.10 (read from
its info.yml, or from composer.lock when the info file carries no version).

Usage:
  ./drupal-core-check.sh [command] [DIR ...]

  check (default)  scan DIR (default /var/www /srv /opt /home). Exit 0 = nothing
                   exposed, 1 = an affected site is exposed, unverifiable, or on
                   an end-of-life branch that cannot be patched.
  mitigate [--dir DIR] [--dry-run] [--force]   (root) changes the host. Drupal's own
                   published workaround for CVE-2026-108097: uninstalls the Field UI
                   module with drush (pm:uninstall field_ui) on every site whose core is
                   affected and where the LIVE site (not only exported configuration)
                   still has it enabled. drush runs as the owner of the site, never as
                   root, and is looked up in the project's vendor/bin, then PATH. The
                   field management screens are unavailable until you reinstall Field UI.
                   It covers this advisory only: the same release fixes two other core
                   issues, so update core as well. --force uninstalls on a core that is
                   not in the affected range.
  rollback [--dry-run]   reinstall Field UI (pm:install field_ui) on the sites mitigate changed.
  version          print the script version.

Configuration kept only in the database is not visible to a file scan. On a
live site, run in the Drupal root:
  drush pm:list --status=enabled --type=module --format=list | grep -x field_ui
Containers: with no directory argument the check also copies the files it reads from running
docker and podman containers (SCAN_CONTAINERS=1, the default; 0 skips them) and judges them like
host installs. The copies are temporary: a path shown as .../docker_NAME_PATH is the PATH inside
the container NAME.
     PSF_LOCK_WAIT    seconds a run that changes the host waits for another one that is already
                      changing it (default 30), then stops with exit 2; the lock is STATE_DIR/.lock

The Security Patches software and this documentation are dedicated to the public domain under CC0 1.0 Universal. Other pages on privacysafe.app/docs are CC BY-SA 4.0 unless the page says otherwise.