CVE-2026-53495 w containerd to dobry przykład, dlaczego severity nie powinno automatycznie wyznaczać kolejki remediation. W implementacji CRI na Linuksie operacje ExecSync — w praktyce także exec-based probes i lifecycle hooks — mogą zostawić zablokowane goroutines, gdy uruchomiony proces tworzy długowieczne procesy potomne dziedziczące deskryptory stdio. Powtarzanie wzorca zwiększa zużycie pamięci, aż OOM killer zabija containerd. Rezultat: niedostępność runtime na całym node do restartu. CVSS v4 to 6.8 Medium, ale blast radius obejmuje wiele workloadów.
Failure path
To nie „DoS jednego kontenera”. Affectedness jest warunkowa: Linux, używany plugin CRI, podatna wersja, workload uruchamiający ExecSync/probes/hooks w problematyczny sposób. Użytkownicy bez CRI i systemy nie-Linuksowe nie należą do exploitable population — idealny przypadek conditional VEX.
CVSS 6.8 vs realne ryzyko
Na hoście developerskim skutkiem jest irytujący restart. Na Kubernetes node z wieloma krytycznymi workloadami awaria containerd uderza w zarządzanie kontenerami, operacje kubelet/runtime, zdolność platformy do obsługi workloadów i pośrednio dostępność wielu usług. CVSS nie modeluje gęstości workloadów, krytyczności node poola ani kosztu utraty runtime: CVSS 6.8 != business impact 6.8. Źródło maintainerów nie potwierdza exploitation in-the-wild — nie oznaczaj CVE jako aktywnie wykorzystywanego bez sygnału; problem jest jednak triggerowalny wzorcem workloadu, więc w multi-tenant licz się z przypadkowym triggerem i celowym nadużyciem tam, gdzie user definiuje probes.
Dwa błędy priorytetyzacji
False positive: skaner znajduje podatną wersję na nie-Linuksie, bez CRI albo bez osiągalnego code path — nie usuwaj findingu, zmień affectedness na evidence (package vulnerable / CRI path not active z rewalidacją). False negative (groźniejszy): Medium dostaje niski SLA, a najbardziej krytyczny node pool ma dużo workloadów, częste exec probes, mały memory headroom i krytyczne usługi — priorytet realnie wyższy niż score. Compensating control (maintainerzy): probes/hooks nie powinny uruchamiać długowiecznych procesów potomnych w tle — sprawdzalne policy-as-code, review probe commands, runtime telemetry i alerting na wzrost pamięci/goroutines containerd.
Remediation poprawnie
Inventory po node, nie po repozytorium (obraz/AMI/IaC to nie dowód realnej wersji). Mapowanie linii: 1.7.x→≥1.7.35, 2.0.x→≥2.0.12, 2.2.x→≥2.2.8, 2.3.x→≥2.3.5. 95% nodes patched ≠ remediated — pozostałe 5% może obsługiwać najbardziej krytyczne workloady. Behavioral verification w labie: wzorzec długowiecznego child po ExecSync nie narasta w poprawionej wersji. Telemetria po rollout: RSS containerd, restarty, OOM events, memory pressure, problemy z CRI. Lifecycle: AFFECTED → PATCH_ROLLOUT_IN_PROGRESS → ALL_RELEVANT_NODES_PATCHED → RUNTIME_VERSION_VERIFIED → REMEDIATION_VERIFIED. W autoscalingu sprawdź, że nowe node powstają z poprawionego obrazu — inaczej vulnerability wraca po scale-out.
Powiązane na blogu
- crun: trzy CVE, trzy warunki — container runtime i configuration-aware affectedness
- Excelize: 3 KB pliku, minuta CPU — DoS o dużym koszcie mimo Medium
Źródła
- containerd GHSA-7jxh-36q5-gcqv — github.com
Nota redakcyjna: stan informacji 10 września 2026. CVE-2026-53495 (containerd, CRI na Linuksie, CVSS v4 6.8) prowadzi do wyczerpania pamięci i śmierci containerd, a więc utraty runtime na node. Brak potwierdzenia active exploitation w źródle. Artykuł omawia conditional VEX, mapowanie linii i rollout coverage w klastrach autoskalowanych.