Cómo saber si tu Linux necesita una actualización urgente: kernel, paquetes, firmware y vulnerabilidades críticas

No todas las actualizaciones de Linux tienen la misma urgencia. Algunas corrigen errores menores; otras cierran vulnerabilidades críticas en el kernel, OpenSSH, OpenSSL, sudo, systemd, navegadores, firmware, controladores, servicios web o bibliotecas usadas por aplicaciones expuestas a Internet.

Saber cuándo actualizar de inmediato puede evitar intrusiones, escalamiento de privilegios, robo de datos, ransomware, caída de servicios o explotación remota. La clave es revisar cuatro frentes: kernel, paquetes instalados, firmware y vulnerabilidades críticas o explotadas activamente. CISA mantiene el catálogo KEV como fuente de vulnerabilidades explotadas en el mundo real, mientras NVD y CVSS ayudan a entender severidad técnica, y EPSS estima probabilidad de explotación en los próximos 30 días.

1. Señales claras de que debes actualizar ahora

La primera señal es simple: hay parches de seguridad disponibles para componentes críticos. En Ubuntu, los avisos USN se publican cuando se corrige un problema de seguridad en un paquete oficial; en Debian, el Security Tracker permite consultar CVE, paquetes afectados, versiones corregidas y avisos DSA; en Red Hat, los RHSA documentan fallos de seguridad corregidos y DNF permite listar actualizaciones de seguridad pendientes.

2. Revisar la versión del sistema y del kernel

Antes de decidir, identifica qué distribución, versión y kernel estás usando. Kernel.org recuerda que, salvo que hayas descargado y compilado tu propio kernel desde kernel.org, normalmente ejecutas un kernel proporcionado por tu distribución; por eso, en servidores empresariales es mejor seguir los canales oficiales de Debian, Ubuntu, Red Hat, SUSE, Fedora, AlmaLinux, Rocky o la distribución usada.

cat /etc/os-release
uname -a
uname -r
hostnamectl
uptime -p

Una alerta importante es usar un kernel o una versión de distribución fuera de soporte. Kernel.org publica ramas estables y longterm, y también marca versiones EOL cuando ya no reciben mantenimiento. Las versiones EOL no deben usarse en producción porque dejan de recibir correcciones normales de seguridad y estabilidad.

3. Ver actualizaciones pendientes en Debian y Ubuntu

En Debian y Ubuntu, el flujo básico empieza con actualizar metadatos y listar paquetes actualizables. La documentación de Debian muestra comandos como apt update, apt upgrade y apt list --upgradable dentro de sus herramientas de gestión de paquetes.

sudo apt update

# Ver paquetes con actualización disponible

apt list --upgradable

# Simular actualización antes de ejecutar

sudo apt -s upgrade

# Aplicar actualizaciones normales

sudo apt upgrade

# Aplicar cambios que pueden instalar o retirar dependencias

sudo apt full-upgrade

Si aparecen paquetes como linux-image, linux-headers, openssh-server, openssl, sudo, systemd, glibc, curl, nginx, apache2, php, postgresql, mysql o containerd, revisa con más cuidado: pueden afectar seguridad, red, autenticación, cifrado, contenedores o servicios expuestos.

4. Ver actualizaciones de seguridad en RHEL, Rocky, AlmaLinux y Fedora

En distribuciones basadas en RHEL, DNF puede listar actualizaciones de seguridad y aplicar parches relacionados. La documentación de Red Hat indica comandos como dnf updateinfo list updates security para mostrar actualizaciones de seguridad disponibles, y explica que las RHSA documentan fallos de seguridad corregidos en productos Red Hat.

# Ver actualizaciones disponibles
sudo dnf check-update || true

# Ver actualizaciones de seguridad

sudo dnf updateinfo list updates security

# Ver detalle de avisos de seguridad

sudo dnf updateinfo info --security

# Aplicar solo actualizaciones de seguridad

sudo dnf upgrade --security

# Actualización completa

sudo dnf upgrade

Después de actualizar, revisa si hay procesos usando bibliotecas antiguas o si el sistema requiere reinicio. En entornos RHEL, herramientas como needs-restarting ayudan a identificar procesos o reinicios necesarios después de actualizar paquetes.

5. Ver parches en openSUSE y SUSE

En openSUSE y SUSE, zypper permite consultar parches aplicables y filtrar por categoría de seguridad. La documentación de zypper describe comandos que muestran el conteo de parches aplicables y cuántos pertenecen a la categoría de seguridad.

sudo zypper refresh

# Listar parches pendientes

zypper list-patches

# Listar parches de seguridad

zypper list-patches --category security

# Aplicar parches

sudo zypper patch

# Aplicar parches de seguridad

sudo zypper patch --category security

6. Ver actualizaciones en Arch Linux sin caer en actualizaciones parciales

En Arch Linux y derivadas, la recomendación es mantener actualizaciones completas y evitar actualizaciones parciales. ArchWiki advierte contra refrescar la base de datos de paquetes sin actualizar el sistema y recomienda leer noticias cuando una actualización requiere intervención manual.

# Ver actualizaciones de forma segura con pacman-contrib
checkupdates

# Actualización completa del sistema

sudo pacman -Syu

# Ver paquetes huérfanos después de actualizar

pacman -Qtdq

Si usas AUR, revisa también esos paquetes, porque muchas herramientas externas no se actualizan con el mismo flujo de paquetes oficiales. Una actualización urgente puede estar en una dependencia de usuario, no solo en el repositorio principal.

7. Saber si el kernel necesita actualización urgente

El kernel merece atención especial porque controla memoria, red, procesos, controladores, sistemas de archivos, contenedores y aislamiento. Linux kernel ya es CVE Numbering Authority para vulnerabilidades del kernel listadas en kernel.org, excluyendo versiones EOL, lo que refuerza la importancia de seguir ramas soportadas.

# Kernel en ejecución
uname -r

# Debian / Ubuntu: paquetes de kernel instalados

dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'

# RHEL / Rocky / AlmaLinux

rpm -q kernel kernel-core 2>/dev/null

# Ver si hay kernels nuevos pendientes

apt list --upgradable 2>/dev/null | grep -E 'linux-image|linux-generic|linux-headers' || true
dnf updateinfo list updates security 2>/dev/null | grep -i kernel || true

Una actualización de kernel suele requerir reinicio para que el sistema arranque con el kernel nuevo. Ubuntu Livepatch puede cubrir muchas vulnerabilidades importantes del kernel sin reiniciar, pero la documentación de Canonical aclara que livepatching no sustituye una actualización de kernel a una versión nueva cuando eso es necesario; en ese caso se requiere actualizar el paquete del kernel y reiniciar.

8. Revisar si el sistema necesita reinicio

Una actualización puede estar instalada, pero no aplicada completamente. Esto ocurre cuando procesos siguen usando bibliotecas antiguas o cuando el kernel nuevo todavía no está en ejecución. Ubuntu documenta que puede comprobarse manualmente si existe /run/reboot-required; si existe, el sistema necesita reinicio para terminar la actualización.

# Debian / Ubuntu
if [ -f /run/reboot-required ]; then
  echo "Reinicio requerido"
  cat /run/reboot-required.pkgs 2>/dev/null || true
else
  echo "No hay reinicio requerido por este indicador"
fi

# Ver kernel actual

uname -r

También revisa servicios que deben reiniciarse después de una actualización. needrestart verifica qué demonios necesitan reinicio después de actualizaciones de bibliotecas, y checkrestart puede usarse como herramienta de auditoría para identificar procesos que siguen usando archivos antiguos.

# Debian / Ubuntu
sudo needrestart

# Alternativa con debian-goodies

sudo checkrestart

# RHEL / Rocky / AlmaLinux

sudo needs-restarting -r 2>/dev/null || true

9. Revisar firmware con fwupd y LVFS

El firmware también puede necesitar actualización urgente: BIOS/UEFI, controladoras, docks, SSD, tarjetas de red, dispositivos Thunderbolt, placas base y otros componentes. LVFS explica que los proveedores suben firmware redistribuible y que fwupd permite instalar actualizaciones de firmware en Linux de forma segura usando metadatos específicos.

# Instalar fwupd si no está disponible
sudo apt install fwupd
# o
sudo dnf install fwupd

# Actualizar metadatos

sudo fwupdmgr refresh --force

# Ver dispositivos reconocidos

fwupdmgr get-devices

# Ver firmware disponible

fwupdmgr get-updates

# Aplicar actualizaciones

sudo fwupdmgr update

# Ver historial

fwupdmgr get-history

El repositorio de fwupd indica que el proyecto se configura por defecto para descargar firmware desde Linux Vendor Firmware Service. En servidores, portátiles corporativos y estaciones críticas, conviene revisar firmware en ventanas controladas, con energía estable, respaldo y notas del fabricante.

10. Priorizar CVE: CVSS, EPSS y CISA KEV

No basta ver “hay 120 actualizaciones”. Debes priorizar. CVSS ayuda a medir severidad técnica; EPSS estima probabilidad de explotación observada en los próximos 30 días; CISA KEV identifica vulnerabilidades ya explotadas en el mundo real. Una actualización es urgente cuando combina alta severidad, explotación real, exposición a Internet y activo crítico.

URGENTE = (
  CVE en CISA KEV
  OR CVSS crítico + servicio expuesto
  OR EPSS alto + activo crítico
  OR parche de kernel con escalamiento de privilegios
  OR vulnerabilidad remota sin autenticación
  OR firmware corrige fallo de seguridad crítico
)

11. Revisar si un paquete concreto está afectado por una CVE

Cuando recibes una alerta de CVE, no asumas automáticamente que todos tus servidores están afectados. Revisa paquete, versión instalada, distribución, backport de seguridad y versión corregida. Debian Security Tracker permite buscar por CVE, paquete o aviso; su información se deriva de DSAs, CVE, NVD y reportes del sistema de bugs de Debian.

# Debian / Ubuntu
dpkg -l | grep -E 'openssl|openssh|sudo|nginx|apache2|linux-image'
apt policy openssl openssh-server sudo nginx apache2

# RHEL / Rocky / AlmaLinux

rpm -qa | grep -E 'openssl|openssh|sudo|nginx|httpd|kernel'
dnf info openssl openssh-server sudo nginx httpd kernel-core

# Arch

pacman -Q | grep -E 'openssl|openssh|sudo|nginx|linux'

Muchos proveedores aplican backports: mantienen una versión aparente antigua, pero incorporan el parche de seguridad. Por eso, la comparación correcta debe hacerse contra los avisos de la distribución, no solo contra el número de versión upstream.

12. Detectar servicios expuestos que aumentan la urgencia

Una CVE en un paquete instalado no tiene el mismo riesgo si el servicio está apagado, aislado en red interna o expuesto públicamente. Antes de priorizar, revisa puertos abiertos, servicios activos y reglas de firewall.

# Servicios activos
systemctl --type=service --state=running --no-pager

# Puertos escuchando

sudo ss -tulpen

# Firewall

sudo nft list ruleset 2>/dev/null | less
sudo firewall-cmd --list-all 2>/dev/null || true
sudo ufw status verbose 2>/dev/null || true

Si el paquete vulnerable corresponde a un servicio que escucha en Internet, la actualización se vuelve prioritaria. Ejemplos típicos: OpenSSH, servidores web, VPN, paneles de administración, correo, DNS, bases de datos expuestas por error, Kubernetes API, Docker API o aplicaciones PHP/Java/Python publicadas.

13. Revisar contenedores e imágenes

Actualizar el host no corrige automáticamente todas las vulnerabilidades dentro de contenedores. Una imagen Docker puede tener bibliotecas vulnerables aunque el servidor anfitrión esté actualizado. Por eso, además de actualizar Linux, revisa imágenes base, dependencias, runtimes y paquetes incluidos en contenedores.

docker ps
docker images

# Revisar fecha e imagen base usada

docker inspect nombre_contenedor | less

# Reconstruir imágenes con base actualizada

docker compose pull
docker compose build --pull
docker compose up -d

En entornos empresariales, la revisión de vulnerabilidades debe incluir host, contenedores, dependencias de aplicación y firmware. Un Linux “actualizado” puede seguir en riesgo si ejecuta una imagen antigua con OpenSSL, glibc, Java, Node.js o Python vulnerables.

14. Evaluar urgencia por tipo de vulnerabilidad

No todas las vulnerabilidades requieren la misma respuesta. Una ejecución remota sin autenticación sobre un servicio público exige respuesta inmediata. Una vulnerabilidad local que requiere cuenta válida puede seguir siendo grave en servidores multiusuario o entornos compartidos, pero su tratamiento depende del contexto.

15. Comando rápido: diagnóstico de urgencia en 2 minutos

Este bloque no reemplaza una gestión formal de vulnerabilidades, pero ayuda a tener una fotografía rápida del servidor.

echo "== SISTEMA =="
cat /etc/os-release | grep -E 'PRETTY_NAME|VERSION='
echo "Kernel: $(uname -r)"
echo "Uptime: $(uptime -p)"

echo
echo "== REINICIO =="
[ -f /run/reboot-required ] && echo "Reinicio requerido" || echo "Sin indicador /run/reboot-required"
cat /run/reboot-required.pkgs 2>/dev/null || true

echo
echo "== PAQUETES APT =="
if command -v apt >/dev/null 2>&1; then
sudo apt update >/dev/null
apt list --upgradable 2>/dev/null | sed -n '1,30p'
fi

echo
echo "== PAQUETES DNF =="
if command -v dnf >/dev/null 2>&1; then
sudo dnf updateinfo list updates security || true
fi

echo
echo "== PUERTOS ABIERTOS =="
sudo ss -tulpen | sed -n '1,30p'

echo
echo "== FIRMWARE =="
if command -v fwupdmgr >/dev/null 2>&1; then
fwupdmgr get-updates || true
fi

16. Cuándo actualizar inmediatamente y cuándo programar

La actualización urgente debe equilibrar seguridad y disponibilidad. En producción, no se debe actuar a ciegas, pero tampoco se debe esperar semanas ante una vulnerabilidad explotada. NIST SP 800-40 Rev. 4 plantea la gestión de parches como mantenimiento preventivo y reducción de riesgo, no como reacción improvisada.

17. Mitigar cuando no puedes actualizar todavía

A veces no puedes aplicar el parche de inmediato porque el sistema es crítico, el proveedor no liberó actualización, el cambio requiere pruebas o el reinicio afectaría operación. En ese caso, la mitigación debe ser temporal, documentada y con fecha de cierre.

18. Checklist de actualización urgente

19. Errores comunes

20. Preguntas clave

Recomendamos

En resumen

Tu Linux necesita una actualización urgente cuando existe riesgo real y cercano: CVE explotada, parche crítico del kernel, servicio público vulnerable, firmware sensible, reinicio pendiente o sistema fuera de soporte. La decisión no debe basarse solo en el número de paquetes pendientes, sino en el impacto, la exposición, la criticidad del activo y la evidencia de explotación.

La administración profesional combina comandos locales, avisos oficiales, CVSS, EPSS, CISA KEV, revisión de servicios expuestos, control de firmware, backup, ventana de mantenimiento y verificación posterior. Actualizar rápido es importante; actualizar con método es lo que evita convertir un parche urgente en una caída innecesaria.