**Affected Versions**:
  - kubelet <= v1.28.0
  - kubelet <= v1.27.4
  - kubelet <= v1.26.7
  - kubelet <= v1.25.12
  - kubelet <= v1.24.16

**Fixed Versions**:
  - kubelet v1.28.1
  - kubelet v1.27.5
  - kubelet v1.26.8
  - kubelet v1.25.13
  - kubelet v1.24.17

**Affected Versions**:
  - kubelet <= v1.28.0
  - kubelet <= v1.27.4
  - kubelet <= v1.26.7
  - kubelet <= v1.25.12
  - kubelet <= v1.24.16

**Fixed Versions**:
  - kubelet v1.28.1
  - kubelet v1.27.5
  - kubelet v1.26.8
  - kubelet v1.25.13
  - kubelet v1.24.17

- `kubeadm`: will now allow deploying a kubelet that is 3 versions older than the version of `kubeadm` (N-3). This aligns with the recent change made by SIG Architecture that extends the support skew between the control plane and kubelets. Tolerate this new kubelet skew for the commands `init`, `join` and `upgrade`. Note that if the `kubeadm` user applies a control plane version that is older than the...

directories outside of the volume, including on the host filesystem.

**Affected Versions**:
  - kubelet v1.22.0 - v1.22.1
  - kubelet v1.21.0 - v1.21.4
  - kubelet v1.20.0 - v1.20.10
  - kubelet <= v1.19.14

**Fixed Versions**:
  - kubelet v1.22.2
  - kubelet v1.21.5
  - kubelet v1.20.11
  - kubelet v1.19.15

This vulnerability was reported by Fabricio Voznika and Mark Wolters of Google.

	HostProbeSNATIPV6 = netip.MustParseAddr(env.RegisterStringVar("HOST_PROBE_SNAT_IPV6", DefaultHostProbeSNATIPV6, "").Get())
)

const (
	// to reliably identify kubelet healthprobes from inside the pod (versus standard kube-proxy traffic,
	// since the IP is normally the same), we SNAT identified host probes in the host netns to a fixed
	// APIPA/"link-local" IP.
	//

#### Affected Versions

- kubelet v1.20 - v1.21
- kubelet v1.22.0 - v1.22.13
- kubelet v1.23.0 - v1.23.10
- kubelet v1.24.0 - v1.24.4

### How do I mitigate this vulnerability?

There are no known mitigations to this vulnerability.

#### Fixed Versions

- kubelet v1.22.14
- kubelet v1.23.11
- kubelet v1.24.5
- kubelet v1.25.0

- kubeadm now deletes the bootstrap-kubelet.conf file after TLS bootstrap
  User relying on bootstrap-kubelet.conf should switch to kubelet.conf that contains node credentials ([#80676](https://github.com/kubernetes/kubernetes/pull/80676), [@fabriziopandini](https://github.com/fabriziopandini))

  optional EventSeries series = 3;

  // reportingController is the name of the controller that emitted this Event, e.g. `kubernetes.io/kubelet`.
  // This field cannot be empty for new Events.
  optional string reportingController = 4;

  // reportingInstance is the ID of the controller instance, e.g. `kubelet-xyzf`.
  // This field cannot be empty for new Events and it can have at most 128 characters.
  optional string reportingInstance = 5;

**Affected Versions**:

- kubelet v1.20 - v1.21
- kubelet v1.22.0 - v1.22.13
- kubelet v1.23.0 - v1.23.10
- kubelet v1.24.0 - v1.24.4

**How do I mitigate this vulnerability?**

There are no known mitigations to this vulnerability.

**Fixed Versions**:

- kubelet v1.22.14
- kubelet v1.23.11
- kubelet v1.24.5
- kubelet v1.25.0

### Node Components
* **Kubelet with the Docker-CRI implementation**
  * The Docker-CRI implementation is enabled by default.
  * It is not compatible with containers created by older Kubelets. It is
    recommended to drain your node before upgrade. If you choose to perform
    an in-place upgrade, the Kubelet will automatically restart all
    Kubernetes-managed containers on the node.