kubelet-started container uid changes to root after first restart or if image is already pulled to the node
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Kubernetes | Kubernetes | affected |
|
Configuration 1 [-]
|
No data.
No data available yet.
Vendor Workaround
Specify runAsUser directives in pods to control the uid a container runs as. Specify mustRunAsNonRoot:true directives in pods to prevent starting as root (note this means the attempt to start the container will fail on affected kubelet versions).
| Source | ID | Title |
|---|---|---|
EUVD |
EUVD-2024-1293 | In kubelet v1.13.6 and v1.14.2, containers for pods that do not specify an explicit runAsUser attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified mustRunAsNonRoot: true, the kubelet will refuse to start the container as root. If the pod did not specify mustRunAsNonRoot: true, the kubelet will run the container as uid 0. |
Github GHSA |
GHSA-r76g-g87f-vw8f | Kubelet Incorrect Privilege Assignment |
No CVSS v4.0
No CVSS v3.1
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.599% probability within 30 days)
Key SSVC decision points have not yet been added.
No history.