Drupal fixes CVE-2026-108099 in Entity List 3.0.10 amid sparse exploit evidence

Drupal now has a fixed release for CVE-2026-108099: every version of the Entity List contributed module before 3.0.10 is affected, and 3.0.10 is the patch. The advisory, SA-CONTRIB-2026-218, gives responders an unambiguous remediation step but very little detection material. According to an analysis published on dev.to, no proof of concept, no complete request chain and no CVE-specific indicators of compromise have been made public.

What the flaw is

Per the dev.to write-up, the advisory describes a reflection-injection weakness whose exploitation depends on other contributed or custom code present on the site, and it identifies at least one path that can be reached without authentication. Versions below 3.0.10 are in scope. The advisory does not name the vulnerable symbol, which has a practical consequence: defenders cannot hunt for a known payload, and a narrow text search that comes back clean proves little. Investigation has to be assembled from software inventory, reachability analysis and generic signs of post-exploitation.

Start with the running code

First establish where Entity List below 3.0.10 is actually installed, checking the active code rather than only a dependency declaration. Record both sites that use the module directly and sites that inherit it through a shared platform or custom feature. Next, map where Entity List behavior meets untrusted input. The dev.to post points to custom controllers, forms, imports, queues and contributed integrations that select a class or callback dynamically as the places to review.

Checks when code execution is in question

Because the exploit request is not public, the recommended review targets the consequences of unauthorized execution. The dev.to post lists five things to look for: unexpected changes to Drupal code, themes or configuration; new administrative accounts or permission changes with no matching change record; unexplained scheduled tasks, cron changes or outbound connections from the web tier; web-shell indicators or files created outside the normal deployment path; and database changes that do not match application activity. The author is explicit that these are generic investigative checks, so a positive finding still requires correlation and a negative one does not prove the site was never targeted.

Preserve before rebuilding

If compromise is suspected, the post advises preserving application, web server and database logs, deployment records and relevant filesystem metadata before remediation, and recording the Entity List version and custom-code state first. Rebuilding without preserving evidence can destroy useful traces and make scope assessment harder. The official advisory covers the module update only and provides no incident-response sequence, so organizations should fall back on their own containment and evidence-preservation policies.

Patch, then verify

The remediation itself is straightforward: upgrade Entity List to 3.0.10, deploy the fixed package to every runtime, and verify the version that is actually active. The dev.to post also suggests reviewing whether custom integrations should be changed to enforce an allowlist around class selection, since dynamic class or callback selection is what makes the weakness reachable in the first place.

Reading the scan numbers correctly

For exposure context, the post cites ZoomEye results from November 8, 2026: 435,185 matches for its Drupal application filter and zero for the CVE filter. As the author notes, those counts describe a fingerprint and a CVE association, not confirmed vulnerable or compromised sites, so neither number should be read as a measure of impact.

Why it matters

This advisory pairs an easy fix with a hard investigation. Patching is a single version bump, but answering whether a site was attacked has no signature shortcut: exploitability depends on site-specific custom code, no CVE-specific indicators exist, and internet-wide scan data currently offers no signal. That makes the disciplined basics — accurate inventory, reachability review of dynamic class selection, generic post-exploitation checks and evidence preservation before rebuilding — the entire toolkit. Teams that remediate without first recording their module versions and custom-code state will find scope assessment far harder afterward, which is the quiet operational lesson of this CVE.