El parche ya es obligatorio: CVE-2026-108097 permite ejecución remota de código en el módulo core Field UI sin necesidad de iniciar sesión, siempre y cuando haya módulos contribuidos involucrados. La acción debe tomarse hoy, ya sea actualizando a la versión corregida o mitigando con la desinstalación temporal del módulo.
El alcance real de la vulnerabilidad
Field UI es parte del core de Drupal y se encarga de las pantallas de "Administrar campos" y "Administrar visualización" para entidades con tipos de contenido personalizados. Al ser un módulo base, es fácil que esté habilitado sin que se recuerde, sobre todo en sitios que han tenido contenido personalizado desde sus inicios.
La falla, sin embargo, no se activa únicamente con Field UI. Según The Hacker News, el core por sí solo no es suficiente para explotarla: son los módulos contribuidos los que interactúan con este componente los que generan el vector de ataque. Es esa combinación la que permite la ejecución remota sin autenticación. A su vez, SecurityWeek advierte que el equipo de seguridad de Drupal prevé una explotación rápida, por lo que la ventana para actuar es corta.
Por este motivo, la prioridad no es cuestionar la etiqueta crítica, sino verificar si Field UI está habilitado en el sitio y si existen módulos contribuidos que dependen de él.
Cómo funciona el vector: render callbacks mal validados
El mecanismo detrás de esta vulnerabilidad son los render callbacks. Drupal construye gran parte de su interfaz con render arrays, los cuales pueden contener claves como #theme, #pre_render, #post_render o #lazy_builder. Estas le indican al motor de renderizado qué función PHP debe ejecutar para generar el elemento correspondiente. Es un sistema normal, flexible y necesario para la arquitectura de Drupal.
El problema ocurre cuando un módulo acepta callbacks provenientes de una entrada no confiable sin validarlos contra una lista blanca. Si un atacante logra controlar el nombre de esa función o sus parámetros, Drupal terminará invocando código PHP arbitrario durante el proceso de renderizado. Con las condiciones correctas —un módulo contribuido vulnerable junto a Field UI— esto puede lograrse sin iniciar sesión alguna.
La corrección aplicada por el equipo de Drupal no elimina los render callbacks, sino que limita la forma en la que Field UI los acepta y procesa. Ahí radica la diferencia entre una mitigación superficial y un parche real: este corrige la validación de la entrada, no únicamente una ruta. Para cualquier módulo propio, la regla es sencilla: si se permite un callback configurable, este debe validarse con una lista explícita de funciones permitidas, nunca con datos crudos provenientes de una petición.
Acción 1: actualizar el core a la versión corregida
La solución definitiva es actualizar Drupal a la versión que incluye el parche. Antes de aplicarlo a producción, siempre se debe hacer una copia de seguridad completa de archivos y base de datos, además de probarlo en un entorno de staging con una réplica lo más fiel posible.
# Ajusta la versión según tu rama: 11.4.10, 11.3.19 o 10.6.19
composer require drupal/core-recommended:11.4.10 \
drupal/core-composer-scaffold:11.4.10 \
drupal/core-project-message:11.4.10 \
--update-with-dependencies
Una vez actualizado el código, es necesario aplicar las actualizaciones de base de datos y limpiar cachés:
drush updatedb -y
drush cache:rebuild
Para confirmar que el proceso fue exitoso, se puede verificar la versión y el estado de Field UI:
drush status --fields=drupal-version
drush pm:list --status=enabled | grep field_ui
Es importante no mezclar versiones entre core-recommended y drupal/core. Si el comando updatedb falla, el despliegue debe detenerse y restaurarse desde el respaldo en staging para resolver el error antes de intentar nuevamente en producción.
Acción 2: desinstalar Field UI como mitigación temporal
Si no hay ventana de mantenimiento inmediata para el parche, la mitigación recomendada por el equipo de seguridad es desinstalar el módulo field_ui. Esto elimina las rutas y la configuración asociadas al vector, reduciendo drásticamente la superficie de ataque. Los datos de los campos y el contenido ya existente no se perderán con esta acción, aunque sí se perderá la interfaz para crearlos o editarlos desde la administración.
drush pm:uninstall field_ui -y
drush cache:rebuild
Antes de ejecutarlo, se debe revisar si algún otro módulo declara a field_ui como dependencia. En caso de que Drush lo rechace, la única opción limpia es aplicar la actualización. Desinstalar no es lo mismo que deshabilitar: esta última reduce la carga del módulo, pero la recomendación explícita es la desinstalación, ya que elimina la configuración y las rutas involucradas.
Verificación y priorización después de actuar
Independientemente de la acción tomada, hay puntos a revisar para confirmar que el riesgo se ha contenido:
- Dependencias: listar todos los módulos contribuidos que dependen de
field_uiy verificar si cuentan con actualizaciones de seguridad pendientes. - Rutas anónimas: revisar si algún módulo añade rutas de administración de campos accesibles sin iniciar sesión.
- Logs: buscar solicitudes repetidas a rutas relacionadas con Field UI o parámetros atípicos en los últimos días.
- Integridad: comparar usuarios administradores, archivos PHP modificados y sesiones activas con un respaldo reciente.
- Auditoría de Composer: ejecutar
composer auditpara revisar posibles avisos abiertos en otras dependencias.
La exposición real es lo que define la urgencia. Un sitio donde field_ui no está habilitado y sin módulos que lo utilicen tiene menor superficie, pero el parche sigue siendo necesario si este llega a habilitarse en algún flujo. Un sitio con tipos de contenido administrados desde la interfaz y módulos contribuidos sin actualizar debe priorizarse sin demora.
El siguiente paso es concreto: hacer el respaldo ahora, confirmar el estado de field_ui y aplicar la actualización en staging antes de llevarla a producción. Si esto no es posible hoy, desinstalarlo, documentar la deuda y agendar el parche para las próximas horas.
Preguntas frecuentes
¿Debo actualizar si no uso Field UI?
Sí. Field UI viene en core y puede estar habilitado sin que se recuerde. Además, un módulo contribuido puede depender de él aunque no se utilice la interfaz a diario. Es recomendable verificar su estado con drush pm:list --status=enabled | grep field_ui y aplicar el parche si aparece habilitado.
¿Puedo solo deshabilitar Field UI en lugar de desinstalarlo?
La recomendación oficial es desinstalarlo, ya que elimina rutas y configuración asociadas al vector. Deshabilitar reduce la superficie, pero no es equivalente a la mitigación sugerida. Si hay dependencias que lo impiden, la actualización del core es la única salida limpia.
¿Cómo sé si mi sitio fue comprometido?
No existe un único indicador. Es necesario revisar usuarios administradores nuevos, archivos PHP modificados, tareas cron desconocidas, sesiones activas inusuales y solicitudes a rutas de Field UI en los logs de acceso. Comparar con un respaldo reciente es fundamental, y en caso de encontrar anomalías, el sitio debe aislarse antes de continuar la investigación.
¿El parche requiere actualizar la base de datos?
Sí. Tras actualizar el código con Composer, es obligatorio ejecutar drush updatedb -y y posteriormente drush cache:rebuild. Si el proceso de actualización de base de datos falla, se debe restaurar el respaldo y resolverlo en staging antes de reintentar en producción.
¿Esto aplica a Drupal 7?
No. Esta corrección corresponde a las ramas 10.6.x y 11.x. Drupal 7 ya no recibe soporte de seguridad oficial, por lo que la recomendación no es buscar un parche retroportado, sino migrar a una versión soportada.
