Yes. A container image carries libraries and applications, not a kernel. Containers run on the host's kernel, so a kernel vulnerability is fixed by patching and rebooting the host or node, not by rebuilding the image. Image scanning and kernel patching cover different layers.
What lives where
Think in two layers.
| Layer | Who updates it | How it gets fixed |
|---|---|---|
| Application and libraries in the image | Your build | Rebuild and redeploy the image |
| Host kernel and host packages | Whoever runs the node | Patch the node, reboot or livepatch |
Docker's security documentation explains why the kernel matters. Isolation depends on kernel namespaces and cgroups, and the page warns that default capabilities and mounts may give incomplete isolation when combined with kernel vulnerabilities. That is the document's own framing: the kernel is part of the security boundary.
A common misunderstanding
Teams scan an image, see a clean report, and conclude the workload is safe. But a scanner reading an image sees packages in that image. It does not see the kernel of the machine the container will run on. A base image with a kernel package listed inside it is also not what runs, because the container uses the host's kernel.
So two questions stay separate: is my image current, and are my nodes current?
Who owns the kernel in your setup
- Self managed virtual machines or bare metal: you do.
- A managed Kubernetes node pool: usually the provider offers node image upgrades, but you often trigger or schedule them. Check the provider's documentation for your service.
- A serverless platform: the provider does, which is part of the shared responsibility split described in serverless shared responsibility.
A practical node patching routine
- Keep an inventory of node image versions and kernel versions per cluster.
- Drain a small group of nodes, upgrade them, and watch workloads.
- Continue in waves, as in canary patch rollouts.
- Use a livepatch where it fits, and remember its limits, covered in kernel livepatch: what it fixes and what still needs a reboot.
- Record the kernel version after the reboot, not only the package version installed.
Hardening that lowers the stakes
Docker notes that running containers with reduced privileges makes it harder for an intruder with root inside a container to reach the host. Dropping capabilities and avoiding privileged containers will not replace kernel patching, but they raise the cost of using a kernel bug.
Try it yourself
Click through an image scan and note which findings are image packages, then think about which layer a kernel flaw would belong to.
Click through it at your own pace, or open it full screen.
Quick check
If my image has no kernel CVEs, am I covered?
No. The image does not contain the running kernel. Check the nodes separately.
Does rebuilding an image pick up a kernel fix?
No. A rebuild updates image contents. The kernel changes only when the host is patched and restarted, or livepatched where supported.
Safeguard scans container images and dependencies and discovers assets, which helps you keep an inventory of what is running where. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
