CVE-2026-44210 - Kata virtiofsd annotation VM escape

Kata Containers shipped a default annotation allowlist that let pod creators pass extra arguments to virtiofsd and add kernel parameters to the guest VM. When both annotation families are accepted, a low-privileged workload creator can override the virtiofs shared directory to the host root filesystem and enable the agent debug console. From inside the VM, that can expose host files and make host writes possible.

This is a container-boundary issue, not just a Go dependency alert. The fix needs to cover three layers: the Kata runtime version, the node or operator configuration that controls enable_annotations, and the Kubernetes admission boundary that decides which users may create pods using Kata RuntimeClasses.

GitHub Advisory Database currently scores the issue as Moderate with CVSS v4, while GitLab Advisory Database records CVSS 3.1 impact as High. This recipe treats it as high operational priority because a reachable default annotation path can cross from pod creation into host filesystem access.

When to use it

Use this recipe when a Kubernetes platform, container runtime fleet, or workload repository uses Kata Containers RuntimeClass with pod annotation allow-lists. It is built for platform/source remediation, container-boundary audit, admission-control review, and evidence that workload creators cannot inject virtiofsd or guest-kernel arguments that expose the host.

Inputs

  • Kata version, RuntimeClass definitions, operator/node configuration, annotation allow-lists, admission policies, and cluster workload ownership.
  • Manifests or policies that permit virtiofsd args, guest kernel args, debug console settings, shared directory overrides, or privileged workloads.
  • Regression fixtures for denied dangerous annotations, allowed safe annotations, low-privilege pod creators, and node rollout validation.
  • Boundary evidence: affected nodes, workloads using Kata, host filesystem exposure, admission logs, and runtime rollout owner.

Affected versions

Package/runtime Vulnerable versions Fixed versions
github.com/kata-containers/kata-containers <=3.29.0 in the upstream advisory; GitLab also reports pseudo-versions before 0.0.0-20260519062212-ffa59ce3aa78 3.31.0+ in the upstream advisory; GitLab lists 0.0.0-20260519062212-ffa59ce3aa78+

High-risk configuration:

  • enable_annotations allows virtio_fs_extra_args.
  • enable_annotations allows kernel_params.
  • Untrusted or tenant-scoped users can create pods against a Kata-backed RuntimeClass.
  • Admission policy does not reject io.katacontainers.config.hypervisor.virtio_fs_extra_args or io.katacontainers.config.hypervisor.kernel_params.

Indicator-of-exposure

  • The repository pins, builds, vendors, deploys, or configures Kata Containers at an affected version.
  • Kubernetes manifests, Helm charts, Terraform, GitOps overlays, node images, containerd templates, operator config, or runbooks enable Kata runtime classes.
  • Kata configuration.toml or rendered config includes virtio_fs_extra_args or kernel_params in enable_annotations.
  • Pod Security Admission, Gatekeeper, Kyverno, CEL admission, Validating Admission Policy, or custom admission webhooks do not deny the risky Kata annotations.
  • Tenants, CI jobs, notebooks, build systems, model-serving workloads, browser automation, or agent sandboxes can request Kata RuntimeClasses.

Quick checks:

rg -n "kata-containers|kata-runtime|containerd-shim-kata|io\\.containerd\\.kata|RuntimeClass|enable_annotations|virtio_fs_extra_args|kernel_params|io\\.katacontainers\\.config\\.hypervisor" .
rg -n "allowedAnnotations|forbiddenAnnotations|ValidatingAdmissionPolicy|Gatekeeper|ConstraintTemplate|Kyverno|pod-security|runtimeClassName" charts deploy k8s helm terraform .github .
go list -m all | rg '^github.com/kata-containers/kata-containers'

On nodes or rendered image roots controlled by this repository, inspect the effective Kata configuration:

kata-runtime --version
kata-runtime kata-env
rg -n "enable_annotations|virtio_fs_extra_args|kernel_params" /etc/kata-containers /opt/kata/share/defaults/kata-containers 2>/dev/null

Remediation strategy

  • Upgrade every controlled Kata runtime, module, node image, operator bundle, containerd shim, runtime-class package, and deployment artifact to the fixed release line. Prefer 3.31.0+ when tracking upstream tagged releases.
  • Regenerate node images, AMIs, SBOMs, lockfiles, deployment manifests, containerd configs, RuntimeClass definitions, and dependency reports.
  • Remove virtio_fs_extra_args and kernel_params from Kata enable_annotations unless a narrowly owned platform workflow still needs them and admission policy blocks tenant use.
  • Add or tighten admission policy so workload authors cannot set the risky io.katacontainers.config.hypervisor.* annotations.
  • Review who can create pods using Kata RuntimeClasses. Treat notebook users, CI workloads, build jobs, agent sandboxes, and model-serving tenants as untrusted unless they are explicitly platform-admin owned.
  • If the upgrade cannot deploy immediately, ship a containment-only change that removes both annotations from rendered Kata config, denies them at admission, blocks tenant access to affected RuntimeClasses, and schedules the fixed runtime rollout.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-44210 / GHSA-rr59-xxvx-96qr, a Kata Containers
VM escape through default-enabled `virtiofsd` and kernel-parameter pod
annotations. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades or contains affected Kata
  runtime configuration, adds admission/runtime-class guardrails, refreshes
  generated artifacts, and documents operator actions, or
- TRIAGE.md if this repository does not control a Kata runtime, node image,
  Kubernetes RuntimeClass, or admission policy surface.

## Rules

- Scope only CVE-2026-44210 / GHSA-rr59-xxvx-96qr and directly related Kata
  annotation, RuntimeClass, containerd, node-image, and admission controls.
- Do not run container-escape proof-of-concept payloads.
- Do not mount host filesystems, read `/etc/shadow`, write host paths, enable
  a real guest debug console, or test against production nodes.
- Treat kubeconfigs, service account tokens, registry credentials, node SSH
  keys, cloud instance credentials, model artifacts, tenant data, and host
  files as sensitive.
- Do not stop at a dependency bump if rendered node images, Kata configs,
  RuntimeClasses, admission policies, SBOMs, or GitOps overlays remain stale.
- Do not auto-merge.

## Steps

1. Inventory every Kata-controlled asset in the repository: Go modules,
   vendored code, release tarball pins, node-image build scripts, AMI/image
   templates, containerd configs, Kata `configuration.toml`, operator values,
   Helm charts, Kubernetes manifests, RuntimeClasses, Terraform, GitOps
   overlays, admission policies, SBOMs, dependency reports, CI jobs, and
   runbooks.
2. Determine the effective Kata version for each controlled target. Treat
   upstream releases through `3.29.0` as affected unless the repository carries
   a documented backport of the fix. Prefer upgrading to `3.31.0+`.
3. Inspect every rendered and source Kata config for `enable_annotations`.
   Flag exposure when `virtio_fs_extra_args` or `kernel_params` is allowed.
4. Search all Kubernetes and policy assets for the risky annotation keys:
   `io.katacontainers.config.hypervisor.virtio_fs_extra_args` and
   `io.katacontainers.config.hypervisor.kernel_params`.
5. Map who can create pods with Kata RuntimeClasses: platform admins, tenants,
   CI systems, notebooks, build workers, model-serving jobs, browser or agent
   sandboxes, and any self-service workload channel.
6. If this repository does not control Kata runtime, node image, RuntimeClass,
   or admission policy assets, stop with `TRIAGE.md` listing checked paths, the
   likely runtime owner, the fixed target `3.31.0+`, and the required
   containment for both risky annotations.
7. Upgrade controlled Kata runtime pins to the fixed line and refresh module
   files, checksums, release artifact hashes, node images, SBOMs, dependency
   reports, and rendered deployment artifacts.
8. Remove `virtio_fs_extra_args` and `kernel_params` from controlled
   `enable_annotations` by default. If a platform-owned workflow requires one,
   document the owner and require admission policy that denies tenant-supplied
   values.
9. Add admission guardrails for every cluster policy system controlled here:
   deny pods carrying either risky Kata annotation unless a tightly scoped,
   platform-owned exemption is present; add tests or policy fixtures for
   ordinary tenants and privileged platform namespaces.
10. Tighten RuntimeClass access where this repository controls RBAC or
    namespace policy. Tenants, CI jobs, notebooks, model serving, and agent
    sandboxes should not be able to select affected Kata RuntimeClasses until
    runtime and annotation containment are deployed.
11. Add safe verification:
    - static checks prove fixed Kata versions or documented backports;
    - rendered `configuration.toml` omits both risky annotations;
    - admission-policy tests reject pods with both annotation keys;
    - RuntimeClass/RBAC fixtures show untrusted namespaces cannot request the
      affected runtime;
    - SBOMs and image manifests reflect regenerated fixed artifacts.
12. Add a PR body section named `CVE-2026-44210 operator actions` that states:
    - Kata versions before and after;
    - which nodes/images/runtime configs were regenerated;
    - whether `virtio_fs_extra_args` and `kernel_params` were removed from
      `enable_annotations`;
    - which admission policies reject the risky annotations;
    - which RuntimeClasses and namespaces were reviewed;
    - whether any tenant or CI workload could previously create affected pods;
    - whether node credential, registry credential, kubelet credential, or
      workload-secret review is required for the vulnerable window.
13. Run available validation: Go dependency resolution, image build, containerd
    config rendering, Helm/Kustomize/Terraform rendering, admission policy unit
    tests, Kubernetes schema validation, SBOM refresh, dependency/security
    scans, and CI workflow checks.
14. Use PR title:
    `fix(sec): remediate CVE-2026-44210 in Kata runtime annotations`.

## Stop conditions

- No Kata Containers runtime, RuntimeClass, node image, containerd/Kata config,
  or admission policy is controlled by this repository.
- The repository only deploys workloads onto a platform-managed Kata runtime;
  document the platform owner and required containment.
- Safe remediation requires a cluster-ownership decision about who may use Kata
  RuntimeClasses; write `TRIAGE.md` with the exact decision needed.
- Verification would require running a container escape, mounting host
  filesystems, reading host secrets, or changing production node config.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Kata, removes dangerous annotation allowances, adds RuntimeClass/admission regression checks, and documents node rollout.
  • Or a TRIAGE.md file that lists inspected manifests/config, owner, observed version, annotation boundary, affected workloads, required fix, and residual risk.
  • The output must include exact validation commands and must not expose host files, enable debug consoles on production nodes, or run escape payloads.

Verification - what the reviewer looks for

  • No controlled dependency, runtime pin, node image, SBOM, or generated deployment artifact remains on an affected Kata release unless a documented backport is present.
  • Rendered Kata config no longer allows tenant-supplied virtio_fs_extra_args or kernel_params.
  • Admission tests reject pods that set the risky Kata annotation keys.
  • RuntimeClass access is limited to the intended platform-owned namespaces or service accounts.
  • The PR body names any node, credential, or workload-secret review required for clusters that ran affected config.

Watch for

  • Fixing Go module pins while node images or release tarball checksums still install older Kata binaries.
  • Removing one risky annotation while leaving the other enabled.
  • Admission policy that only checks one namespace, one API version, or one RuntimeClass name while tenants can use aliases.
  • Treating “Kata is a sandbox” as sufficient when workload authors can pass hypervisor annotations.
  • Running the public PoC in a shared cluster instead of using static config and admission-policy tests.

References