Answer in brief
CVE-2026-18107 records a Unknown severity vulnerability in Criu: criu: container escape via rseq critical section hijack during checkpoint/restore. The current sources do not mark it as known exploited. Affected software not mapped in the current feed; confirm the named product and version against your inventory.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
Affected software not mapped in the current feed; confirm the named product and version against your inventory.
Published upstream
Jul 28, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 21, 2026
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.
Quoted source text, attributed separately from HOL analysis.