CVE-2026-18107

WysokieCVSS 7.8

Opublikowano: 28/07/2026(UTC)Zaktualizowano: 21/08/2026(UTC)Przetłumaczono: 29/07/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.11%

Percentyl 2 - wyżej niż 2% wszystkich znanych CVE

Streszczenie

W CRIU stwierdzono podatność związaną z obsługą restartowalnych sekwencji (rseq) podczas tworzenia punktów kontrolnych i przywracania. Złośliwy proces w kontenerze może zarejestrować sekcję krytyczną rseq, która przechwytuje wstrzykiwanie kodu pasożytniczego CRIU, umożliwiając sfałszowanie poświadczeń procesu zapisanych w obrazie punktu kontrolnego. Po przywróceniu proces w kontenerze uzyskuje podniesione możliwości i wyzerowane UID/GID.

Ocena ryzyka

Ryzyko jest ograniczone przez kilka czynników: do wywołania wymagane są uprawnienia roota lub cluster-admin RBAC, a na OpenShift domyślnie stosowane są przestrzenie nazw użytkowników, SELinux i seccomp, które blokują eskalację uprawnień.

Rekomendacja

Zaleca się aktualizację CRIU do najnowszej wersji zawierającej poprawkę oraz stosowanie domyślnych mechanizmów bezpieczeństwa OpenShift (przestrzenie nazw użytkowników, SELinux, seccomp).

Inne podatności w CRIU

CVE-2015-5228Wysokie
Demon usługi w CRIU tworzy pliki dziennika i zrzutu w sposób niebezpieczny, co pozwala lokalnym użytkownikom na tworzenie dowolnych plików oraz przejmowanie własności istniejących plików poprzez nieokreślone wektory związane ze ścieżką katalogu.

Oryginalny opis (angielski, źródło NVD)

A flaw was found in CRIU's handling of restartable sequences (rseq) during checkpoint/restore. A malicious process inside a container can register an rseq critical section that hijacks CRIU's parasite code injection during checkpoint, allowing it to spoof the process credentials saved in the checkpoint image. On restore, the container process gains elevated capabilities and zeroed UIDs/GIDs. The practical impact on Red Hat products is limited by several factors: checkpoint/restore requires root privileges (podman) or cluster-admin RBAC (OpenShift) to trigger and cannot be initiated from within the container itself; on OpenShift prior to 4.17 the feature required explicit opt-in, and on 4.17+ the kubelet checkpoint API RBAC is not configured by default; OpenShift enforces user namespaces by default for regular workloads (hostUsers is gated behind admin-only SCCs), which makes the spoofed capabilities namespace-scoped and ineffective for privilege escalation; SELinux type enforcement (container_t) blocks privilege transitions independently of capabilities; seccomp filters persist through checkpoint/restore and cannot be corrupted via the parasite; and kernel mount namespace ownership checks on RHEL 9/10 kernels prevent mount-based container escape even with spoofed capabilities.