# Kubernetes v1.33.6 / v1.34.x – Kernel 4.18 Compatibility on RHEL 8 while Addressing Kubelet RCE

**URL:** <https://discuss.kubernetes.io/t/kubernetes-v1-33-6-v1-34-x-kernel-4-18-compatibility-on-rhel-8-while-addressing-kubelet-rce/33851>\
**Category:** General Discussions\
**Tags:** security\
**Created:** [December 23, 2025, 6:38am UTC](https://discuss.kubernetes.io/t/kubernetes-v1-33-6-v1-34-x-kernel-4-18-compatibility-on-rhel-8-while-addressing-kubelet-rce/33851 "2025-12-23T06:38:56Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bangar](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/bangar/32/15416_2.png) [@Bangar](https://discuss.kubernetes.io/u/Bangar)\
**Post date:** [December 23, 2025, 6:38am UTC](https://discuss.kubernetes.io/t/kubernetes-v1-33-6-v1-34-x-kernel-4-18-compatibility-on-rhel-8-while-addressing-kubelet-rce/33851/1 "2025-12-23T06:38:56Z")

</div>

Hello Everyone,

I’m looking for guidance and confirmation regarding Kubernetes upgrade constraints on RHEL 8, specifically while trying to address a Kubelet RCE vulnerability.

### Cluster information

- **Current Kubernetes version:** v1.30.0

- **Target versions under consideration:** v1.30.8 / v1.33.6 / v1.34.1

- **Deployment model:** Bare-metal (offline environment)

- **Installation method:** kubeadm

- **Host OS:** RHEL 8.10

- **Kernel version:** 4.18.0-553.x.el8\_10.x86\_64 (latest vendor-supported kernel for RHEL 8)

- **CNI:** Flannel v0.26.0

- **CRI:** containerd v1.7.24

* * *

### Background / reason for upgrade

This upgrade is being planned to address a **Kubelet Remote Code Execution (RCE) vulnerability** identified in one of the environments .

- The commonly referenced temporary mitigation (disabling anonymous authentication on kubelet) is already hardcoded in **Kubernetes v1.30.0** , but this **does not fully remediate the vulnerability**.

- Based on upstream advisories and technical guidance, the **effective fix is available only in patched releases (v1.30.8+) or in newer Kubernetes versions**.

- Recommendations generally point to:

Given that this is a **security-driven upgrade** , we are evaluating the safest supported path forward.

* * *

### Issue encountered

When attempting to upgrade to **Kubernetes v1.33.6** , `kubeadm` fails during preflight checks with the following error:

```auto
[ERROR SystemVerification]: kernel release 4.18.0-553.x.el8_10.x86_64 is unsupported.
Recommended LTS version from the 4.x series is 4.19.
Any 5.x or 6.x versions are also supported.

```

This prevents cluster initialization or upgrade from proceeding.

* * *

### Environment constraints

- RHEL 8.10 systems are running the **latest kernel supported by Red Hat (4.18)**.

- Upgrading to kernel 5.x on RHEL 8 is **not supported by Red Hat**.

- Upgrading to **RHEL 9.x (kernel 5.14)** is technically feasible, but represents a **major OS upgrade** with potential impact to existing applications and dependencies.

- The environment is **offline** , with all Kubernetes artifacts pre-downloaded and managed internally.

* * *

### Points requiring confirmation and decision

1. Whether **Kubernetes v1.33.x / v1.34.x is officially unsupported on RHEL 8** due to the kernel 4.18 limitation.

2. Whether **Kubernetes v1.30.x (specifically v1.30.8)** represents the **last supported and secure Kubernetes version** for RHEL 8.

3. From a security and supportability standpoint:

4. Whether any **supported interim approaches** exist for environments that cannot immediately undergo an OS upgrade but must address this security exposure.

* * *

### Current understanding

- Kubernetes **v1.31 and above dropped support for kernel 4.18**

- `kubeadm` enforces this through preflight checks

- Bypassing checks using `--ignore-preflight-errors=SystemVerification` is **not suitable for production or regulated environments**

- The limitation appears to be a **platform compatibility constraint** , rather than a configuration or deployment issue

* * *

I’m looking to confirm this understanding and determine the **most appropriate supported path forward** before finalizing the upgrade decision.

Thanks.