titulo: Vulnerabilidad Field UI en Drupal 19/25: se explota sin login meta_description: Drupal parchó el 14 de octubre una ejecución remota en Field UI sin login (19/25). Verifica tu versión, aplica el parche o desactiva el módulo hoy mismo. keywords: vulnerabilidad Field UI Drupal, parche de seguridad Drupal octubre 2026, cómo actualizar Drupal con Composer, ejecución remota Drupal CVE-2026-108097 tags: Drupal, seguridad, Drupal 11, Drupal 10, modulos de drupal categoria: Negocios slug: vulnerabilidad-field-ui-drupal-ejecucion-remota ---
CVE-2026-108097: ejecución remota en Field UI sin login, riesgo 19/25. Afecta Drupal 10.6.x, 11.3.x y 11.4.x; actualiza a 10.6.18, 11.3.18 o 11.4.9.
Qué parchó Drupal el 14 de octubre y por qué no puede esperar
Drupal.org publicó el PSA-2026-10-12, un aviso de seguridad con riesgo calificado 19 de 25, con la advertencia de que las explotaciones pueden aparecer en horas o días desde el anuncio. El 14 de octubre llegaron las correcciones, y la principal es SA-CORE-2026-014: una ejecución remota de código en Field UI catalogada como AC:Basic/A:None, es decir, atacable por cualquier visitante sin cuenta ni sesión.
Field UI es el módulo que permite crear y editar campos de contenido desde la interfaz de administración. Viene incluido en la instalación estándar de Drupal y en la mayoría de distribuciones, así que un sitio típico de pyme lo tiene activo sin que nadie lo haya instalado a propósito. Ese es justamente el riesgo: no es un módulo exótico que puedas ignorar.
En la misma fecha se liberaron además dos correcciones de XSS (SA-CORE-2026-015 y SA-CORE-2026-016) y una ejecución remota en el módulo contribuido Entity List (SA-CONTRIB-2026-218). Si usas Entity List, ese parche también es obligatorio hoy.
Cómo saber en 10 minutos si tu sitio quedó expuesto
Lo primero es identificar en qué versión exacta estás. Puedes hacerlo desde el navegador o desde la línea de comandos:
# Versión reportada por Drupal
drush status --field=drupal-version
También la encuentras en /admin/reports/status. Las ramas afectadas son 10.6.x, 11.3.x y 11.4.x por debajo de 10.6.18, 11.3.18 y 11.4.9 respectivamente. Cualquier versión anterior a 10.6.x o 11.3.x está sin soporte: no recibió parche porque esas ramas ya cerraron mantenimiento, y eso no reduce el riesgo, lo agranda.
Lo segundo es confirmar que Field UI está instalado y activo:
drush pm:list --filter='name=field_ui' --field=status
Si responde enabled, tu sitio tiene la superficie de ataque expuesta. Si responde uninstalled o no aparece, CVE-2026-108097 no aplica a tu caso, aunque igual debes instalar el resto del release por los XSS.
Como tercer paso, revisa los registros de acceso recientes en busca de peticiones sospechosas a rutas de administración de campos, por ejemplo /admin/structure/types/manage/*/fields o /field_ui/. La ausencia de registros no garantiza que no haya habido intentos, pero su presencia sí amerita una revisión a fondo del sitio.
Cómo actualizar con Composer sin dejar el sitio caído
Antes de tocar nada, genera un respaldo completo: base de datos y código. Un git commit limpio y un dump de la base te ahorran noches de madrugada:
mysqldump -u usuario -p nombre_basedatos > backup_$(date +%Y%m%d).sql
git status # debe estar limpio antes de continuar
Luego actualiza core con Composer a la versión parcheada de tu rama. Ejemplo para Drupal 11:
# Drupal 11.4 — actualiza a 11.4.9 o superior
composer require 'drupal/core-recommended:^11.4' \
'drupal/core-composer-scaffold:^11.4' \
'drupal/core-project-message:^11.4' \
--update-with-dependencies
Si estás en la rama 10.6, el comando equivalente usa ^10.6 y te lleva a 10.6.18 o superior. Si vienes de 11.3.x y quieres saltar a 11.4, cambia ^11.3 por ^11.4 y deja que Composer resuelva dependencias.
Después de la actualización aplica los cambios de la base de datos y limpia la caché:
drush updatedb -y
drush cache:rebuild
Verifica en /admin/reports/updates que no queden módulos con actualizaciones de seguridad pendientes. Si algo se rompe, el respaldo y el git revert son tu retorno al estado anterior; no hay atajos mejores que un plan de rollback probado.
Un detalle que se pasa por alto: revisa los módulos contribuidos desactualizados antes de actualizar core. Composer puede bloquear la actualización si un módulo exige una versión de core incompatible. Actualiza primero esos módulos o desinstálalos si ya no los usas.
Si no puedes actualizar hoy: desactivar Field UI como medida temporal
Por qué desactivar Field UI es una medida válida
Desactivar o desinstalar Field UI no borra los campos que ya creaste: el contenido y las definiciones de campos permanecen intactos en la base de datos. Lo que pierdes es la capacidad de administrar campos desde la interfaz durante un tiempo. Para un sitio de pyme que publica contenido habitualmente, eso es perfectamente manejable por 24 o 48 horas.
Cómo hacerlo
# Drupal 11 / 10.6
drush pm:uninstall field_ui -y
drush cache:rebuild
Si no usas Drush, puedes deshabilitar el módulo desde /admin/modules, pero la vía de Drush es más rápida y deja registro.
Considera dos advertencias antes de hacerlo en producción. Primero: si tu proceso de despliegue usa Config Split o un flujo de Configuration Management, la configuración del módulo puede quedar marcada como pendiente; no es un error peligroso, pero avísale a quien administra tu CI/CD. Segundo: si tu equipo necesita editar campos con urgencia mientras Field UI está desinstalado, esa tarea queda en pausa hasta el parche. Planifícalo con ellos, no sorprendas a nadie un lunes en la mañana.
Desactivar Field UI no te deja seguro contra los XSS de SA-CORE-2026-015 y 016. Es una medida de contención, no una solución. El plan debe ser actualizar a 10.6.18, 11.3.18 o 11.4.9 tan pronto sea posible.
Si tu sitio corre Drupal 10.5 o 11.2: no hay parche, hay migración
Drupal 10.5 y 11.2 ya no forman parte de las ramas con soporte. La política de seguridad de Drupal.org solo corrige las ramas activas, y esas son 10.6.x, 11.3.x y 11.4.x. En la práctica, un sitio en 10.5 o 11.2 no recibirá versión parcheada de esta vulnerabilidad ni de las siguientes.
La ruta correcta es migrar a una rama soportada, idealmente a 11.4.x. El salto de 10.5 a 10.6 suele ser menor, pero de 10.x a 11.x exige revisar módulos contribuidos, compatibilidad de PHP y el código custom de tu tema. Calcula ese esfuerzo hoy, no cuando aparezca el exploit público.
Mientras defines la migración, desinstala Field UI como se explicó arriba y reduce el alcance de usuarios con permisos de administración de estructura. Esas dos acciones, sumadas a un WAF o reglas de bloqueo en el servidor, te compran tiempo, pero no sustituyen la migración. Tener un calendario de actualizaciones de seguridad, con Composer y Drush en un proceso documentado, es la diferencia entre parchar en una tarde y reconstruir un sitio comprometido.
Preguntas frecuentes
¿Cuánto tarda en explotarse una vulnerabilidad como CVE-2026-108097?
Drupal.org advirtió en el PSA que las explotaciones pueden aparecer en horas o días desde la publicación del parche. No existe un plazo de gracia oficial: desde el 14 de octubre el exploit puede estar en circulación. Trata cada release crítico como si ya tuviera explotación activa.
¿Puedo actualizar de Drupal 10.5 a 11.4 de un solo salto?
Sí, pero no es un salto de un comando. Primero sube a 10.6.x y deja el sitio estable, y luego migra a 11.4.x revisando módulos contribuidos, temas y código custom. Saltar sin esa escala aumenta el riesgo de romper el sitio sin plan de rollback.
¿Desinstalar Field UI borra mis campos y mi contenido?
No. Al desinstalar Field UI se elimina la interfaz de administración de campos, pero las definiciones de campos y los datos del contenido se conservan. Puedes reinstalarlo después del parche y quedará tal como lo dejaste.
¿Mi sitio en Drupal 9 o 10.4 está afectado por esta vulnerabilidad?
Las versiones anteriores a 10.6.x no recibieron parche porque están sin soporte. Eso no significa que sean seguras: significa que no hay corrección disponible para ellas. La única salida real es migrar a una rama soportada (10.6.x o 11.4.x).
¿Un firewall o un CDN me protegen mientras actualizo?
Pueden mitigar parcialmente el riesgo si bloquean rutas de administración, pero no son una solución. La vulnerabilidad está en el núcleo de Drupal y un ataque que no pase por esas rutas seguiría siendo posible. La solución definitiva es instalar las versiones parcheadas: 10.6.18, 11.3.18 o 11.4.9.
Si tu equipo no tiene experiencia actualizando Drupal con Composer o el sitio lleva versiones atrasadas, conviene pedir una revisión profesional antes de tocar producción. En saibher.com trabajamos Drupal a diario: entregamos sitios y e-commerce con licencia vitalicia, sin mensualidad, y mantenimiento con procesos de actualización como los que describimos aquí. Escríbenos por el formulario de contacto o por WhatsApp y te mandamos una cotización sin compromiso.
