CVE-2026-18107: Improper Privilege Management in Red Hat Red Hat Enterprise Linux 10
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.
AI Analysis
Technical Summary
CVE-2026-18107 is a vulnerability in CRIU's handling of restartable sequences (rseq) during checkpoint and restore operations. A malicious container process can register an rseq critical section that hijacks CRIU's parasite code injection during checkpoint, enabling spoofing of process credentials saved in the checkpoint image. Upon restore, the container process gains elevated capabilities and zeroed user and group IDs. The vulnerability's practical impact on Red Hat products is limited by several factors: checkpoint/restore requires root privileges (podman) or cluster-admin RBAC (OpenShift) and cannot be initiated from within the container; OpenShift prior to 4.17 requires explicit opt-in for checkpoint/restore, and in 4.17+ the kubelet checkpoint API RBAC is not configured by default; OpenShift enforces user namespaces by default, making spoofed capabilities namespace-scoped and ineffective for privilege escalation; SELinux type enforcement blocks privilege transitions independently of capabilities; seccomp filters persist and cannot be corrupted; and kernel mount namespace ownership checks on RHEL 9/10 prevent mount-based container escape even with spoofed capabilities.
Potential Impact
If exploited, a malicious container process can gain elevated capabilities and zeroed UIDs/GIDs after checkpoint/restore, potentially escalating privileges within the container namespace. However, the requirement for root or cluster-admin privileges to trigger checkpoint/restore, combined with container security features such as user namespaces, SELinux enforcement, seccomp filters, and kernel mount namespace ownership checks, significantly limits the practical impact and prevents container escape or host privilege escalation.
Mitigation Recommendations
No official patch or fix is explicitly stated in the provided advisory content. The vulnerability requires privileged access to trigger checkpoint/restore, which is typically restricted. Red Hat products enforce multiple security controls that mitigate exploitation impact, including user namespaces, SELinux, seccomp, and kernel namespace ownership checks. Users should ensure that checkpoint/restore operations are restricted to trusted administrators and that security policies (RBAC, SELinux, seccomp) are properly enforced. Patch status is not yet confirmed — check the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-18107 for current remediation guidance.
CVE-2026-18107: Improper Privilege Management in Red Hat Red Hat Enterprise Linux 10
Description
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.
CVSS v3.1
Score 7.8high
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
CVE-2026-18107 is a vulnerability in CRIU's handling of restartable sequences (rseq) during checkpoint and restore operations. A malicious container process can register an rseq critical section that hijacks CRIU's parasite code injection during checkpoint, enabling spoofing of process credentials saved in the checkpoint image. Upon restore, the container process gains elevated capabilities and zeroed user and group IDs. The vulnerability's practical impact on Red Hat products is limited by several factors: checkpoint/restore requires root privileges (podman) or cluster-admin RBAC (OpenShift) and cannot be initiated from within the container; OpenShift prior to 4.17 requires explicit opt-in for checkpoint/restore, and in 4.17+ the kubelet checkpoint API RBAC is not configured by default; OpenShift enforces user namespaces by default, making spoofed capabilities namespace-scoped and ineffective for privilege escalation; SELinux type enforcement blocks privilege transitions independently of capabilities; seccomp filters persist and cannot be corrupted; and kernel mount namespace ownership checks on RHEL 9/10 prevent mount-based container escape even with spoofed capabilities.
Potential Impact
If exploited, a malicious container process can gain elevated capabilities and zeroed UIDs/GIDs after checkpoint/restore, potentially escalating privileges within the container namespace. However, the requirement for root or cluster-admin privileges to trigger checkpoint/restore, combined with container security features such as user namespaces, SELinux enforcement, seccomp filters, and kernel mount namespace ownership checks, significantly limits the practical impact and prevents container escape or host privilege escalation.
Mitigation Recommendations
No official patch or fix is explicitly stated in the provided advisory content. The vulnerability requires privileged access to trigger checkpoint/restore, which is typically restricted. Red Hat products enforce multiple security controls that mitigate exploitation impact, including user namespaces, SELinux, seccomp, and kernel namespace ownership checks. Users should ensure that checkpoint/restore operations are restricted to trusted administrators and that security policies (RBAC, SELinux, seccomp) are properly enforced. Patch status is not yet confirmed — check the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-18107 for current remediation guidance.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-hm7v-8wcp-3gjm
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-18107"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6a6940329c2644c7f866a519
Added to database: 07/28/2026, 23:50:10 UTC
Last enriched: 07/29/2026, 12:07:10 UTC
Last updated: 09/12/2026, 10:01:29 UTC
Views: 118
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.