CVE-2026-32241

What it actually does

CVE-2026-32241 is a command injection vulnerability in Flannel versions prior to 0.28.2 when the experimental Extension backend is enabled. An attacker with Kubernetes permissions to modify Node annotations can place attacker-controlled content in the `flannel.alpha.coreos.com/backend-data` annotation. Flannel passes this data through the Extension backend `SubnetAddCommand` or `SubnetRemoveCommand` path into a shell command without sufficient validation, allowing arbitrary commands to execute with root-level privileges on affected Flannel nodes. Standard Flannel backends such as `vxlan` and `wireguard` are not affected.

Why it matters to the business

A compromised low-privilege Kubernetes identity with permission to edit Node annotations could be escalated into root-level code execution across nodes running the vulnerable Flannel Extension backend. This can lead to cluster-wide service disruption, theft of workloads or secrets accessible from nodes, deployment of persistence or cryptominers, and potential lateral movement into connected infrastructure. The issue is not currently listed in CISA KEV, has no known mature public exploit reported in the supplied data, and has a low EPSS score with a flat 30-day trend, but the impact is severe for clusters using the experimental Extension backend.

How an attack unfolds

An attacker first obtains Kubernetes credentials or compromises a workload, service account, or user with permission to update or patch Node objects. The attacker identifies that Flannel is deployed and configured to use the experimental Extension backend. They then modify a Kubernetes Node annotation, specifically `flannel.alpha.coreos.com/backend-data`, so that data consumed by Flannel includes command content that reaches the Extension backend command execution path. When Flannel processes subnet add or remove events, the vulnerable `SubnetAddCommand` or `SubnetRemoveCommand` handling unmarshals the annotation content and passes it into a shell without adequate validation. The injected command executes as root in the Flannel node context, allowing the attacker to run arbitrary commands on affected nodes and potentially repeat the action across the cluster.

How to fix it

Upgrade Flannel to version 0.28.2 or later. If immediate upgrade is not possible, stop using the experimental Extension backend and reconfigure Flannel to use an unaffected backend such as `vxlan` or `wireguard`. Remove or tightly restrict any Kubernetes RBAC permissions that allow users, service accounts, controllers, or workloads to update or patch Node objects or Node annotations. Review admission control policies to block unauthorized changes to `flannel.alpha.coreos.com/backend-data`. Restart or roll out Flannel components after upgrading or changing backend configuration to ensure all nodes are running the fixed or unaffected configuration.

How to confirm the fix worked

Confirm the running Flannel version on every node is 0.28.2 or later, or confirm the cluster is not using the Extension backend. Inspect Flannel ConfigMaps, manifests, DaemonSets, and container arguments for backend configuration and ensure `extension` is not in use unless Flannel has been upgraded. Enumerate Node annotations and verify that `flannel.alpha.coreos.com/backend-data` is absent or contains only expected benign configuration. Review Kubernetes RBAC to ensure only highly trusted control-plane identities can patch or update Node resources. Test admission controls by attempting to modify the annotation from a non-administrative identity and confirming the request is denied. After remediation, verify Flannel pods have been restarted and are running the intended image version across all nodes.

Typical attack path

1. Obtain Kubernetes credentials or compromise an identity with permission to patch or update Node objects.
2. Confirm Flannel is deployed and using the experimental Extension backend rather than unaffected backends such as vxlan or wireguard.
3. Modify the `flannel.alpha.coreos.com/backend-data` Node annotation with attacker-controlled content.
4. Trigger or wait for Flannel subnet add/remove processing to consume the modified annotation.
5. Achieve root-level command execution through the vulnerable Extension backend command path on affected Flannel nodes.
6. Use node-level execution to collect secrets, disrupt networking, deploy persistence, or move laterally within the cluster.

How to detect it

To determine whether exploitation already occurred, review Kubernetes API audit logs for `patch` or `update` operations against Node resources, especially changes to the `flannel.alpha.coreos.com/backend-data` annotation. Pay close attention to non-administrative users, service accounts, CI/CD identities, or workload identities modifying Node annotations. Examine Flannel pod logs and node system logs around the same timestamps for subnet add/remove activity, Extension backend execution, shell invocation errors, or unexpected command output. On nodes, use EDR, auditd, eBPF telemetry, or container runtime logs to identify shell processes or unusual utilities spawned by the Flannel process or container. Investigate signs of post-exploitation such as new privileged containers, modified host files, unexpected cron/systemd entries, dropped binaries, cryptomining processes, outbound connections to unfamiliar infrastructure, or Kubernetes secret access following the annotation change. Because the payload is attacker-controlled, there is no single universal command IOC; the strongest detection pivots are suspicious writes to the Flannel backend-data annotation and unexpected process execution from Flannel.

• flannel.alpha.coreos.com/backend-data
• SubnetAddCommand
• SubnetRemoveCommand
• flanneld
• verb=patch objectRef.resource=nodes
• verb=update objectRef.resource=nodes
• patch nodes
• update nodes
• /api/v1/nodes/
• backend-data
• extension
• /bin/sh
• /bin/bash

What your security team should do

• Prioritize clusters that run Flannel with the experimental Extension backend; these are the affected deployments.
• Upgrade Flannel to 0.28.2 or later, or migrate immediately to an unaffected backend such as vxlan or wireguard.
• Audit Kubernetes RBAC for any identity with `update` or `patch` permissions on `nodes` and remove unnecessary access.
• Add an admission policy to block unauthorized writes to `flannel.alpha.coreos.com/backend-data`.
• Search Kubernetes audit logs for recent Node annotation changes involving `flannel.alpha.coreos.com/backend-data`.
• Investigate affected nodes for unexpected child processes spawned from Flannel, suspicious shell execution, persistence artifacts, or unexplained network connections.
• If suspicious annotation changes are found, treat affected nodes as potentially compromised and rotate Kubernetes credentials and secrets that may have been exposed from those nodes.