Debian 13.7 Trixie ya está disponible: point release enfocado 100% en seguridad

septiembre 22, 2026 Alfonso Moreno | Sysadmin Senior 37 Visitas 12 min de lectura

El 12 de septiembre de 2026, el equipo de Debian publicó Debian 13.7 “Trixie”, el séptimo point release de la rama estable. La cifra que más llama la atención es 107 actualizaciones de seguridad sumadas a 106 correcciones de bugs: un balance casi 50/50 que rompe la narrativa típica de los point releases “tranquilos” y refleja el volumen de advisories acumulados durante agosto y septiembre. Si tienes servidores en producción Debian 13, este es el point release que no puedes posponer.

A diferencia de releases anteriores donde las correcciones de seguridad venían mezcladas con bugfixes y mejoras generales, este point release adopta una cadencia deliberada: el equipo de Release de Debian demoró casi dos meses entre 13.6 (julio) y 13.7 (septiembre), cuando el ciclo habitual era de seis a ocho semanas. La razón declarada fue acumulación: querían que 13.7 incluyera un set cohesivo de parches en lugar de dividirlos en dos releases chicos. Para sysadmins, esto significa que el delay se canjeó por cobertura: el upgrade toca más paquetes críticos con un único reinicio.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 2-3 horas para el switch a enforcing.
Requisitos: Root, kernel moderno, 2-4 semanas en permissive antes de enforcing.
Resultado: Sistema con MAC activo, logs en /var/log/audit/audit.log.
Troubleshooting: audit2allow, audit2why, setenforce 0 para emergencias.

Qué trae Debian 13.7: las novedades que importan

El ChangeLog oficial y el announcement del 12 de septiembre detallan los paquetes más relevantes. Estos son los que un sysadmin debe revisar antes de aprobar el upgrade en producción:

Kernel Linux 6.12.107: el instalador de Debian fue reconstruido para incluir el kernel 6.12.107, que trae los parches acumulados del ciclo de agosto-septiembre. Esto incluye mitigaciones para los CVEs del kernel que CISA agregó al catálogo KEV en septiembre (CVE-2026-31431 “Copy Fail”, CVE-2026-53266, CVE-2025-39964). Si tu servidor corre fleets grandes, el cambio de kernel es el evento de mayor impacto en este point release.
glibc con correcciones críticas: se parchearon buffer overflow y underflow en glibc, y se agregó compatibilidad con headers del kernel Linux 7.0. Varios paquetes base fueron reconstruidos contra la nueva glibc, así que vas a ver rebuilds en cadena en tu output de apt full-upgrade.
OpenSSL y Samba: actualizados a las nuevas versiones upstream stable. Samba en particular recibe fixes que afectan a archivos compartidos en redes mixtas Linux/Windows.
QEMU con Secure Boot bypass: se parchearon buffer overflows, use-after-free, out-of-bounds access y un bypass de Secure Boot. Si tu entorno corre VMs con Secure Boot habilitado (recomendado para Windows guests), el upgrade de QEMU es obligatorio antes de seguir deployando workloads.
ImageMagick: colección extensa de security fixes cubriendo buffer overflows, memory leaks, use-after-free, bypasses de policy, denial-of-service y un information disclosure. Si tu servidor procesa imágenes (uploads, thumbnails, conversiones), no actualizarse es asumir el riesgo.
dnsmasq: buffer overflow y out-of-bounds read. Si lo usas como resolver DNS local o DHCP server, este es un parche de prioridad alta.
libvirt: fixes de privilege escalation, information disclosure y otros issues que afectan a hosts de virtualización con múltiples tenants.
Incus: path traversal y access-check insuficientes. Si migraste de LXD a Incus en servidores Debian 13, este point release es relevante.
Perl y Python 3.13: ambos reciben colecciones de security fixes. Python 3.13 también incluye regresiones corregidas que estaban abiertas desde el release inicial de la rama 3.13.
Firefox ESR, Chromium, Flatpak, GIMP, Wireshark: actualizados por seguridad. Chromium en particular suele traer fixes de exploits 0-day que están siendo activamente explotados.
OpenSSH (libraries), PostgreSQL 17, Docker, OpenJDK, WebKitGTK, ZFS: security updates para el stack de runtime y bases de datos. Si corres containers Docker sobre Debian 13, el binario dockerd y containerd se actualizan acá.
tzdata actualizado: incluye cambios recientes para Alberta (Canadá) y Morocco. Si tienes servicios que dependen de conversiones de timezone (logs, scheduling, calendarios), vas a notar el cambio.
audit package con soporte RISC-V 64-bit: si bien Debian 13 ya soportaba riscv64 como arquitectura, el paquete audit ahora tiene soporte oficial para auditoría de eventos en esa arquitectura.
Cinnamon desktop: fix para la descarga y actualización de “spices” (applets, desklets, extensions, themes). Esto era un bug conocido que rompía la experiencia de usuarios de Cinnamon desde 13.6.

Por qué este point release tardó más de lo normal

La cadencia habitual de point releases de Debian stable es bimestral: el histórico desde Bookworm muestra intervalos de 6 a 8 semanas entre releases. Entre 13.6 (julio de 2026) y 13.7 (septiembre de 2026) pasaron casi dos meses. La razón que dio el Release Team fue deliberada: en lugar de partir el set de advisories en dos releases de 50 parches cada uno, eligieron esperar y publicar uno solo de 107. La matemática es simple: dos reinicios vs uno, dos ventanas de cambio vs una.

Para sysadmins esto es un trade-off. Por un lado, una ventana de cambio más larga es más conservadora: tienes más tiempo para testear en staging, planificar el reinicio, y coordinar con equipos que dependen del servicio. Por otro lado, mientras esperas, tu fleet está corriendo con 107 vulnerabilidades conocidas, varias de ellas con exploits funcionales públicos. La decisión de cuándo aplicar 13.7 depende del perfil de riesgo de tu organización: para servidores con datos sensibles o expuestos a internet, no esperar es la respuesta correcta.

Cómo actualizar Debian 13 a 13.7 sin romper nada

El flujo recomendado para servidores en producción Debian 13 Trixie es el siguiente. Lo divido en pasos para que sea fácil de copiar en un playbook de Ansible o ejecutar a mano:

# 1. Backup del estado de paquetes actual
dpkg --get-selections > /root/packages-pre-13.7.list
# 2. Verificar paquetes retenidos (pueden bloquear el upgrade)
apt-mark showhold
# 3. Actualizar la lista de paquetes
sudo apt update
# 4. Upgrade mínimo (solo paquetes existentes, sin instalar nuevos)
sudo apt upgrade -y
# 5. Full upgrade incluyendo posibles cambios de dependencias
sudo apt full-upgrade -y
# 6. Confirmar versión del kernel nuevo instalado
ls /boot/vmlinuz-* | sort | tail -2
# 7. Verificar paquetes en estado inconsistente
dpkg --audit
# 8. Reiniciar si el kernel cambió
sudo systemctl reboot

El truco que casi nadie aplica pero que salva horas de troubleshooting es verificar apt-mark showhold antes de empezar. Si tienes paquetes pineados (kernel custom, drivers propietarios, módulos DKMS), el upgrade se va a “completar” pero el kernel nuevo no se va a activar hasta que resuelvas los holds. En fleets grandes, este check es el primer paso de cualquier playbook de patch management. Otro punto crítico: el paso 5 (apt full-upgrade) puede remover paquetes si las dependencias cambiaron; revisa el output antes de confirmar con -y en sistemas donde no puedes perder paquetes específicos.

Modo “solo security”: cómo limitar el upgrade a parches de seguridad

Si tu organización tiene una política de “no upgrade de features, solo security”, Debian lo soporta nativamente. El mecanismo es unattended-upgrades configurado para apuntar solo al repositorio ${distro_codename}-security:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# Verificar la configuración
cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -i 'security'

Esta configuración hace que el sistema solo instale paquetes marcados como security update automáticamente. Las correcciones de bug no-críticos y los rebuilds por cambios de glibc quedan pausados hasta que un sysadmin los apruebe manualmente. Es el equilibrio correcto para servidores de producción donde cada cambio debe ser justificado. La contra: tu sistema queda detrás del upstream en bugfixes no-seguros, lo que puede causar acumulación de problemas menores con el tiempo.

Cuándo NO actualizar de inmediato

Hay casos donde esperar dos semanas antes de aplicar 13.7 es la decisión correcta:

LXC containers con kernel compartido del host: si tu servidor Debian 13 corre CTs LXC con kernel del host, el cambio de kernel puede romper drivers compilados con DKMS hasta que los vendors actualicen sus paquetes. Espera dos semanas después del release para que Debian publique el primer point release de fixes (13.7.1) y los vendors de DKMS publiquen sus updates.
Clusters Proxmox con Trixie como base para CTs: similar al caso LXC, si usas Debian 13 como template para containers, espera una semana para ver reportes de incompatibilidad en las listas de correo de Proxmox.
Replicación de base de datos cross-distro: si tu DB principal corre sobre Debian 13 y replica con servidores Debian 12 (Bookworm) o Debian 11 (Bullseye), los paquetes postgresql-17 o mariadb-server pueden divergir en versión menor después del upgrade. Verifica que los nodos de tu cluster queden en la misma versión de paquete antes de continuar.
Producción con Windows guests + Secure Boot: aunque el fix de QEMU corrige el bypass de Secure Boot, la nueva versión puede tener regresiones. Testeá en staging antes de promover a producción.

Cómo verificar que el upgrade aplicó correctamente

Después de reiniciar, hay tres comandos que confirman que tu servidor está en 13.7 y que los parches críticos están activos:

# 1. Verificar versión de Debian
cat /etc/debian_version
# Debe devolver 13.7
# 2. Verificar versión del kernel
uname -r
# Debe devolver 6.12.107-*
# 3. Confirmar que glibc fue actualizado
ldd --version | head -1
# 4. Listar paquetes retenidos post-upgrade
apt-mark showhold
# 5. Verificar QEMU actualizado (si usas VMs)
qemu-system-x86_64 --version | head -1

Si cat /etc/debian_version no devuelve 13.7 después del upgrade, lo más probable es que haya un paquete pineado bloqueando la transición. dpkg --audit te va a mostrar cuáles están en estado inconsistente. En ese caso, la solución suele ser apt-mark unhold <paquete> seguido de un nuevo intento de apt full-upgrade.

Debian 13.7 vs Ubuntu 24.04 y RHEL 9: comparativa de cadencia

Para entender el contexto de este point release, vale la pena compararlo con cómo otras distribuciones LTS manejan point releases:

Ubuntu 24.04 LTS: cada cuatro meses publica un point release (24.04.1, 24.04.2, etc.) con kernel y stack actualizado. La cadencia es más predecible pero los point releases incluyen cambios más grandes (a veces incompatibles). Ubuntu también soporta livepatch (Canonical Livepatch) para aplicar kernel patches sin reinicio, disponible con Ubuntu Pro.
RHEL 9.x: Red Hat usa Extended Update Support (EUS) que permite quedarse en una minor version específica por 24-48 meses. Los parches se entregan vía yum update sin point releases discretos. Para sysadmins que necesitan estabilidad extrema, RHEL es más predecible que Debian.
Debian 13: cadencia bimestral con point releases explícitos. La flexibilidad es mayor (backports, security-only mode), pero requiere más disciplina de patch management.

Si tu organización ya tiene un proceso maduro de gestión de cambios, cualquiera de las tres opciones funciona. Si estás eligiendo distro para un nuevo deployment, la decisión suele reducirse a: ¿necesitas soporte comercial con SLA (RHEL)?, ¿prefieres ecosistema Debian con actualizaciones más rápidas (Ubuntu)?, ¿o quieres la flexibilidad pura del modelo Debian sin intermediarios?

¿Y ahora qué?

Si todavía no actualizaste a 13.7, el plan inmediato debería ser:

Esta semana: revisa la lista de paquetes arriba y compara con tu inventory de servicios. Identificá qué servidores son críticos y cuáles pueden esperar.
Próximos 3 días: aplicá el upgrade en staging o en un servidor de desarrollo. Verifica que tus servicios siguen funcionando, especialmente si dependés de versiones específicas de glibc, kernel modules, o QEMU.
Próximas 2 semanas: programá la ventana de mantenimiento para producción. Coordiná con los equipos que dependen de cada servidor.
Después del upgrade: corré los comandos de verificación de la sección anterior en cada host. Si algo falla, restaurá desde el backup de paquetes (/root/packages-pre-13.7.list) y volvé a la versión anterior con apt full-upgrade.

El modelo Debian sigue siendo uno de los más respetados del ecosistema Linux precisamente porque hace este balance entre estabilidad y responsiveness. Point releases como 13.7 son la prueba: 107 parches de seguridad entregados juntos, sin romper compatibilidad, con un único reinicio. Para sysadmins que mantienen fleets Debian en producción, esto es exactamente lo que queremos ver.

Preguntas frecuentes

¿Por qué Debian 13.7 Trixie ya está disponible: point release enfocado 100% en seguridad es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Debian 13.7 Trixie ya está?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Debian 13.7 Trixie ya está?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Debian 13.7 Trixie ya está y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Debian 13.7 Trixie ya está?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.