릴리즈

containerd v2.1.9은 CVE 5건을 수정한 보안 패치 릴리스입니다. containerd 2.1.x를 운영 중이라면 즉시 업그레이드 계획을 세우세요.

• securityCVE 5건 패치 — containerd 2.1.x 즉시 업그레이드

  이번 릴리스에서 containerd 자체 CVE 5건을 수정했습니다. 어드바이저리가 아직 공개되지 않아 심각도를 확인할 수 없지만, 패치 릴리스 하나에 CVE가 5건이면 빠르게 대응해야 합니다. Kubernetes 노드 이미지, 관리형 노드 그룹, bare-metal CRI 환경 모두 이번 주 안에 업그레이드 일정을 잡으세요.

• securityrunc v1.3.6 확인 — containerd 업그레이드만으로는 부족할 수 있음

  이번 릴리스에 포함된 runc 바이너리는 v1.3.6입니다. runc를 containerd와 별도로 관리하는 환경(Kubernetes 노드에서 흔한 구성)이라면, containerd를 올려도 runc는 그대로입니다. 별도 설치된 runc가 v1.3.6 이상인지 직접 확인하세요.

• enhancement체크포인트 복원 로직 강화 — CRIU 사용 환경은 복원 동작 검증 필요

  CRI 체크포인트/복원과 관련해 세 가지가 바뀌었습니다. 예상치 못한 아카이브 내용을 거부하고, 복원된 체크포인트의 재태깅을 건너뛰며, CDI 어노테이션을 필터링합니다. CRIU 기반 라이브 마이그레이션을 쓰는 팀은 업그레이드 후 복원 워크플로우를 반드시 테스트해 기존 동작에 영향이 없는지 확인하세요.

containerd 1.7.33은 containerd 자체 CVE 2건과 go-jose CVE 1건을 패치하고, runc를 v1.3.6으로, Go 런타임을 업데이트했습니다. 업그레이드 이유는 보안 패치가 전부입니다.

• securityCVE 3건 수정 — 1.7.33으로 바로 업그레이드

  containerd 본체에서 CVE-2026-53488과 CVE-2026-47262, go-jose에서 CVE-2026-34986이 수정됐습니다. 세부 내용은 GitHub 보안 어드바이저리를 확인하세요. containerd 1.7.x를 운영 중이라면 이전 패치 버전에 머물 이유가 없으므로 즉시 업그레이드하는 것이 좋습니다.

• security이미지 config에서 예약 레이블 전파 차단

  이미지 config에 포함된 reserved label이 외부로 전파되지 않도록 수정됐습니다. 레이블 기반 접근 제어나 정책 적용을 운영 중이라면 업그레이드 후 동작을 검증하고, CVE-2026-47262 어드바이저리에서 영향 범위를 확인하세요.

• enhancementrunc v1.3.6 반영 확인 필요

  containerd에 번들된 runc가 v1.3.6으로 올라갔습니다. runc를 별도로 관리하는 환경이라면 설치된 버전이 v1.3.6 이상인지 확인해 containerd와 버전을 맞추세요.

containerd v2.0.10은 CVE-2026-53488, CVE-2026-47262 두 건의 취약점을 수정하고 runc를 v1.3.6으로 올렸습니다. 2.0.x를 운영 중이라면 즉시 업그레이드하세요.

• securityCVE 두 건 수정 — 즉시 업그레이드

  CVE-2026-53488과 CVE-2026-47262가 이번 릴리스에서 함께 수정됐습니다. 각 어드바이저리(GHSA-xhf5-7wjv-pqxp, GHSA-jpcc-p29g-p8mq)에서 영향 범위를 확인하세요. containerd 2.0.x를 운영 중인 노드는 노출 여부를 따지기 전에 v2.0.10으로 먼저 올리는 것이 맞습니다. 런타임 레벨 취약점이라 영향 범위가 넓을 수 있습니다.

• securityrunc v1.3.6으로 업데이트

  containerd에 포함된 runc 바이너리가 v1.3.6으로 올라갔습니다. v1.3.4, v1.3.5의 수정 사항도 포함됩니다. runc를 패키지 매니저 등으로 별도 관리하는 경우, containerd 업그레이드와 별개로 runc 버전도 v1.3.6에 맞춰 확인하세요.

• enhancement이미지 config의 reserved 레이블 전파 차단

  컨테이너 실행 시 containerd의 reserved 레이블이 이미지 config에서 더 이상 전파되지 않습니다. 실행 중인 컨테이너의 레이블을 읽는 자동화 도구를 운영 중이라면, 업그레이드 후 동작을 확인하세요. 조용한 동작 변경이라 레이블 기반 로직에 영향을 줄 수 있습니다.

containerd 2.3.2는 CVE 5건을 포함한 보안 패치와 런타임 안정성 수정이 핵심입니다. 2.3.x를 운영 중이라면 즉시 업그레이드하세요.

• securityCVE 5건 패치 — 2.3.x 노드 즉시 업그레이드 필요

  이번 릴리스에서 containerd 코어 관련 CVE가 한 번에 5건 패치됐습니다. 어드바이저리가 아직 전부 공개되지 않았지만, 한 패치 릴리스에 5건이 몰린 만큼 노출 범위가 작지 않습니다. 2.3.x를 운영 중인 팀은 다음 정기 점검을 기다리지 말고 containerd 바이너리를 2.3.2로, runc는 v1.4.3으로 함께 업그레이드하세요. 노드 프로비저닝 파이프라인도 버전을 맞춰 업데이트하세요.

• enhancement이미지 풀 시 일시적 네트워크 오류 재시도 지원

  마지막으로 설정된 레지스트리 호스트에서 일시적 네트워크 오류가 발생할 때 자동으로 재시도하도록 resolver가 수정됐습니다. 별도 설정 변경 없이 적용되며, 네트워크 불안정 환경에서 간헐적 이미지 풀 실패를 겪었다면 이 패치로 개선될 수 있습니다.

• enhancement느린 컨테이너 생성 시 RPC 타임아웃 실패 수정

  runc shim이 runc create 호출 전체를 서비스 락을 잡은 채로 실행하면서, 컨테이너 생성이 느릴 때 동시 RPC 타임아웃이 발생해 시작에 실패하는 문제가 있었습니다. 부하가 걸린 상태에서 컨테이너가 시작되지 않거나 멈추는 증상을 겪었다면 이번 패치로 해결될 가능성이 높습니다.

containerd 2.2.5는 5개의 CVE를 수정하고 runc를 v1.3.6, Go를 1.26.4/1.25.11로 올린 보안 중심 패치 릴리스입니다. 2.2.x를 운영 중이라면 빠른 업그레이드가 필요합니다.

• securityCVE 5건 패치 — 2.2.x 노드 즉시 업그레이드 필요

  이번 릴리스는 containerd 자체에서 발견된 CVE 5건을 수정합니다. 각 취약점 상세 내용은 공개된 보안 어드바이저리를 참고하세요. 2.2.x를 운영 중인 클러스터는 2.2.5로 업그레이드해야 합니다. runc도 v1.3.6으로 올라갔으므로, 배포 전에 runc 릴리스 노트도 함께 확인하세요.

• securitygolang.org/x/crypto 등 x/ 라이브러리 대폭 업데이트 — 커스텀 플러그인 빌드 시 재빌드 필요

  golang.org/x/crypto가 v0.45.0에서 v0.53.0으로, golang.org/x/net이 v0.47.0에서 v0.55.0으로 올라갔습니다. containerd를 벤더링하거나 라이브러리를 직접 참조해 플러그인을 빌드하고 있다면, 의존성을 다시 vendor하고 재빌드하세요. crypto 범위 내에는 여러 보안 수정이 포함되어 있습니다.

• enhancement체크포인트/복원 사용 시 이번 릴리스 우선 적용 권장

  CRI 체크포인트 복원 관련 버그 3건이 한꺼번에 수정됐습니다. CDI 어노테이션이 복원 시 제대로 필터링되고, 복원된 체크포인트가 잘못 재태깅되는 문제가 없어졌으며, 비정상적인 아카이브 콘텐츠에 대한 처리도 강화됐습니다. 프로덕션에서 컨테이너 체크포인트/복원을 쓰고 있다면 업그레이드 우선순위를 높이세요.

CVE-2026-46680 보안 패치와 함께 샌드박스 서비스 버그, AppArmor 호환성, OCI USER 스펙 처리 문제를 수정한 패치 릴리스입니다.

• securityCVE-2026-46680 즉시 패치 적용

  이번 릴리스의 핵심은 CVE-2026-46680 수정입니다. GHSA 어드바이저리에서 공격 범위와 심각도를 먼저 확인하세요. containerd 2.1.x를 운영 중이라면 이번 업그레이드를 최우선 배포 작업으로 처리해야 합니다. 의존성 변경이 없어 업그레이드 절차는 단순합니다.

• breakingOCI USER 범위 초과 값이 이제 명시적 오류로 실패 — 스펙 사전 점검 필요

  기존에는 OCI 스펙의 USER 값이 유효 UID/GID 범위를 벗어나도 사용자명/그룹 조회로 암묵적으로 처리되어 설정 오류가 숨겨졌습니다. 이제는 명시적 에러가 반환되므로, 숫자형 USER 값을 사용하는 컨테이너가 있다면 업그레이드 후 갑자기 실패할 수 있습니다. 프로덕션 배포 전에 컨테이너 스펙을 반드시 점검하세요.

• enhancementAppArmor 3.0 미만 환경이나 샌드박스 런타임 사용자는 업그레이드 적극 권장

  AppArmor abi 조건부 설정 수정은 구버전 AppArmor(예: Ubuntu 20.04의 2.x)를 사용하는 환경에서 실질적인 차단 요인이었습니다. 샌드박스 서비스 버그도 이벤트 기반 워크플로와 샌드박스 생성 설정에 직접 영향을 줍니다. Kata Containers 등 샌드박스 기반 런타임을 쓰고 있다면 이번 수정이 특히 중요합니다.

containerd v2.2.4는 두 건의 CVE 패치와 함께 overlay, sandbox, AppArmor, seccomp 관련 버그를 수정한 보안 중심 패치 릴리스입니다.

• securityCVE 두 건 포함 — 즉시 v2.2.4로 업데이트

  containerd 코어(CVE-2026-46680)와 go-jose 의존성(CVE-2026-34986) 각각 하나씩, 총 두 건의 CVE가 수정됐습니다. 프로덕션 배포 모두에 해당하는 내용이므로 정기 점검 일정을 기다릴 이유가 없습니다. 긴급 패치 프로세스로 처리하세요. Kubernetes 노드에서 containerd를 런타임으로 사용 중이라면 오케스트레이터 종류와 무관하게 모두 영향을 받습니다.

• securityAF_ALG 기본 차단 추가 — 커스텀 워크로드 사전 검토 필요

  기본 seccomp 프로파일이 AF_ALG(소켓 기반 커널 암호화 API)를 차단하도록 강화됐습니다. 일반적인 워크로드에는 영향이 없지만, 암호화 처리나 하드웨어 오프로드 목적으로 AF_ALG 소켓을 직접 사용하는 컨테이너는 시스템 콜 거부가 발생할 수 있습니다. 업그레이드 전에 커스텀 또는 관대한 seccomp 프로파일을 사용하는 워크로드를 점검해두세요.

• enhancementUserNS + overlay 환경의 레이어 추출 오류 수정

  사용자 네임스페이스(rootless 컨테이너 포함)에서 overlay 스냅샷터를 쓸 때 'rebase' 기능이 레이어 추출 실패를 일으키던 문제가 해결됐습니다. UserNS 컨텍스트에서 자동으로 비활성화되므로 별도 설정 변경 없이 업그레이드만 하면 됩니다. 업데이트 후 rootless 워크로드의 마운트 정상 동작 여부를 확인하는 정도면 충분합니다.

containerd 2.0.9는 CVE-2026-46680 보안 취약점 패치와 tar 추출 시 TOCTOU 경쟁 조건 수정, containerd 재시작 시 컨테이너 종료 이벤트 유실 문제 등 여러 버그를 수정했습니다.

• securityCVE-2026-46680 즉시 패치

  CVE-2026-46680 보안 취약점이 이번 릴리스에서 수정됐습니다. containerd 2.0.x를 사용 중이라면 즉시 2.0.9로 업그레이드하세요. GHSA 보안 권고문에서 영향받는 구성과 심각도를 확인한 뒤 유지보수 일정을 잡되, 가능한 한 빨리 적용하는 것을 권장합니다.

• securitytar 추출 TOCTOU 수정 — 외부 이미지 사용 환경은 특히 주목

  tar 추출 중 발생하는 TOCTOU 경쟁 조건은 악의적으로 조작된 이미지 레이어로 경로 탈출을 시도하는 데 악용될 수 있습니다. 신뢰할 수 없는 서드파티 이미지를 pull하는 환경이라면 업그레이드와 함께 이미지 소스 제한 정책도 함께 점검하세요.

• breakingAppArmor 3.0 미만 환경은 업그레이드 후 프로파일 동작 확인 필요

  AppArmor ABI 필드가 이제 조건부로 설정됩니다. AppArmor 3.0 미만 시스템에서는 기존에 호환되지 않는 ABI가 프로파일에 삽입되던 문제가 해결되는 것이지만, 커스텀 프로파일로 이 문제를 우회해왔다면 업그레이드 후 AppArmor 동작을 반드시 검증하세요.

• enhancement컨테이너 종료 이벤트 유실 수정 — 파드 교체가 잦은 환경에서 효과적

  containerd 재시작 후 컨테이너가 예상치 못한 상태로 멈추는 현상, 특히 파드가 빠르게 순환되는 Kubernetes 환경에서 자주 발생했다면 이 수정이 근본 원인을 해결합니다. 별도 설정 변경 없이 업그레이드만으로 적용됩니다.

containerd 1.7.32는 CVE-2026-46680 보안 패치를 포함하며, 기본 seccomp 프로파일에서 AF_ALG 소켓을 차단하고 OCI spec USER 처리 버그도 수정했습니다.

• securityCVE-2026-46680 즉시 패치 — 1.7.32로 업그레이드

  이번 릴리스의 핵심은 CVE-2026-46680입니다. containerd 보안 어드바이저리(GHSA-fqw6-gf59-qr4w)에서 심각도와 공격 범위를 먼저 확인하되, 1.7.x를 운영 중이라면 패치를 미루지 마세요. 유지보수 창을 조정하더라도 업그레이드 자체는 최우선으로 계획해야 합니다.

• security기본 seccomp에서 AF_ALG 차단 — 커스텀 워크로드 사전 점검 필요

  기본 seccomp 정책이 이제 AF_ALG(커널 암호화) 소켓 패밀리를 차단합니다. 하드웨어 암호화 오프로딩이나 HSM 연동 워크로드는 업그레이드 후 시작에 실패할 수 있습니다. 일반 컨테이너에는 영향이 없지만, 특수한 암호화 기능을 쓰는 컨테이너라면 기본값을 완화하는 대신 커스텀 seccomp 프로파일로 명시적으로 허용하는 방식으로 대응하세요.

• breaking범위 초과 USER 값은 이제 명시적 오류로 처리

  기존에는 OCI spec에 유효 범위를 벗어난 UID/GID가 있으면 예측 불가한 사용자 이름 조회가 조용히 실행됐습니다. 이제는 컨테이너 시작 자체가 실패합니다. 고 숫자 UID를 사용하는 이미지가 있다면 업그레이드 전에 미리 점검하세요. 특히 레거시 이미지나 직접 빌드한 OCI spec을 쓰는 경우 주의가 필요합니다.

• enhancementAppArmor 2.x 호환성 복구 — 구형 배포판 운영자 확인

  Ubuntu 20.04, Debian Bullseye 등 AppArmor 2.x를 탑재한 배포판에서 1.7.x 일부 버전이 AppArmor 프로파일 로드 오류를 일으켰습니다. abi 지시어를 조건부로 설정하도록 수정되었으니, 관련 오류를 겪었던 환경이라면 업그레이드 후 프로파일 로딩 상태를 확인하세요.

containerd 2.3.1은 CVE-2026-46680을 패치하고, 기본 seccomp 정책 강화 및 런타임/스냅샷터 버그를 수정한 패치 릴리스입니다.

• securityCVE-2026-46680 즉시 패치 — 2.3.0에서 업그레이드 필수

  이번 릴리스에서 CVE-2026-46680이 수정됐습니다. 2.3.0을 운영 중이라면 취약점 세부 정보가 공개되기 전에 모든 노드에 2.3.1을 배포하세요. 패키지 매니저나 배포 파이프라인을 통해 빠르게 적용하는 것이 좋습니다.

• security기본 seccomp 정책에서 AF_ALG 차단 — 커널 암호화 API 사용 워크로드 사전 검증 필요

  기본 seccomp 프로파일이 AF_ALG(커널 소켓 기반 암호화 API)를 차단하도록 강화됐습니다. 대부분의 컨테이너 워크로드에는 영향이 없지만, AF_ALG를 직접 사용하는 애플리케이션은 업그레이드 후 동작이 중단될 수 있습니다. 프로덕션 적용 전에 strace 또는 소켓 호출 감사를 통해 영향 여부를 확인하세요. 커스텀 seccomp 프로파일을 직접 지정한 경우엔 영향받지 않습니다.

• breaking비-runc 런타임 사용자: 업그레이드 후 샌드박스 태스크 API 동작 검증 필요

  Kata Containers, gVisor 등 대체 런타임을 쓰는 환경이라면 샌드박스 태스크 API 수정 사항이 실제 컨테이너 생성 및 태스크 관리에 미치는 영향을 반드시 확인하세요. Runc 옵션의 태스크 필드가 deprecated 처리됐으니, 커스텀 Runc 옵션 설정에서 해당 필드를 제거하는 작업도 미리 진행해두는 것이 좋습니다.

runc 외 런타임(Kata, gVisor 등)에서 샌드박스 태스크 API 엔드포인트가 동작하지 않던 버그를 수정한 패치 릴리스입니다.

• breakingnon-runc 런타임 사용 중이라면 즉시 업그레이드 필요

  api/v1.11.0에서 Kata Containers, gVisor, 커스텀 샌드박스 shim을 사용하는 경우 태스크 API 엔드포인트가 정상 동작하지 않는 버그가 있습니다. 태스크 생성·삭제·exec 등의 작업이 조용히 실패하거나 오작동할 수 있으니, api/v1.11.1로 업그레이드 후 태스크 라이프사이클 동작을 반드시 검증하세요.

• enhancement커스텀 shim 관리자라면 프로토 변경 내용 확인

  이번 수정으로 CreateTaskRequest 프로토에 태스크 API 주소 필드가 추가됐습니다. 커스텀 shim을 직접 구현·관리하고 있다면, 해당 필드를 읽는 코드 경로가 있는지 검토하세요. 기존에 비어 있던 필드가 이제 채워져 전달되므로 동작 차이가 생길 수 있습니다. 일반 runc 워크로드는 별도 조치가 필요 없습니다.

containerd 2.3.0은 Kubernetes 릴리스 주기에 맞춘 새 4개월 케이던스 하의 첫 LTS 버전으로, 2년 이상 지원이 보장되며 NRI, EROFS, 관측성 분야에서 대폭 개선됐습니다.

• breaking업그레이드 전 NRI 플러그인 이름에서 쉼표 제거 필수

  새 OCI 훅 소유자 누적 로직이 쉼표를 내부 구분자로 씁니다. 이름에 쉼표가 포함된 NRI 플러그인은 2.3.0에서 동작하지 않습니다. 지금 바로 플러그인 이름을 점검하고, 쉼표가 있다면 바이너리 이름과 설정 파일 모두 변경한 뒤 업그레이드하세요.

• enhancement1.7 → 2.3 LTS 마이그레이션 계획 수립 시작

  이번 릴리스는 containerd 1.7 LTS의 공식 업그레이드 대상입니다. 순차적 LTS 간 직접 업그레이드가 공식 테스트됩니다. 아직 1.7을 쓰고 있다면 지금이 마이그레이션 계획을 세울 적기입니다. 2.3은 최소 2년 지원이 보장되므로, 대략 2027년까지 Kubernetes 클러스터의 안정적인 기반이 됩니다.

• enhancement트레이스 전파 설정으로 플러그인·런타임 관측성 확보

  이제 OTel 트레이스가 containerd와 플러그인 간 gRPC RPC를 통해 전파되고, 트레이스 ID를 로그에 주입할 수 있습니다. Jaeger나 Tempo 같은 분산 트레이싱 스택을 운영 중이라면, containerd 설정에서 OTLP 익스포터를 구성하고 로그의 trace ID 주입을 활성화하세요. 컨테이너 라이프사이클 이벤트가 트레이싱 백엔드에서 보이지 않던 공백이 드디어 채워집니다.

containerd API v1.11.0은 containerd 2.3 릴리스에 맞춰 새 shim 부트스트랩 프로토콜, 컨테이너 파일시스템 복사 전송 타입, 샌드박스 spec 필드를 도입했습니다.

• securitygRPC v1.59.0 → v1.79.3 대폭 업그레이드 — 보안 패치 다수 포함

  마이너 버전이 20단계 올라간 만큼 그간 쌓인 보안·안정성 수정이 상당합니다. gRPC를 별도로 핀닝하거나 벤더링하는 환경이라면 v1.79.3 기준으로 의존성 트리를 재조정해야 합니다. golang.org/x/* 패키지들도 일괄 업그레이드됐으니, 이 API 버전을 프로덕션에 올리기 전에 전체 의존성 감사를 권장합니다.

• breaking샌드박스 API 변경: Container 필드 제거됨 — 관련 코드 즉시 점검 필요

  샌드박스 메타데이터에서 Container 필드가 삭제되고 spec 필드로 대체됐습니다. 샌드박스 메타데이터를 직접 읽거나 쓰는 컨트롤러, 커스텀 런타임, 내부 툴링이 있다면 지금 바로 점검해야 합니다. 이전 proto 정의로 컴파일된 코드는 containerd 2.3 환경에서 런타임 오류가 발생합니다.

• breakingshim 부트스트랩 프로토콜이 protobuf로 교체 — 커스텀 shim은 반드시 업데이트

  부트스트랩 프로토콜이 JSON에서 protobuf로 바뀌었고, 기능과 로그레벨도 문자열에서 enum으로 변경됐습니다. 커스텀 shim을 유지하거나 containerd API를 직접 벤더링하는 경우, containerd 2.3 배포 전에 부트스트랩 처리 로직을 반드시 수정해야 합니다. kata-containers, nydus 같은 서드파티 shim의 호환 릴리스도 함께 확인하세요.

containerd v2.2.3은 spdystream의 CVE-2026-35469를 패치하고, 병렬 언팩 시 whiteout 누락 버그, tar 추출 경쟁 조건, Go 1.24 심링크 회귀 등 여러 버그를 수정했습니다.

• securityCVE-2026-35469 패치: 즉시 v2.2.3으로 업그레이드

  CVE-2026-35469는 containerd가 스트리밍 연결에 사용하는 moby/spdystream에서 발견된 취약점입니다. 이번 릴리스에 spdystream v0.5.1이 포함되어 수정됐습니다. 2.2.x 버전을 운영 중이라면 다음 정기 점검을 기다리지 말고 지금 바로 업그레이드하세요.

• breaking병렬 언팩 whiteout 버그 — 영향받은 이미지는 재풀링 필요

  병렬 언팩이 활성화된 환경에서 레이어 간 파일 삭제를 표시하는 whiteout 파일이 무시되는 버그가 있었습니다. overlayfs와 병렬 언팩을 함께 사용했다면 레이어 삭제 시맨틱이 제대로 적용되지 않았을 수 있습니다. 업그레이드 후 병렬 언팩으로 받은 이미지는 재풀링해서 레이어 상태를 확인하는 것이 좋습니다.

• enhancementGo 1.24 + NixOS 계열 환경의 컨테이너 기동 실패: 이번 릴리스로 해결됩니다

  Go 1.24로 빌드된 바이너리에서 rootfs 내 사용자/그룹 조회 시 절대 심링크 처리에 회귀가 생겼습니다. /etc/passwd나 /etc/group이 심링크인 NixOS 계열 시스템에서 주로 나타나는 문제입니다. Go 1.24 빌드로 전환한 뒤 사용자 조회 실패나 컨테이너 기동 오류를 겪었다면 v2.2.3 업그레이드로 해결됩니다.

containerd 2.0.8은 CVE-2026-35469 보안 패치, CRI 에러 메시지의 인증 정보 노출 수정, containerd 재시작 후 CNI DEL이 실행되지 않던 버그 수정을 포함합니다.

• securityCVE-2026-35469 대응: 즉시 2.0.8로 업그레이드

  CVE-2026-35469는 moby/spdystream 의존성에 존재하는 취약점입니다. 2.0.x를 운영 중인 클러스터라면 다음 유지보수 주기를 기다리지 말고 2.0.8로 올리세요. 해당 advisory의 심각도를 확인한 뒤 업그레이드 우선순위를 판단하기 바랍니다.

• security과거 파드 이벤트 로그에서 인증 정보 노출 여부 점검

  이번 수정 이전에는 레지스트리 인증 정보 등 URL에 포함된 민감 데이터가 CRI gRPC 에러 메시지와 파드 이벤트에 평문으로 기록될 수 있었습니다. Datadog, Splunk, ELK 등 외부 로깅 백엔드로 파드 이벤트를 수집 중이라면, 최근 로그에서 노출된 쿼리 파라미터가 없는지 점검하세요. 2.0.8부터는 containerd 내부에서 마스킹 처리됩니다.

• breaking업그레이드 후 CNI 네트워크 정리가 정상 동작하는지 확인

  이번에 수정된 CNI DEL 버그로 인해, containerd 재시작 이후 파드를 삭제할 때 CNI 플러그인 정리가 실행되지 않아 노드에 네트워크 상태가 남아 있을 수 있습니다. 2.0.8로 업그레이드한 뒤에는 containerd 재시작을 경험한 노드에서 파드 삭제 시 CNI DEL이 제대로 호출되는지 검증하세요. 이전에 고아 네트워크 인터페이스나 IP 할당 충돌이 발생했다면 이 버그가 원인이었을 가능성이 높습니다.

containerd 2.1.7은 spdystream의 CVE-2026-35469를 패치하고, gRPC 자격 증명 누출 방지 및 tar 추출 TOCTOU 경쟁 조건 수정 등 보안 강화 변경을 포함합니다.

• securityCVE-2026-35469 패치를 위해 즉시 2.1.7로 업그레이드

  moby/spdystream의 CVE-2026-35469가 이번 릴리스에서 수정됐습니다. spdystream은 CRI 스트리밍 경로에서 사용되므로 exec/attach/port-forward를 쓰는 Kubernetes 워크로드가 잠재적으로 영향을 받습니다. 모든 노드의 containerd를 2.1.7로 업그레이드하세요. 설정 변경 없이 바이너리 교체 후 데몬 재시작만 하면 됩니다.

• securitypod 이벤트를 통한 자격 증명 누출 경로 차단

  이번 수정 전까지 레지스트리 자격 증명이 포함된 원시 오류가 pod 이벤트에 노출될 수 있었습니다. 네임스페이스 범위 사용자에게 pod 이벤트 접근을 허용하는 클러스터라면 자격 증명이 로그나 이벤트 스트림에 노출됐을 가능성이 있습니다. 영향받은 클러스터에서 사용된 레지스트리 pull secret을 교체한 뒤 2.1.7로 업그레이드하세요.

• enhancementCNI DEL 버그 수정으로 재시작 후 네트워크 자원 누수 방지

  기존에는 containerd 재시작 후 정리되는 샌드박스에 CNI DEL이 호출되지 않아 IP 등 네트워크 자원이 누수됐습니다. 노드 재시작 후 스테일 IP나 CNI 상태 이상을 겪은 적 있다면 이 버그가 원인일 가능성이 높습니다. 2.1.7로 업그레이드하고, 기존 누수 상태를 정리하려면 containerd 재시작 전 노드를 드레인하는 편이 안전합니다.

v1.7.31은 spdystream의 CVE-2026-35469를 패치하고, 재시작 후 CNI DEL이 실행되지 않던 버그와 gRPC 에러를 통한 자격증명 노출 문제를 수정합니다.

• securityCVE-2026-35469 패치: 즉시 v1.7.31로 업그레이드

  CVE-2026-35469는 SPDY 멀티플렉싱에 쓰이는 moby/spdystream 라이브러리의 취약점입니다. 수정본은 이번 릴리스에 포함된 spdystream v0.5.1에 담겨 있습니다. 1.7.x 이전 버전을 운영 중이라면 즉시 업그레이드하세요. 특히 CRI 스트리밍 서버가 노출되어 있거나 kubectl exec/attach/port-forward 트래픽이 containerd를 통해 흐르는 클러스터라면 더욱 시급합니다.

• security파드 이벤트 로그에서 자격증명 노출 여부 점검

  원시 에러 메시지에 레지스트리 자격증명이 포함된 채로 gRPC를 통해 반환되고 파드 이벤트에 노출되는 버그가 있었습니다. 업그레이드 후, 수정 전 기간의 파드 이벤트 로그(kubectl get events 또는 로그 수집 시스템)를 검토해 인증 토큰, 비밀번호, 이미지 풀 시크릿이 포함된 항목이 있는지 확인하세요. 노출된 자격증명이 발견되면 즉시 교체해야 합니다.

• breaking업그레이드 후 CNI 네트워크 정리 동작 검증 필요

  CNI DEL 버그 수정으로, 기존에 containerd 재시작 후 스테일 네트워크 상태를 남기던 컨테이너가 이제 제대로 정리됩니다. 올바른 동작이지만, CNI DEL이 생략된다고 가정하는 자동화 스크립트나 워크플로가 있다면 미리 테스트하세요. 비정상 재시작 이력이 있는 노드는 업그레이드 후 첫 파드 삭제 시 정리 작업이 실행될 수 있습니다.

containerd 2.2.2는 프로덕션 쿠버네티스 워크로드에 영향을 줄 수 있는 CRI 네트워킹 버그, 레지스트리 인증정보 유출, AppArmor 호환성 문제를 수정했습니다.

• security레지스트리 인증정보 노출 방지를 위한 업데이트

  레지스트리 인증정보가 에러 메시지와 파드 이벤트에 노출될 수 있었습니다. 인증이 필요한 프라이빗 레지스트리를 사용한다면 즉시 이 패치를 배포하세요. 해당 인증정보가 권한 없는 사용자가 접근할 수 있는 로그나 쿠버네티스 이벤트에 나타날 수 있기 때문입니다.

• breaking재시작 후 CNI 네트워크 정리 문제 해결

  containerd 재시작 후 CNI DEL 작업이 실행되지 않아 오래된 네트워크 구성이 남아있었습니다. 파드 네트워킹 안정성에 영향을 줍니다. 다음 유지보수 기간 전에 업데이트해서 네트워크 네임스페이스 누수와 잠재적인 IP 충돌을 방지하세요.

• enhancementAppArmor 호환성을 위한 업그레이드

  AppArmor 프로파일이 이제 최신 커널에서 유닉스 도메인 소켓과 올바르게 동작합니다. 최신 커널 버전을 실행하면서 AppArmor가 활성화된 상태에서 소켓 연결 문제를 겪고 있다면, 이 업데이트가 호환성 문제를 해결해줍니다.