Ayer por la tarde abrí drupal.org/security, como cada miércoles, y empecé a bajar. Y seguí bajando. Treinta y nueve avisos de seguridad de módulos contribuidos, del SA-CONTRIB-2026-254 al 292, todos con fecha del 28 de octubre.
El primero de la lista ya te quitaba las ganas de cenar tranquilo: Commerce Core, Highly critical, 21 sobre 25 y con la coletilla de que ya se está explotando. Debajo venían tres avisos de Commerce Stripe, Single Content Sync con ejecución remota de código, CAPTCHA, Field Permissions, S3 File System, OpenID Connect... y ocho del propio módulo AI, que la ironía tampoco se me escapa. Para rematar, tres proyectos marcados directamente como sin soporte, que es la forma educada de decir "desinstálalo".
Lo curioso es que no me sorprendió. El miércoles anterior habían salido 34. Dos semanas antes, core tuvo su propia ejecución remota de código en Field UI. Y entre medias, PHP sacó parches de emergencia para PHP2Shell. Hace un par de años una semana así habría sido el tema de conversación en todos los Slack de agencias. Ahora es un miércoles más.
Las cifras ya no son de una mala racha
A ver, que los números a veces engañan, pero estos dejan poco margen. Entre 2019 y 2024 los módulos contribuidos se movieron entre 38 y 96 avisos al año. En 2025 fueron 126. En 2026, a 28 de octubre, vamos por unos 290, y todavía quedan nueve semanas de año.
En core pasa algo parecido a otra escala. Llevamos 16 avisos este año, el doble que en 2024 y que en 2025. Y no hablamos de avisos de relleno: en mayo hubo una inyección SQL Highly critical para sitios con PostgreSQL que empezó a atacarse en cuestión de días y que acabó en el catálogo de vulnerabilidades explotadas de CISA.
Si lo miras mes a mes, el cambio hasta tiene fecha. Hasta mayo, contrib iba a un ritmo de entre 3 y 12 avisos al mes. Desde junio no ha bajado de 25. Septiembre cerró con 72, con un día de más de veinte avisos solo para Webform, y octubre ya pasa de cien sin haber terminado.
No es que Drupal se haya vuelto peor
El código de esos módulos no se estropeó este verano. Esos fallos llevaban ahí meses, algunos años. Lo que ha cambiado es lo barato que sale encontrarlos.
En mayo la Drupal Association consiguió financiación de Alpha-Omega, el proyecto de la Linux Foundation, para montar una iniciativa de seguridad apoyada en IA. A las seis semanas ya hablaban de más de diez avisos publicados y más de treinta issues abiertos. Y decían algo que me parece lo más honesto de todo el asunto: el cuello de botella ya no es encontrar bugs, es tener gente que los valide y los arregle.
Drupal tampoco es una excepción, ni de lejos. En el kernel de Linux los mantenedores han pasado de recibir dos o tres reportes por semana a cinco o diez al día, y las últimas versiones rondan los 1.500 CVE cada una, la mayoría encontrados con herramientas de IA. Linus Torvalds llegó a decir en mayo que la lista de seguridad del kernel se había vuelto casi inmanejable. Y PHP2Shell, lo de PHP de la semana pasada, era un fallo que llevaba más de una década en el motor y que se destapó con ayuda de IA.
Así que el patrón se repite en toda la pila. Cuando no es PHP es Drupal, y cuando no es Drupal es el kernel del servidor donde corre todo lo demás.
El otro lado también tiene IA
Si esto fuera solo "se encuentran más bugs y se arreglan", sería hasta una buena noticia. Lo que pasa es que la misma herramienta que usa el equipo de seguridad para encontrar el fallo la tiene cualquiera para explotarlo.
Con la inyección SQL de core de mayo, una empresa de seguridad hizo la prueba de coger el parche público y apoyarse en un modelo de IA para construir un exploit. Le llevó 51 minutos. Con PHP2Shell fue todavía peor: Amazon detectó intentos de explotación en sus honeypots el 17 de octubre, cuatro días antes de que hubiera parche, y los detalles acabaron filtrándose antes de la fecha prevista, hasta el punto de que PHP tuvo que adelantar la publicación. Y el aviso de Commerce de ayer ya salió diciendo que había explotación activa.
Cada aviso de seguridad es, a la vez, un parche y un mapa. A ti te dice qué actualizar y a otro le dice exactamente dónde mirar. Antes había un margen de días, a veces semanas, entre que salía el aviso y aparecía algo que funcionara. Ese margen prácticamente ha desaparecido.
Después de Drupalgeddon, allá por 2014, el equipo de seguridad llegó a decir que un sitio que no se hubiera parcheado en siete horas había que darlo por comprometido. En su momento a mucha gente le sonó exagerado. Hoy a mí me parece casi generoso.
Lo que más me preocupa no es core
Core lo tenemos bastante controlado. Es lo primero que todo el mundo actualiza y casi siempre es un composer update sin sorpresas. Lo que me preocupa es todo lo que hay alrededor.
Me preocupan los módulos que se instalaron hace cuatro años para una funcionalidad concreta y que nadie ha vuelto a mirar. Ayer tres proyectos quedaron sin soporte: hay un fallo conocido, nadie lo va a arreglar y la única salida es quitarlos. Me preocupa Stage File Proxy, que se llevó un aviso crítico y que es un módulo pensado para desarrollo, pero que me he encontrado activo en producción más veces de las que me gustaría. Y me preocupan los arreglos que no arreglan del todo, como Media Alias Display, que recibió ayer un segundo aviso porque el parche de la semana anterior no cerraba bien la vulnerabilidad.
Y luego está la parte que ni siquiera es Drupal. El PHP del servidor, el kernel, la imagen base del contenedor. PHP2Shell afectaba a cualquier web en PHP, tuviera el Drupal que tuviera. Según los datos que circularon esos días, casi tres de cada cuatro servicios que mostraban su versión de PHP iban con la 8.1 o anterior, versiones que ya no reciben parches oficiales. Ahí da igual lo bien que tengas el composer.lock.
¿Y entonces qué hago con esto?
Para empezar, asumir que esto no va a bajar a corto plazo. Plantear el mantenimiento como "una revisión al mes" ya no tiene sentido cuando cada miércoles sale algo y, de vez en cuando, algo gordo cae un martes o un jueves.
En mis proyectos lo que me funciona es que enterarse no dependa de que yo me acuerde. Un composer audit en el pipeline, un drush pm:security programado que avise si hay algo pendiente y los correos de Update Status activados, aunque parezca de la vieja escuela. Nada de esto es nuevo ni sofisticado. Lo nuevo es que ha dejado de ser opcional.
Enterarse es la parte fácil, claro. La difícil es atreverse a actualizar rápido. Y aquí está la trampa: casi nadie actualiza tarde por pereza, actualiza tarde porque no se fía de que no se rompa nada. Si no tienes un entorno de staging y unos tests que te den cierta tranquilidad, cada parche es una apuesta, y lo normal es aplazar las apuestas. Para mí esto es lo que de verdad separa a un sitio que aguanta este ritmo de uno que no.
Mi regla para los Critical y Highly critical es aplicarlos el mismo día. Si por lo que sea no se puede, el propio aviso suele traer una mitigación, como desinstalar un módulo o desactivar una opción concreta, y eso se hace ya. Esperar al lunes a ver qué pasa ya no es una estrategia.
También ayuda tener menos superficie. Cada módulo contribuido es un frente más que vigilar, así que si algo está activado y no se usa, o hace lo que hoy ya resuelve core, fuera. Siempre fue buena práctica, pero ahora se nota en el calendario. Y lo mismo con el servidor: actualizaciones de seguridad automáticas del sistema, una versión de PHP con soporte y reconstruir las imágenes cuando sale un parche.
La última parte es más de conversación con clientes que técnica. Un sitio que recibe los parches críticos el mismo día cuesta más que uno que se revisa cada trimestre, y hay que explicarlo así, sin dramatizar pero sin venderlo como algo que se hace en cinco minutos.
La nueva normalidad
Hay quien piensa que en uno o dos años, cuando la IA haya barrido la mayoría de fallos antiguos, el software será bastante más robusto y el volumen bajará.
Pero la IA no solo encuentra bugs, también escribe muchísimo código nuevo, y que ocho de los avisos de ayer fueran del módulo AI dice algo sobre lo rápido que se está construyendo todo. Igual me equivoco, que conste, pero me cuesta ver la lista de cada miércoles volviendo a los números de 2023.
Lo que sí tengo claro es que mantener una web en Drupal ya no es actualizar cuando toca. Es actualizar cuando sale. El próximo miércoles volveré a abrir drupal.org/security a la misma hora, y no espero que la lista sea corta.