Drupal’s Separate Patch

The code-execution flaw is not directly exploitable alone. Serious paths involve other contributed modules, including an unauthenticated route; custom code may expose it too. Drupal’s critical 19/25 rating is not CVSS; exploitation is theoretical, not confirmed attacks. It supplies no exploit code, indicators, partner-module names or exposure count.

Two different maintenance decisions

The project page identifies the package as drupal/entity_list, with compatibility for Drupal ^10.1 or ^11. It builds entity lists without Views, using query, display and filter plugins.

Field UI’s separate core fix, covered earlier, does not update Entity List.

For an agency maintaining inherited client sites, the practical problem is ownership. One team may maintain the central core build while another controls a customer’s contributed packages. Ask both for the deployed state before closing the work. A current central template cannot answer for a site last handed over by a departed supplier.

Make the result visible

Our recommendation is to reconcile each site’s dependency records with its running application. Keep the reviewed package and lock-file changes together through testing and deployment, rather than resolving a different dependency set on the live host. Record the owner of any exception.

Test representative content, user, file, media or taxonomy lists, including language selection, filters, sorting and paging. Check the visitor-facing result without an administrative session. Include custom query, display and filter routes rather than relying solely on a generic status page.

Record both the deployed version and a working list for each site. Neither proves the other.

Investigate separately

Preserve application and deployment evidence when activity looks suspicious. Investigate the earlier state separately; a successful update cannot resolve that history.

These are our recommendations, not results from inspecting readers’ sites.