How-To Upgrade Cilium to Resolve CVE-2026-49445 in CMK clusters

Introduction

Cilium is a core Crusoe Managed Kubernetes (CMK) add-on that provides the cluster's CNI, handling networking, service load-balancing, and network policy enforcement. CMK clusters currently run one of two Cilium versions - 1.16.1 on older clusters, or 1.19.1 on newer ones.

A critical vulnerability, CVE-2026-49445 (CVSS 9.2, Critical), has been identified affecting any cluster running Cilium with L7 functionality enabled. The vulnerability impacts all Cilium versions prior to 1.17.14, 1.18.8, and 1.19.2 — which includes both versions CMK clusters currently ship with, 1.16.1 and 1.19.1.

The fix is included in 1.17.14, 1.18.8, 1.19.2, and later releases on each branch.

This page walks through safely upgrading Cilium in your CMK cluster to the latest patched version, 1.19.8.

See Determining Your Upgrade Path below to check which version your cluster is on and how to get to 1.19.8 from there.

ℹ️ Note: Cilium is a Crusoe-managed add-on under the CMK shared responsibility model. Because Cilium upgrades affect cluster networking, coordinate a maintenance window with Crusoe Support before upgrading. See FAQ: CMK Add-on Lifecycle and Upgrades.

Prerequisites

Existing CMK Cluster
kubectl Access to the CMK Cluster
helm Installed on the Local Machine

⚠️ Warning: This procedure only works if the cluster's Cilium images are sourced from a public registry (quay.io). It will not work for air-gapped/private clusters. If your cluster pulls Cilium images from a mirrored registry, open a ticket with Crusoe Support instead.

Determining Your Upgrade Path

Use the commands in Step 2 below to check which Cilium version your cluster is currently running.

If your cluster is on 1.19.1 - go straight to 1.19.8 using the steps below.
If your cluster is on 1.16.1 - this is a multi-minor-version jump (1.16 → 1.17 → 1.18 → 1.19), and Cilium's own upgrade guide explicitly recommends against upgrading directly across minor versions. Step through each one instead:

1.16.1 → 1.16.19 → 1.17.18 → 1.18.14 → 1.19.8

ℹ️ Note: Confirm the exact latest patch for each branch at upgrade time, since Cilium ships patches frequently.

You can use the same steps below for each hop in this chain - repeat Steps 2 through 7, swapping in the next target version each time (e.g. run Step 4 with --version 1.16.19 first, verify, then repeat with --version 1.17.18, and so on).

Instructions

Step 1: Add the Cilium Helm Repository

Skip this step if the repository is already added.

helm repo add cilium https://helm.cilium.io/
helm repo update

Step 2: Check What the Cluster Is Currently Running

helm list -A | grep cilium

kubectl -n kube-system get deploy cilium-operator \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

kubectl -n kube-system get ds cilium \
  -o jsonpath='{.spec.template.spec.containers[?(@.name=="cilium-agent")].image}{"\n"}'

This confirms the current version and identifies whether images are sourced from quay.io (public) or a mirrored path.

ℹ️ Note: Proceed only if the Cilium images are sourced from quay.io.

Step 3: Capture the Cluster's Current Helm Values

helm get values -n kube-system cilium > cilium-values.yaml

Keep these values as they are - this file is what preserves the cluster's existing configuration through the upgrade.

If the output includes a header line like USER-SUPPLIED VALUES:, it's harmless as a top-level key and doesn't need to be removed, but you can delete it if you prefer a clean file.

Step 4: Upgrade the Helm Release to the Target Version

For example, if you're upgrading from 1.19.1 (current version) → 1.19.8 (target version):

helm upgrade -n kube-system cilium cilium/cilium \
  --version 1.19.8 \
  --values ./cilium-values.yaml

Passing the values file explicitly (rather than --reuse-values) ensures exactly the values captured in Step 3 are applied.

ℹ️ Note: Review any custom config you may have in your existing setup against the new version's values before applying.

Step 5: Restart the Cilium Operator

kubectl rollout restart -n kube-system deploy/cilium-operator

The operator only reads its config at startup, so a restart ensures it picks up the new release.

⚠️ Warning: Restarting the Cilium Operator will restart the CNI plugin, which may cause a temporary disruption to running workloads.

Step 6: Verify the Upgrade

kubectl -n kube-system get deploy cilium-operator \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

kubectl -n kube-system get ds cilium \
  -o jsonpath='{.spec.template.spec.containers[?(@.name=="cilium-agent")].image}{"\n"}'

Both should now show the target version.

Step 7: Confirm Agent Health

kubectl -n kube-system exec ds/cilium -c cilium-agent -- cilium-dbg status --brief

Expect OK.

Example

A team running a CMK cluster created before 1.19.1 became the default checks Step 2 and sees v1.16.1 in both the cilium-operator and cilium-agent image tags, pulled from quay.io. That puts them on the four-hop path.

They schedule a maintenance window with Crusoe Support, then work through Steps 2 to 7 once per hop: --version 1.16.19, then 1.17.18, then 1.18.14, then 1.19.8. They re-capture values in Step 3 before every hop and do not start the next hop until Step 6 shows the new tag and Step 7 reports OK.

A team on a newer cluster that Step 2 shows on v1.19.1 runs Steps 1 to 7 once with --version 1.19.8.

Additional Resources

Related to

cmk cilium helm security cmk-addon cve

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.