MariaDB tapa el GRANT PROXY y Ubuntu 24.04 aún no lo trae

El aviso de MariaDB cabe en una línea: con un GRANT PROXY y una contraseña vacía, el servidor comprobaba los permisos equivocados, y una cuenta de poco privilegio podía fijar la contraseña de otra. Está corregido desde la 10.11.19, del 24 de agosto. El archivo de Ubuntu 24.04 sigue en la 10.11.14.

No voy a reproducir el fallo ni a contar cómo se dispara. Lo que he hecho es preguntar, fuente por fuente, qué versión puede instalar hoy quien tenga Ubuntu 24.04 con la MariaDB de Ubuntu, quién queda expuesto según el aviso y por dónde se sale mientras Ubuntu no publique paquete.

Qué he mirado y cómo

Lo Probado es del 20 de octubre de 2026, entre las 21:50 y las 22:00 UTC, sin instalar nada: consultas a la API de Launchpad y a los índices públicos del repositorio de MariaDB y de esm-apps, comparaciones con dpkg --compare-versions y los dos paquetes de mariadb-server-core desempaquetados en un directorio de trabajo para preguntarles su versión.

El aviso, el registro CVE, las notas de versión y los rastreadores de Ubuntu y Debian van como Revisado (lo explico en cómo pruebo y reviso las guías). El guion con el que MariaDB añade su repositorio lo he leído entero, pero no lo he ejecutado.

El fallo, según el aviso

Según el aviso GHSA-625w-4hgq-qwmr, que MariaDB publicó el 7 de septiembre, la sentencia GRANT PROXY con una cláusula IDENTIFIED de contraseña vacía comprobaba mal los permisos de quien la ejecuta. El resultado: alguien podía poner contraseña a otras cuentas. Lo reportó Kévin Gervot.

El registro CVE-2026-97380 llegó a cve.org el 16 de octubre, con 8,8 en CVSS 3.1 y privilegios requeridos bajos. Su descripción pone la condición: basta un atacante con poco privilegio «que pueda nombrar otra cuenta». En la rama 10.11 afecta de la 10.11.1 a la 10.11.18.

Quién está expuesto

Leído con calma, el aviso no pide una cuenta de administración ni un permiso raro. Pide una cuenta cualquiera dentro de la base de datos y el nombre de otra. Eso describe casi cualquier servidor con más de una aplicación: cada web con su usuario, cada servicio con el suyo.

Que MariaDB escuche solo en local no lo arregla. Limita quién llega a conectarse, pero una aplicación comprometida ya tiene su usuario y su contraseña de base de datos en su configuración. Esto es mi lectura del aviso, no una prueba: no lo he reproducido.

Comprobar qué versión tienes

Tres preguntas, en este orden: qué versión está sirviendo, de qué repositorio viene y si queda por debajo del arreglo. Son lecturas; no cambian nada.

# La version que sirve el proceso, no la del cliente
sudo mariadb -N -e "SELECT VERSION();"

# El paquete instalado y de que repositorio sale
apt-cache policy mariadb-server

# Comparacion valida solo dentro de la rama 10.11
v=$(dpkg-query -W -f='${Version}' mariadb-server)
dpkg --compare-versions "$v" lt 1:10.11.19 && echo "AFECTADA: $v" || echo "10.11.19 o superior: $v"

La comparación solo vale en la rama 10.11. Si tienes una 11.4 o una 11.8 del repositorio de MariaDB, el corte es otro (11.4.13 y 11.8.9), y una 11.4.12 sale «mayor» que la 10.11.19 aunque esté afectada.

Para ver qué cara tiene cada versión, he bajado el mariadb-server-core de los dos sitios y lo he desempaquetado sin instalarlo. El binario dice de dónde viene:

# Desempaquetar sin instalar: no toca dpkg ni el sistema
dpkg-deb -x mariadb-server-core_10.11.14-0ubuntu0.24.04.1_amd64.deb u1014
dpkg-deb -x mariadb-server-core_10.11.19+maria~ubu2404_amd64.deb m1019

u1014/usr/sbin/mariadbd --version
# Ver 10.11.14-MariaDB-0ubuntu0.24.04.1-log for debian-linux-gnu on x86_64 (Ubuntu 24.04)
m1019/usr/sbin/mariadbd --version
# Ver 10.11.19-MariaDB-ubu2404-log for debian-linux-gnu on x86_64 (mariadb.org binary distribution)

Dónde está el arreglo a 20 de octubre

Lo he preguntado a cada fuente sobre las 21:51 UTC. El resumen cabe en una lista:

• Ubuntu 24.04. Según Launchpad, noble-updates ofrece la 1:10.11.14-0ubuntu0.24.04.1, publicada el 20 de enero, y noble-security se queda en la 10.11.13 de USN-7548-1 (2 de junio de 2025). Ningún aviso de Ubuntu cita este CVE y su rastreador no tiene ficha de él.
• Debian. Según su rastreador, bookworm-security (Debian 12) ya sirve la 1:10.11.19-0+deb12u1, aunque todavía la marca vulnerable; trixie (Debian 13) sigue en la 11.8.6, afectada; forky y sid están corregidos con la 11.8.9.
• Repositorio de MariaDB. Su rama 10.11 para noble ofrece la 1:10.11.19+maria~ubu2404.
• Ubuntu Pro, esm-apps. Su índice público de noble-apps-security, fechado el 12 de octubre, tiene 1.162 paquetes para amd64 y ninguno es de mariadb.

Los fallos de MariaDB que entraron en cve.org el 9 de octubre sí tienen ficha en el rastreador de Ubuntu, y para 24.04 pone «needs-triage»: sin revisar todavía. Comparadas con dpkg, las cuatro versiones quedan así:

for v in 1:10.11.14-0ubuntu0.24.04.1 1:10.11.13-0ubuntu0.24.04.1 \
         1:10.11.19+maria~ubu2404 1:10.11.19-0+deb12u1; do
  dpkg --compare-versions "$v" lt 1:10.11.19 && echo "$v AFECTADA" || echo "$v corregida"
done
# 1:10.11.14-0ubuntu0.24.04.1 AFECTADA
# 1:10.11.13-0ubuntu0.24.04.1 AFECTADA
# 1:10.11.19+maria~ubu2404 corregida
# 1:10.11.19-0+deb12u1 corregida

Riesgo

Lo que he leído en ese guion (su versión 2026-09-15), sin ejecutarlo: escribe /etc/apt/sources.list.d/mariadb.sources y crea /etc/apt/preferences.d/mariadb-enterprise.pref con prioridad 1000 para todo lo que venga de dlm.mariadb.com. Se llama «enterprise» aunque instales la versión comunitaria. Es el detalle raro del día.

Salida 1: el repositorio de MariaDB, fijado a 10.11

Es la única que hoy trae la 10.11.19 a un Ubuntu 24.04. Primero la copia, luego el guion con la rama fijada y, antes de instalar, mirar qué candidato ofrece apt:

# Copia completa antes de tocar nada
sudo mariadb-dump --all-databases --single-transaction --routines --events > copia-antes.sql

# El guion oficial: leelo antes de ejecutarlo como root
curl -LsSO https://r.mariadb.com/downloads/mariadb_repo_setup
sudo bash mariadb_repo_setup --mariadb-server-version="mariadb-10.11"

sudo apt update
apt-cache policy mariadb-server   # candidato esperado: 1:10.11.19+maria~ubu2404
sudo apt install mariadb-server mariadb-client

Salida 2: Ubuntu Pro, cuando llegue

Ubuntu Pro es gratis para uso personal en hasta cinco máquinas físicas, según su página, y su servicio esm-apps cubre los paquetes de universe, que es donde vive MariaDB, según su documentación. Hoy no resuelve este fallo: su índice no trae ningún paquete de mariadb para 24.04. Con pro security-status --esm-apps ves qué te cubriría.

Mientras tanto: mira tus cuentas

Si no puedes actualizar hoy, por lo menos sabe quién podría intentarlo. Esta consulta lista las cuentas sin permisos de administración, que son las que el aviso llama de poco privilegio. Solo lee:

# Cuentas sin SUPER, sin GRANT OPTION y sin CREATE USER
sudo mariadb -e "SELECT User, Host FROM mysql.user
  WHERE Super_priv='N' AND Grant_priv='N' AND Create_user_priv='N';"

Las que no use nadie, fuera. Las que queden, con nombres que no se adivinen, que es lo que pide el aviso. Lo primero es cosa mía, no de MariaDB: una cuenta que no existe no se puede usar contra otra.

Comprobación

Después de la salida 1, el proceso tiene que contestar con la versión nueva, y apt tiene que decir que el paquete sale de dlm.mariadb.com:

sudo mariadb -N -e "SELECT VERSION();"
# debe empezar por 10.11.19-MariaDB-ubu2404

apt-cache policy mariadb-server
# Instalados: 1:10.11.19+maria~ubu2404, con dlm.mariadb.com en la tabla de versiones

Vuelta atrás

Quitar el repositorio es borrar los dos ficheros que crea el guion y volver a leer los índices. Los paquetes ya instalados no bajan solos:

# Fuera el repositorio y su prioridad
sudo rm /etc/apt/sources.list.d/mariadb.sources /etc/apt/preferences.d/mariadb-enterprise.pref
sudo apt update

# Si hay que volver a los datos de antes, la copia del principio
sudo mariadb < copia-antes.sql

Volver al paquete de Ubuntu es bajar de versión dentro de la rama. La documentación de MariaDB dice que eso suele ser posible, pero que hay que comprobar la compatibilidad, y que lo más fiable es restaurar una copia completa en una instalación limpia. Por eso la copia va antes de todo.

Qué no he probado

• El fallo en sí. No lo he reproducido ni lo voy a hacer en una entrada: para decidir si actualizar basta con la versión y con saber quién tiene cuenta.
• El guion de MariaDB y la subida a la 10.11.19 en una máquina con datos. Lo de la salida 1 está leído en el guion y en la documentación, no ejecutado.
• Bajar de la 10.11.19 a la 10.11.14 de Ubuntu.
• Otras ramas (11.4, 11.8), Ubuntu 22.04 y ARM. Y el contenido de esm-apps con una suscripción: solo he mirado su índice público.

Es la lección de la guía de OpenSSH 10.6 y de la de las cuatro libcurl: lo que decide cuándo te llega un arreglo no es la gravedad del fallo, sino quién empaqueta lo que corres y en qué estante lo pone.

A mi checklist de Ubuntu recién instalado le falta esa línea: en qué repositorio vive cada servicio que escucha, porque eso dice de qué cola de parches dependes. El resto de guías de Ubuntu y Linux va por ahí.