Avisos de seguridad en Drupal: qué debería significar "aplicado"

En corto: una actualización de seguridad de Drupal está aplicada cuando se cumplen cuatro cosas. La versión corregida está en el código de su sitio. Se desplegó por el mismo pipeline probado que cualquier otro cambio. Alguien revisó el sitio en producción y lo vio corriendo la versión corregida. Y la decisión quedó por escrito, con el aviso, la versión y la fecha. "Integrado" y "desplegado" son pasos del camino. Ninguno de los dos es "aplicado".

¿Qué debería significar "aplicado"?

1. Publicado en su código. El sitio pasa a la versión corregida más baja de la rama en la que está. Una actualización de seguridad no debería volverse, sin que nadie lo decida, un salto de versión menor. Después, el composer audit de las dependencias de producción sale limpio.
2. Desplegado por el pipeline. Pruebas, el control de auditoría, la construcción de la imagen, el despliegue y una verificación de que la página de inicio responde. Antes de todo eso se toma una copia de la base de datos y de la imagen que está corriendo, para que devolverse sea un paso conocido y no una improvisación.
3. Verificado en producción. Alguien lee la versión que corre el sitio en producción y comprueba que la imagen en marcha es el commit que se envió. Una verificación de salud demuestra que el sitio responde. No demuestra qué versión respondió.
4. Registrado. El aviso, la versión, los commits, la fecha y la copia, escritos donde otra persona los pueda leer.

¿Cómo publica Drupal sus avisos de seguridad?

El equipo de seguridad de Drupal los publica en drupal.org/security, en tres listas: núcleo, proyectos contribuidos y anuncios de servicio público. Se pueden seguir con el boletín de seguridad de su perfil en drupal.org, por RSS, o en Mastodon y Bluesky.

Salen en horarios fijos:

• Entre las 11:00 y las 17:00, hora de Colombia (16:00 a 22:00 UTC).
• Los módulos contribuidos tienen ventana todos los miércoles.
• El núcleo tiene un miércoles al mes, casi siempre el tercero.

Que haya ventana no quiere decir que vaya a salir algo. Un problema altamente crítico puede publicarse por fuera de ella.

Cada aviso trae un nivel de riesgo, con un puntaje de 0 a 25 según el sistema de puntuación de NIST (Common Misuse Scoring System). Los cinco niveles van de "no crítico", pasando por "poco crítico", "moderadamente crítico" y "crítico", hasta "altamente crítico". Dos avisos recientes del núcleo:

• SA-CORE-2026-013 (16 de septiembre de 2026): moderadamente crítico, 13/25, en librerías de terceros.
• SA-CORE-2026-014 (14 de octubre de 2026): crítico, 19/25, ejecución remota de código en el módulo Field UI.

¿Todos los módulos están cubiertos?

No, y esto es lo que más se pasa por alto. En el núcleo, los avisos cubren las dos versiones menores más recientes. Drupal 10 deja de recibirlos cuando termina su soporte, el 9 de diciembre de 2026. En los módulos contribuidos, solo se cubren las versiones estables de los proyectos que se acogieron a la política. Las versiones alfa, beta, candidatas y de desarrollo no. Un proyecto cubierto muestra un escudo en su página de drupal.org.

Eso incluye nuestro propio trabajo. Los dos módulos de nuestro fundador en drupal.org, elevenlabs_agent y maper, están en su serie alfa. Cuando leímos sus páginas el 27 de octubre de 2026, ambas decían que no tienen cobertura. Si su sitio usa un módulo así, alguien tiene que vigilarlo por otro lado: su cola de incidencias, sus versiones y una auditoría de dependencias.

Además, los avisos de Drupal nunca cubren aquello sobre lo que corre Drupal. PHP publica los suyos, y también las librerías de Composer que hay debajo de Drupal. Un composer audit lee los avisos de las librerías; los de PHP, no.

¿Cómo se ve eso en nuestros propios sitios?

• El control de auditoría lo vio primero. Cuando salió el SA-CORE-2026-013, la construcción de cada uno de nuestros sitios falló en la auditoría de dependencias antes de que alguien hubiera leído el aviso. Para eso está ese control. Los cinco sitios pasaron a Drupal 11.4.7, y el 18 de septiembre de 2026 quedó registrado que los cinco corrían 11.4.7 en producción.
• Si no se puede aplicar, se mitiga, y se dice. Con el SA-CORE-2026-014, uno de nuestros sitios, Mon Petit Café, no pudo recibir de inmediato la actualización del núcleo. Su control de auditoría también fallaba por un aviso moderadamente crítico en el módulo de mapas Leaflet (SA-CONTRIB-2026-204), que decidimos dejar abierto hasta que nuestro propio módulo de mapas reemplazara a Leaflet. Así que el 15 de octubre desinstalamos Field UI en ese sitio en producción, como medida temporal, y dejamos escrito por qué. Leaflet salió del código de ese sitio el 21 de octubre.
• Una excepción necesita una fecha para volver a mirarla. En junio de 2026, el composer.json de este sitio dejó registrados como ignorados dos avisos de la librería guzzlehttp/psr7, con la razón por escrito. El núcleo fijaba esa librería en un rango sin corrección, y el sitio solo la usa para peticiones salientes a direcciones conocidas, así que ningún visitante controla el servidor que lee el código vulnerable. La nota decía: revisar cuando el núcleo pase a 11.4. El núcleo está en 11.4 desde julio, y la librería va en la 2.13.2, más allá de la versión corregida (2.10.2). Así que esas excepciones ya no ocultaban nada, pero seguían en el archivo. Las quitamos el 31 de octubre de 2026, con una nota que explica por qué.
• PHP necesitó su propia revisión. El 21 de octubre de 2026, PHP publicó correcciones para dos fallas críticas de ejecución remota de código (CVE-2026-109618 y CVE-2026-109619). La base PHP 8.3 de nuestra imagen se había quedado en la 8.3.29 desde enero, así que ninguna reconstrucción podía traer la corrección. El 26 de octubre pasamos la imagen a PHP 8.4.27. El pipeline la desplegó esa misma noche, y la verificación de salud pasó. El 31 de octubre leímos PHP 8.4.27 en el sitio en vivo.

¿Qué prometemos cuando sale un aviso?

Si nos contrata para cuidar un sitio, un aviso que lo toque se empieza a atender el mismo día hábil. Lo evaluamos contra su sitio, aplicamos la corrección o la mitigamos, revisamos el sitio en producción desde afuera y lo dejamos por escrito. Eso es una condición del servicio, no un récord medido: no hemos medido tiempos entre aviso y despliegue, y no vamos a citar uno. El horario es hábil de Colombia (UTC-5) y no hay guardias 24/7, porque hoy el ingeniero es nuestro fundador. Antes de Tecnocratica, él dirigió la respuesta de toda una flota a un aviso del núcleo de Drupal, en una flota de salud de unos 400 sitios.

¿Qué preguntarle a su proveedor?

• ¿Qué avisos evaluó este mes, y qué decidió con cada uno?
• ¿Qué módulos de mi sitio no tienen cobertura de la política de avisos, y cómo los está vigilando?
• ¿Cómo sabe que el sitio en producción corre la versión corregida?
• ¿Dónde está el registro, y lo podría leer otra persona?
• ¿Qué vigila además de Drupal: PHP, las librerías, la imagen del servidor?

La rutina mensual alrededor de estas respuestas está en qué debe revisarse cada mes en el soporte y mantenimiento Drupal. Si quiere que revisemos los módulos y la cobertura de su sitio, escríbanos o pregúntele al concierge en la página de inicio. Nuestra oferta explica cómo recibimos un sitio.