SURIQ
CISA's Known Exploited Vulnerabilities catalog files this one under Linux kernel privilege escalation. That label undersells it. CVE-2026-53362 is a container escape. A low-privilege user inside one container can corrupt kernel memory, step over SELinux, and land as root on the host that runs every other tenant beside them. CISA added it to its Known Exploited Vulnerabilities catalog on August 27, 2026, and gave federal agencies until August 30 to patch. The exposure is also the reverse of the usual instinct: the newest, best-maintained fleets are the ones at risk.
Red Hat rates it 7.8 (High). The scoring tells the story: an attacker needs only local access and low privileges, the attack is low complexity, and a successful run costs you confidentiality, integrity, and availability in full. Red Hat's own name for the advisory, RHSB-2026-009, is blunter than the KEV entry. It calls this an IPv6 fragmentation container escape.
A privilege escalation label hiding a container escape
The bug lives in __ip6_append_data(), the kernel routine that assembles outbound IPv6 packets. A length is miscalculated on the paged-allocation branch, and the kernel then writes past the end of skb_shared_info, the metadata block it keeps beside each network buffer. A local user reaches that branch with a UDPv6 socket that combines MSG_MORE with MSG_SPLICE_PAGES. From that one memory-corruption foothold, Red Hat says an attacker can work up to reading and writing kernel memory at will, then overwrite credentials, step around SELinux enforcement, and cross out of the container onto the host underneath it.
The one precondition that matters for scoping is this: the attacker needs to create network namespaces. On most modern distributions an unprivileged user can do that through user namespaces, which is exactly how a process confined to a container reaches the vulnerable code path. That is the difference between a bug that annoys a single-tenant box and one that collapses the boundary between tenants.
The exposure is inverted: the newest kernels are the vulnerable ones
Read the affected list carefully, because it runs against the grain of how most teams triage. Red Hat Enterprise Linux 10 is affected and already has fixes out. RHEL 9 is not on the list, and OpenShift ships on top of RHEL 9, which keeps it out of scope as well. Current SUSE kernels are affected, and mainline kernels new enough to carry the paged-allocation branch are in the same position.
| Platform / kernel | Exposed to CVE-2026-53362 | First action |
|---|---|---|
| Red Hat Enterprise Linux 10 | Affected | Apply the released kernel errata now |
| Red Hat Enterprise Linux 9 (and OpenShift) | Not affected | No action for this CVE |
| SUSE (current kernels) | Affected | Apply the SUSE kernel update |
| Other distros on recent kernels | Check advisory | Confirm against your vendor bulletin |
The vulnerable append path is recent code, so it is present on the platforms people upgraded to this year and absent on the ones they have not moved off yet. A shop that stayed on RHEL 9 is safe from this specific flaw. A shop that did the responsible thing and moved to RHEL 10 is the one that has to patch tonight. "We are current on everything" is the risk here, not the comfort.
Why EPSS says 0.18 percent and CISA says patch in three days
If you triage by the Exploit Prediction Scoring System, this CVE scores about 0.18 percent, which reads as "almost certainly will not be exploited." CISA lists it as exploited right now. Both are true at once, and the gap is the lesson. EPSS is a statistical model trained on how vulnerabilities behave in aggregate; it lags real-world reports and it has nothing useful to say about a bug that is already in someone's toolkit. When a CVE sits on the KEV catalog with a federal deadline, that is ground truth, and it outranks a low EPSS every time. Treating a KEV listing as "low priority because EPSS is tiny" is how the three-day window closes on you.
This belongs on your container risk register, not just your patch list
The teams with the most to lose are the ones running many tenants on shared kernels: multi-tenant container hosts, shared continuous-integration runners where anyone can submit a job, and any platform that hands untrusted users the ability to spin up their own namespaces. On those systems a single low-privilege foothold in one workload becomes root over the host and, with it, every other workload on the box. That is not a kernel-hygiene footnote. It is the kind of blast radius that justifies pulling a maintenance window forward.
It is also the latest entry in a pattern we have been tracking. This year alone we wrote up GhostLock turning any Linux foothold into host root, Bad Epoll breaking a sandboxed process out to root, and DirtyClone rewriting /bin/su in memory. The container boundary keeps proving to be exactly as strong as the kernel underneath it, and the kernel keeps producing new ways through. What is new here is that this one arrived with a CISA exploitation confirmation attached, the same way the earlier kernel KEV listing did.
Patch fast, and know what the interim switch costs you
The clean fix is the kernel update. RHEL 10 has errata available now; apply them and reboot onto the fixed kernel. SUSE has shipped kernel updates as well. For any host running a recent mainline kernel, confirm the fix against your distribution's bulletin rather than assuming.
If you truly cannot patch and reboot at once, Red Hat offers an interim switch: turn off unprivileged user namespaces by setting user.max_user_namespaces=0. Understand that this is a tradeoff, not a free flag. It shuts the namespace-creation path the exploit relies on, but it also breaks anything that leans on unprivileged user namespaces, rootless Podman and some sandbox setups among them. On a host that relies on rootless containers, that switch is not available to you, which means patching is the only real option, so schedule it.
For knowing whether the window was already used against you, the useful signals are on the host, not in a vulnerability scanner. Watch for unprivileged processes creating network or user namespaces they never touched before, kernel log entries showing buffer or skb corruption or oopses around the IPv6 path, and any local account that acquires root without a matching authenticated escalation. A managed detection service that correlates namespace creation with unexpected privilege gains, mapped to the relevant MITRE ATT&CK techniques, will catch the shape of this even when the specific exploit is novel. A file-based vulnerability scan will only tell you the kernel is unpatched, which you already know.