Cómo actualizar Jellyfin tras su vulnerabilidad reciente

Si tienes Jellyfin en casa, este no es momento de procrastinar. La forma correcta de responder a una vulnerabilidad no es entrar en pánico, es seguir un plan: identificar versión, confirmar exposición real y actualizar con método según tu plataforma para no romper biblioteca, permisos ni transcodificación.

En homelab casi nunca hay un “Jellyfin estándar”. Uno lo tiene en Docker con cuatro volúmenes, otro en una app de TrueNAS SCALE, otro en Unraid, y otro en un stack de Portainer que ya ni recuerda cuándo tocó por última vez. Por eso muchas guías se quedan cortas, porque mezclan comandos y contextos. Aquí vamos al grano: respuesta operativa por tipo de instalación, sin afirmaciones no verificadas sobre el exploit.

La idea central es simple. Si tu instancia está en una rama afectada, actualizar Jellyfin es la prioridad. Luego validas que todo sigue fino: login, reproducción directa, transcodificación por hardware, permisos de escritura en metadatos y acceso a través del proxy inverso si publicas el servicio fuera de casa.

Qué se sabe de la vulnerabilidad reciente y a quién afecta de verdad

Si Jellyfin corre en una máquina pequeña de bajo consumo, también te puede interesar nuestra guía sobre montar un NAS o servidor casero con un Mini PC Intel N100, porque encaja muy bien como base para este tipo de despliegue.

Cuando aparece una alerta de seguridad en Jellyfin, el ruido en foros y redes suele ser mayor que la señal. Para el usuario doméstico avanzado, lo útil es separar hechos operativos de especulación técnica:

• Lo primero es versión instalada, no titulares.
• Lo segundo es superficie de exposición: solo LAN, LAN + VPN, o abierto a Internet con dominio/proxy.
• Lo tercero es método de despliegue, que define cómo se actualiza y dónde se puede romper algo.

“Si lo uso solo en local, no me afecta” es una objeción razonable, pero incompleta. En muchos homeservers hay túneles, DDNS, apps móviles fuera de casa, reglas antiguas del router o un reverse proxy heredado de otras pruebas. Aunque el riesgo sea menor en LAN cerrada, no desaparece. Si estás en versión vulnerable, compensa actualizar.

También está la postura conservadora: “mi contenedor lleva meses estable, no lo toco”. En seguridad, esa estabilidad es engañosa. La forma de no romper nada no es no actualizar, es actualizar bien: backup, cambio controlado, verificación post-update y rollback preparado por si algo sale mal.

Antes de tocar nada: inventario rápido y copia de seguridad mínima

Este paso te ahorra sustos. No hace falta montar un playbook corporativo, pero sí dejar trazabilidad básica.

1. Anota versión actual de Jellyfin (panel admin o CLI).
2. Anota cómo está desplegado (Docker, Compose, apt, TrueNAS, Unraid, Portainer).
3. Guarda rutas de persistencia: config, cache, base de datos y bibliotecas.
4. Haz backup de esos datos antes de actualizar.
5. Captura una prueba funcional previa: reproducción directa + transcodificación.

Si usas Docker en NAS y quieres estandarizar cómo declaras servicios, esta guía te puede venir bien para limpiar stacks y evitar deuda técnica: Docker en NAS: las 15 mejores aplicaciones imprescindibles.

Cómo comprobar qué versión tienes instalada (sin perder tiempo)

Desde la interfaz web de Jellyfin

Entra como admin y revisa la versión del servidor en la sección de información. Es el método más rápido para confirmar si estás en una rama que debes actualizar.

En Docker o Docker Compose

No te fíes solo del YAML. Comprueba también qué imagen está corriendo realmente, porque a veces el archivo declara una etiqueta y el contenedor ejecuta otra por historial de despliegues.

• Revisa el tag definido en tu servicio.
• Revisa la imagen activa del contenedor en ejecución.
• Comprueba fecha de creación/último redeploy para detectar despliegues antiguos.

En Debian/Ubuntu

Valida versión de paquete instalada y disponibilidad de actualización en los repositorios configurados. Si tu repo de Jellyfin está mal configurado o desactualizado, no verás la versión corregida aunque exista.

En TrueNAS SCALE, Unraid y Portainer

Aquí suele haber desfase entre “hay update en catálogo” y “mi instancia ya está actualizada”. Verifica ambos planos: versión disponible y versión desplegada.

Cómo actualizar Jellyfin si usas Docker

En contenedor suelto, el orden importa. Hazlo así:

1. Backup de volúmenes persistentes de Jellyfin.
2. Descarga la imagen actualizada de tu repositorio habitual.
3. Detén y recrea el contenedor manteniendo puertos, volúmenes, variables y dispositivos.
4. Levanta servicio y revisa logs de arranque en busca de errores de permisos o migración.

Dos fallos clásicos tras actualizar en Docker:

• UID/GID mal alineado y Jellyfin deja de escribir metadata.
• Dispositivo GPU no mapeado y se cae la aceleración por hardware.

Si te pasa, no improvises diez cambios a la vez. Corrige primero permisos, valida, y luego corrige aceleración si sigue fallando.

Cómo actualizar Jellyfin con Docker Compose

Compose te da orden, pero también puede esconder errores de copia y pega entre stacks. La ruta segura:

1. Revisa el docker-compose.yml y confirma imagen/tag.
2. Haz pull de la imagen nueva.
3. Recrea solo el servicio de Jellyfin para no tocar otros contenedores innecesariamente.
4. Comprueba que persisten volúmenes, red y dispositivos de transcodificación.

Si usas etiquetas flotantes tipo latest, plantéate pasar a una política más controlada en servicios críticos. Te quita sorpresas en ventanas de mantenimiento con poco margen.

Cómo actualizar Jellyfin en Debian o Ubuntu

En instalación nativa con paquete .deb, lo más importante es que el repositorio esté bien y el servicio arranque limpio tras actualizar.

1. Actualiza índices de paquetes.
2. Aplica actualización de Jellyfin.
3. Valida estado del servicio.
4. Revisa logs por si hay advertencias nuevas tras la subida de versión.

Ventaja de apt: integración sencilla con el sistema. Inconveniente: más riesgo de arrastrar dependencias o configuraciones del host si lleva mucho tiempo sin mantenimiento. Si tu servidor es multiuso, documenta bien qué has tocado para no cruzar incidencias con otros servicios.

Qué hacer en TrueNAS SCALE, Unraid y Portainer

Estos tres escenarios comparten una idea: el despliegue está “guiado”, pero la responsabilidad final de validar sigue siendo tuya.

TrueNAS SCALE (Apps)

• Comprueba update disponible en la app de Jellyfin.
• Antes de aplicar, revisa dataset, ACL y persistencia.
• Tras actualizar, valida biblioteca, escritura de metadatos y reproducción.

Si cambian permisos en datasets, Jellyfin puede arrancar pero quedar “cojo” al escanear. Es el típico fallo silencioso que se detecta tarde.

Unraid (Docker Templates)

• Aplica update desde el gestor de contenedores.
• Confirma que rutas de template siguen idénticas.
• Verifica GPU/iGPU asignada si usas transcodificación.

En Unraid, un cambio pequeño en template puede desmontarte la ruta de caché o transcode temporal. Revisa con calma antes de dar por cerrado el mantenimiento.

Portainer (Stacks/Containers)

• Actualiza imagen del servicio Jellyfin.
• Re-deploy del stack conservando la definición declarativa.
• Consulta logs justo después del arranque para cazar errores tempranos.

Portainer facilita mucho operar, pero precisamente por eso se tiende a tocar en caliente. Mejor una ventana corta de mantenimiento y checklist cerrada.

Resumen por plataforma (para decidir rápido)

Checklist post-actualización: lo que realmente importa

Dar por bueno el update porque “abre el panel” es quedarse a medias. En Jellyfin hay que probar ruta real de uso:

• Login y navegación en web sin errores visibles.
• Reproducción directa de un archivo típico de tu biblioteca.
• Reproducción con transcodificación (si la usas).
• Hardware acceleration detectada y activa como antes.
• Permisos de lectura en medios y escritura en config/cache.
• Biblioteca con escaneo normal, posters y metadatos correctos.
• Reverse proxy y TLS funcionales si publicas fuera de casa.
• Logs limpios de errores recurrentes tras 10-15 minutos.

Si algo falla, prioriza así: primero acceso, luego reproducción, luego aceleración, luego estética de metadatos. El orden evita dedicar una hora a posters cuando realmente tienes un problema de permisos de base.

Objeciones típicas y respuesta práctica

“Solo lo uso en local, no me afecta tanto”

Puede que el riesgo sea menor, sí. Aun así, si estás en rama afectada, actualizar sigue siendo la recomendación sensata. Hoy es LAN, mañana habilitas acceso remoto y se te olvida endurecer superficie.

“Mi contenedor va perfecto, prefiero no tocar nada”

Entiendo el miedo a romper. Pero “funciona” no significa “está protegido”. La solución es procedimiento: backup, update controlado y validación. En la práctica, suele ser una intervención corta si ya tienes los volúmenes bien montados.

“Cada guía dice una cosa distinta”

Porque mezclan plataformas. Tu regla debe ser: una sola guía por método de despliegue, sin cruzar comandos de apt con Docker ni con catálogos de NAS.

Recomendación por perfil de usuario NAS

Perfil 1, usuario doméstico en Docker/Compose: actualiza hoy mismo en ventana corta y valida transcodificación. Es el caso más común y el más fácil de cerrar bien en menos de una hora.

Perfil 2, servidor en Debian/Ubuntu: verifica repositorio oficial, actualiza paquete y confirma salud del servicio. Si el host corre más cosas, documenta cambios para no generar incidencias cruzadas.

Perfil 3, TrueNAS/Unraid/Portainer: aplica update desde tu plataforma, pero no des por hecho que todo queda igual. Revisa permisos, rutas y dispositivos tras el redeploy.

Si estás montando o renovando nodo multimedia, un mini PC con Intel N100 sigue siendo una base muy razonable por consumo y Quick Sync en escenarios de transcodificación ligera: ver mini PC N100 en Amazon. Para bibliotecas grandes, mover metadatos y cache a SSD también mejora bastante la respuesta del sistema: ver SSD SATA 1TB en Amazon.

Cierre: qué haría hoy en un homelab real

Mi secuencia sería esta: comprobar versión, confirmar exposición, backup rápido de persistencia, actualizar según plataforma y pasar checklist completo de reproducción y logs. Si todo está correcto, cierro ventana de mantenimiento y documento versión final. Si hay fallo, rollback limpio y análisis por capas, sin tocar cinco cosas a la vez.

El objetivo no es tener el “stack perfecto”, es reducir riesgo de forma pragmática y mantener Jellyfin estable para el uso diario. En seguridad doméstica, la diferencia la marca la disciplina operativa, no el dramatismo.

Precios actualizados a abril 2026. Pueden variar. Este artículo contiene enlaces de afiliado – si compras a través de ellos, nos ayudas a mantener el blog sin coste adicional para ti.