Skip to content
VulniPulse
Advisory severityHigh7.8Vendor: MediumRed Hat Linux

High [CVE-2026-18107] container escape via rseq critical section hijack during checkpoint/restore

This high-severity Red Hat Linux advisory covers CVE-2026-18107 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8.

Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.

CVE-2026-18107 Source published Source updated

VulniPulse record published Record updated

Affected products & platforms
Red Hat LinuxRed Hat Enterprise Linux
Open source advisory

Android app · Google Play

Monitor future Red Hat Linux CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.

Matching phone alertsOptional email delivery

Summary

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.

Red Hat severity: Moderate — CVSS 7.8 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H).

Affected versions
  • < 4.17

Official advisory · high-confidence parse· fetched 11 days ago·verify at source

Fixed versions

No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.

Official advisory · high-confidence parse· fetched 11 days ago·verify at source

Mitigation checklist

Recommended fix / mitigation
  • Disable checkpoint/restore functionality in the container runtime if it is not required. If checkpoint/restore is needed, ensure containers run with user namespaces enabled, which limits the scope of spoofed capabilities to the user namespace.

Official advisory · high-confidence parse· fetched 11 days ago·verify at source

Discussion(0)

No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.

Sign in to join the discussion.