SUSE corrige cinco vulnerabilidades de disponibilidad en containerd para SLES 12 SP5

SUSE publicó el aviso SUSE-SU-2026:4923-1 para actualizar containerd en SUSE Linux Enterprise Server 12 SP5 y variantes relacionadas. La revisión 2, emitida el 28 de octubre, agrupa cinco vulnerabilidades de disponibilidad; SUSE fija para esos productos el paquete containerd-0:1.7.29-16.119.1. El boletín califica cuatro como medias y una como baja, así que no son cinco fallos idénticos ni una alerta de ejecución remota.

-InfraCrew dice: un runtime no necesita ejecutar el contenedor para convertirse en el cuello de botella; a veces basta con intentar prepararlo.-

El problema puede llegar antes del primer proceso

El caso más claro para los operadores de Kubernetes es CVE-2026-53493, que afecta a la lectura de índices OCI construidos para expandir mucho trabajo. Durante PullImage, containerd puede consumir CPU y memoria mientras recorre el grafo de descriptores, antes de que arranque el contenedor. El aviso upstream indica que el host puede sufrir presión de recursos y retrasos en la creación; aquí no hablamos de código que se ejecute dentro de la imagen.

-InfraCrew dice: “la imagen aún no arrancó” no consuela demasiado al nodo que ya está haciendo horas extra para desempacarla.-

El boletín reúne otros caminos de agotamiento de recursos. CVE-2026-47262 describe una imagen manipulada que puede agotar memoria al crear un contenedor; CVE-2026-95838 fuerza recorridos repetidos al desempaquetar ciertas capas con whiteouts opacos; y CVE-2026-53495 puede bloquear indefinidamente una rutina ligada a ExecSync en el plugin CRI de containerd para Linux. Sus condiciones técnicas difieren, por lo que conviene leer el CVE que corresponda al flujo de cada clúster.

El quinto identificador, CVE-2026-39882, viene de OpenTelemetry-Go, dependencia incluida en el aviso. Sus exportadores OTLP por HTTP podían leer sin límite el cuerpo de respuesta del colector y consumir memoria; la descripción requiere que ese endpoint esté bajo control de un atacante o que la conexión pueda sufrir un intermediario. No equivale a que cualquier nodo con métricas activadas sea explotable desde Internet.

El número upstream no basta para decidir

La actualización publicada por SUSE apunta a SLES 12 SP5, High Performance Computing 12 SP5, SAP Applications 12 SP5 y las variantes Extended Security enumeradas en el aviso. El paquete corregido mantiene como versión base containerd 1.7.29, pero incorpora la revisión de SUSE 16.119.1. Es un backport: el proveedor lleva las correcciones a su rama mantenida sin cambiarla necesariamente al número upstream que aparece en el advisory de containerd.

-InfraCrew dice: comparar solo “1.7.29” con la versión upstream es una forma excelente de declarar vulnerable un paquete ya corregido… o al revés.-

Por eso la comprobación operativa debe partir de la distribución y el paquete instalado, no de una comparación superficial con 1.7.36, que es la versión upstream que corrige CVE-2026-53493 en la rama 1.7. El CSAF de SUSE enumera los productos y builds afectados/corregidos y recomienda instalar el parche por sus métodos habituales de mantenimiento. Confirma primero que el nodo pertenece a una de esas ediciones y que tiene el paquete exacto; no extrapoles este aviso a cualquier instalación de containerd ni a SLES 15.

El riesgo práctico se concentra en la disponibilidad del nodo y el ritmo de los despliegues: un pull atascado o intensivo en recursos puede retrasar un rollout y competir con cargas que ya comparten CPU y memoria. El advisory no afirma que haya explotación activa. Hasta completar la actualización, limitar las imágenes a registros de confianza reduce exposición a artefactos maliciosos, pero no corrige el runtime ni cubre fallos activados por otros caminos.

La respuesta razonable es planificar el parche como cambio de plataforma, validar primero el inventario de nodos SUSE que ejecutan containerd y seguir la ruta de actualización de la edición contratada. Si el clúster exige mantener capacidad durante el cambio, coordina el despliegue con la política de drenado y recuperación de tu entorno. El punto de decisión no es si la imagen parece “solo datos”: el runtime la procesa antes de entregarla al proceso del contenedor.

Diccionario de la Crew

containerd — Runtime que descarga y prepara imágenes y gestiona el ciclo de vida de contenedores.
OCI — Open Container Initiative; especificaciones abiertas para imágenes y runtimes de contenedores.
CRI — Container Runtime Interface; interfaz que permite a Kubernetes comunicarse con un runtime.
Backport — Corrección trasladada a una rama mantenida del proveedor sin adoptar necesariamente la versión upstream más nueva.