Drupal parchea un fallo crítico en Field UI explotable sin autenticación

Drupal publicó el 14 de octubre de 2026 las versiones 11.4.10, 11.3.19 y 10.6.19 para cerrar un fallo crítico de ejecución remota de código en el módulo Field UI del núcleo, identificado como SA-CORE-2026-014 y puntuado con 19 sobre 25 en su escala de riesgo. El núcleo por sí solo no permite explotarlo, pero el equipo de seguridad confirma varias vías a través de módulos contribuidos y al menos una no exige autenticación, en un parque en el que 151.442 sitios seguían en ramas sin parche la semana del 4 de octubre.

Qué ha pasado

El equipo de seguridad de Drupal avisó el 12 de octubre con el comunicado PSA-2026-10-12 de que el miércoles 14, entre las 16:00 y las 21:00 UTC, publicaría una actualización crítica del núcleo, y pidió a los administradores que reservasen tiempo porque «exploits might be developed within hours or days» (podrían desarrollarse exploits en horas o días). Ese día salieron cinco avisos a la vez. El principal es SA-CORE-2026-014, que describe una ejecución remota de código en Field UI, el módulo del núcleo que gestiona los campos y su visualización desde la interfaz de administración. El aviso lo firma el propio equipo de seguridad, que atribuye el hallazgo a Drew Webber, miembro del equipo, y a Octavio Galland.

La frase que importa está en la descripción del aviso. Drupal explica que el fallo no es explotable con el núcleo solo, pero que hay varias rutas con módulos contribuidos y que «At least one known exploit path does not require authentication» (al menos una vía de explotación conocida no requiere autenticación). El código a medida de cada sitio también puede exponer la función vulnerable. El equipo no ha dicho qué módulos abren esas rutas, y es la razón por la que la decisión de parchear no puede depender de inventariar extensiones.

El mismo día se publicó SA-CONTRIB-2026-218, con la misma puntuación de 19 sobre 25 y el mismo texto, para el módulo contribuido Entity List, que permite construir listados de entidades sin usar Views y que, según el análisis de Kevin Gautreau que citamos más abajo, lleva una copia de la tabla de Field UI. Se corrige en Entity List 3.0.10 y actualizar el núcleo no lo arregla, hay que actualizar el módulo por separado. Los otros tres avisos del 14 de octubre son cross-site scripting de riesgo moderado en los módulos Link y Navigation del núcleo y en el tema de administración Gin.

Detalles técnicos

Drupal no publica CVSS. Su escala propia de 25 puntos combina seis factores, y en este aviso el vector dice que la complejidad del ataque es básica (AC:Basic), que no hace falta ningún privilegio (A:None), que el impacto en confidencialidad e integridad es total (CI:All, II:All), que la explotación es teórica porque no hay exploit público (E:Theoretical) y que afecta a configuraciones por defecto o habituales (TD:Default). Kevin Gautreau, autor del blog kgaut.net, que analizó el parche en su blog el mismo 14 de octubre, señala que el aviso previo del día 12 calificaba la complejidad como compleja y que el aviso final la rebajó a básica, lo que subió la nota.

El mecanismo lo describen tanto Gautreau como The Hacker News. Las páginas de gestión de campos y de visualización de Field UI se construyen con un elemento de tabla, field_ui_table, en el que cada fila declara un callback llamado #region_callback para decidir en qué región de la tabla aparece. Antes del parche, el paso previo al renderizado ejecutaba ese callback con call_user_func_array sin comprobar que estuviera permitido. El propio renderizador de Drupal rechaza callbacks no confiables desde la versión 8.8 de 2019, pero esta tabla no pasaba por ese filtro, y la llamada estaba en el código al menos desde Drupal 8.9.0, de 2020. Con la corrección, la región se lee del valor de la fila y el callback deja de ejecutarse.

El diagrama resume por qué el núcleo solo no basta para explotar el fallo. Hace falta que algún módulo contribuido o algún código del sitio exponga la tabla a datos que controle un tercero, y eso es lo que el equipo de seguridad dice que ocurre con varias extensiones, al menos una de ellas sin login. Quien quiera repasar en qué consiste una ejecución remota de código y cómo se encadena con otros ataques tiene en el blog una guía de fondo.

Drupal Steward, el firewall de aplicaciones web con reglas escritas por el equipo de seguridad que ofrecen Acquia, Pantheon, Ironstar y Skpr a sus clientes, ya bloquea algunos vectores conocidos. El aviso advierte de que esa protección no cubre todos los exploits posibles y que los sitios deben actualizar igualmente. Para quien no pueda hacerlo de inmediato, el aviso indica que desinstalar field_ui «will provide protection while sites are updated» (dará protección mientras se actualizan los sitios), a costa de perder las páginas de gestión de campos hasta reinstalarlo.

A quién afecta

A cualquier sitio en Drupal 10.6.x, 11.3.x o 11.4.x que no haya actualizado desde el 14 de octubre, y a todos los que sigan en ramas sin soporte. Drupal 11.2.x y anteriores, 10.5.x y anteriores y las versiones 8 y 9 están afectadas y no reciben corrección. Según las estadísticas de uso de drupal.org que recoge The Hacker News, en la semana del 4 de octubre 151.442 de los 531.499 sitios que informan de su versión del núcleo, un 28,5 %, estaban en una rama afectada sin parche disponible. El gráfico recoge esas dos cifras.

Entity List es un módulo pequeño, con 90 sitios que informaban de su uso esa misma semana, pero la vía de ataque que describe su aviso es idéntica. Drupal 7, que alcanzó el fin de vida en drupal.org en enero de 2025, recibe el parche solo a través de programas de soporte extendido. Pantheon explica que su programa con Tag1 Consulting publicó Drupal 7.107 con la corrección y recuerda que, tras actualizar, el núcleo deja de llamar a #region_callback, así que el código a medida que lo use dejará de funcionar y hay que probar las páginas de gestión de campos y de visualización.

En España, Drupal es el gestor habitual de buena parte de la administración y la universidad. El directorio de The Drop Times lista entre los sitios públicos que lo usan a la Comunidad de Madrid, el Ayuntamiento de Barcelona, el de Alcobendas, la FECYT y Patrimonio Nacional, y entre las universidades a Granada, Zaragoza, Las Palmas, Jaén y Vigo. INCIBE-CERT no había publicado aviso sobre SA-CORE-2026-014 en el momento de escribir esta noticia, aunque sí lo hizo en mayo con el fallo anterior del núcleo, el aviso INCIBE-2026-359 sobre la inyección SQL para sitios con PostgreSQL, en el que recogía que Drupal recomendaba instalar el parche lo antes posible porque «temen que, en cuanto se publique la solución, rápidamente aparezcan exploits para aprovechar el fallo». No hay recuento público de sitios Drupal expuestos en España a fecha de 19 de octubre, así que no damos cifra.

Qué hacer

Si administras un sitio Drupal, por orden de urgencia.

1. Actualiza el núcleo a 11.4.10, 11.3.19 o 10.6.19 según tu rama. Si usas Entity List, actualiza también el módulo a 3.0.10, porque la actualización del núcleo no lo toca. Si usas el tema Gin, pasa a 5.0.16 o 4.1.4.
2. Si no puedes actualizar hoy, desinstala field_ui y vuelve a instalarlo después de parchear. Los sitios alojados con Drupal Steward tienen parte de los vectores bloqueados, pero el aviso pide actualizar igual.
3. Si estás en 11.2.x o anterior, en 10.5.x o anterior, o en Drupal 8 o 9, no hay parche. Migra a una rama con soporte, y ten en cuenta que 11.3.x y 10.6.x pierden la cobertura de seguridad en diciembre de 2026, así que la rama a la que conviene saltar es 11.4.x.
4. Revisa el código a medida y los módulos propios en busca de usos de field_ui_table y #region_callback, porque son los que pueden abrir la ruta de explotación y los que dejarán de funcionar tras el parche.
5. Busca señales de abuso en los registros desde el 12 de octubre, cuando se publicó el aviso previo, y si encuentras algo trata el sitio como comprometido, restaura desde una copia limpia anterior y notifica a INCIBE-CERT si eres empresa o ciudadano y al CCN-CERT si eres administración pública.

Gautreau propone estas comprobaciones con Composer y Drush para actualizar y verificar la versión instalada, y una búsqueda en el código propio de los dos elementos implicados.

composer update "drupal/core-*" --with-all-dependencies
composer update drupal/entity_list
drush updatedb -y
drush cache:rebuild
drush status --field=drupal-version
grep -rn "field_ui_table\|#region_callback" web/modules/custom web/themes/custom

Para la revisión de los registros, el mismo análisis sugiere buscar errores de PHP originados en la clase FieldUiTable y ficheros PHP escritos en el directorio de archivos públicos en los últimos días, que en un Drupal sano no deberían aparecer.

drush watchdog:show --severity=Error --count=200 | grep -i fielduitable
find web/sites/*/files -name "*.php" -mtime -7

Si gestionas despliegues con integración continua, este es el momento de comprobar que la cadena de DevSecOps permite sacar una actualización del núcleo en horas y no en el siguiente sprint, porque el propio equipo de Drupal ha avisado de que ese es el margen.

Análisis

Lo primero que llama la atención del aviso es lo que no dice. Drupal confirma que existen rutas de explotación sin autenticación a través de módulos contribuidos y no nombra ninguno. Es una decisión deliberada para no dar pistas, y es coherente con la política del equipo de no publicar más detalles hasta que la mayoría haya parcheado, pero deja a los administradores sin forma de saber si su combinación concreta de módulos está en la lista. La lectura práctica es que cualquier Drupal con módulos contribuidos, que son casi todos, debe darse por explotable hasta que actualice. El precedente de mayo lo confirma. El fallo de inyección SQL de SA-CORE-2026-004 también salió con exploit teórico, y en dos días había intentos de explotación y CISA lo metió en su catálogo KEV, cuyos plazos de corrección ya hemos analizado, con cinco días de margen para las agencias federales.

La cronología del diagrama deja ver el segundo problema, el del calendario. Dos de las tres ramas que han recibido el parche, 11.3.x y 10.6.x, pierden la cobertura de seguridad en diciembre de 2026. Quien hoy actualice a 11.3.19 o a 10.6.19 habrá cerrado este fallo y tendrá que volver a migrar en dos meses. La operación sensata es saltar directamente a 11.4.10, y para los sitios que siguen en Drupal 7, 8 o 9, el 28,5 % de ramas sin parche del gráfico anterior es la medida del trabajo pendiente. Lo hemos visto con otros productos este mes, como el fallo CVSS 10 de GitLab, donde el parche existía y el problema era la velocidad de despliegue.

Hay un tercer asunto que afecta a la gestión de vulnerabilidades. A 19 de octubre, los identificadores CVE que Drupal asignó a los dos fallos no aparecen en NVD, así que los escáneres que dependen de esa base de datos no los detectan y los cuadros de mando que priorizan por CVSS no tienen puntuación que mostrar. Si tu proceso de parcheo se dispara con el CVE, en este caso se dispara tarde. Es el mismo problema que planteábamos con los plazos de parcheo que exige NIS2 a los sectores esenciales, la fuente de verdad tiene que ser el aviso del proyecto, no el catálogo. Y el firewall de aplicaciones, Drupal Steward u otro, compra tiempo, pero como con cualquier regla de detección de intrusos solo cubre los patrones que ya se conocen.

Contexto

Drupal tiene cinco entradas en el catálogo KEV de CISA, según el fichero JSON del catálogo publicado el 16 de octubre: tres ejecuciones remotas de código del núcleo de 2018 y 2019, con Drupalgeddon 2 como la más recordada, una subida de ficheros sin restricciones de 2020 y la inyección SQL de mayo de 2026, incorporada el 22 de mayo con plazo hasta el 27. Por la numeración, SA-CORE-2026-014 es el decimocuarto aviso del núcleo publicado este año. Segu-Info resume el impacto potencial del nuevo fallo en una frase, «Una explotación exitosa podría exponer todos los datos privados del sitio web», y recuerda que el boletín público no especifica qué módulos están implicados ni aporta un exploit funcional. SecurityWeek subraya que Drupal no menciona explotación de ninguno de los cinco fallos, y The Hacker News confirmaba el 15 de octubre que no había exploit público ni ataques descritos.

Preguntas frecuentes

¿Mi Drupal está afectado si no tengo instalado ningún módulo contribuido?

El aviso dice que el núcleo solo no es explotable de forma directa, pero el código a medida del sitio también puede exponer la función vulnerable, así que la respuesta depende de lo que haya en modules/custom y themes/custom. Como Drupal no ha publicado qué módulos abren las rutas de ataque y casi todos los sitios en producción usan alguno, lo razonable es actualizar sin esperar a confirmarlo.

¿Sirve desinstalar Field UI como solución definitiva?

No. Es la mitigación que ofrece Drupal para ganar tiempo, y funciona porque elimina el elemento de tabla que contiene el fallo, pero deja al sitio sin las páginas de gestión de campos y de visualización. Entity List lleva su propia copia de esa tabla, así que desinstalar Field UI no protege a los sitios que usen ese módulo sin actualizarlo a 3.0.10.

¿Qué pasa con los sitios en Drupal 7?

Drupal 7 dejó de recibir soporte en drupal.org en enero de 2025 y el aviso no lo menciona. Pantheon ha publicado Drupal 7.107 con una adaptación del parche dentro de su programa de soporte extendido con Tag1 Consulting. Fuera de ese programa, un sitio en Drupal 7 no tiene corrección y la única salida es migrar a una rama con soporte, con 11.4.x como destino recomendable.

Quien gestione un portal público con Drupal y quiera revisar el resto de la superficie expuesta puede seguir con nuestra guía para proteger las APIs y las aplicaciones web, que recorre los controles que complementan a un parche a tiempo.