dbcve.org
KubevirtApplication

CVE-2023-26484

HIGH · 8.2 CVSS v3.1 Published 2023-03-15
Fix available
A fix is available. Upgrade to after 0.59.0 or later.
See remediation →
88/100
Remediation priority · High
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
KubeVirt is a virtual machine management add-on for Kubernetes. In versions 0.59.0 and prior, if a malicious user has taken over a Kubernetes node where virt-handler (the KubeVirt node-daemon) is running, the virt-handler service account can be used to modify all node specs. This can be misused to lure-in system-level-privileged components which can, for instance, read all secrets on the cluster, or can exec into pods on other nodes. This way, a compromised node can be used to elevate privileges beyond the node until potentially having full privileged access to the whole cluster. The simplest way to exploit this, once a user could compromise a specific node, is to set with the virt-handler service account all other nodes to unschedulable and simply wait until system-critical components with high privileges appear on its node. No patches are available as of time of publication. As a workaround, gatekeeper users can add a webhook which will block the `virt-handler` service account to modify the spec of a node.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

KubeVirt versions 0.59.0 and prior contain a privilege escalation vulnerability where a compromised node running virt-handler can use its service account to modify all node specs. An attacker can mark other nodes as unschedulable, forcing privileged system components to schedule on the compromised node where they can be read or exec'd into, potentially gaining full cluster access.

MitigationImplement a Gatekeeper (OPA) admission controller webhook to block the virt-handler service account from modifying node specs, as no vendor patch is currently available.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
KubevirtApplication
Affected:<= 0.59.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
High
Privileges
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check if KubeVirt is installed
    Run `kubectl get kubevirt -A` or check for the kubevirt namespace
    Affected if KubeVirt is not installed then the environment is not affected
  2. Determine the installed KubeVirt version
    Run `kubectl get kubevirt -n kubevirt -o jsonpath='{.items[0].status.observedVersion}'` or check the KubeVirt operator version
    Affected if The installed version is 0.59.0 or lower, proceed to next checks; if version is higher, the environment is not affected by this CVE
  3. Verify virt-handler is running
    Run `kubectl get pods -n kubevirt -l app=virt-handler` to confirm the virt-handler daemonset is deployed
    Affected if If virt-handler is not present, the specific vulnerable component is not in use; however, the version check still applies for complete assessment
  4. Check if virt-handler service account can modify node resources
    Run `kubectl auth can-i update nodes --as=system:serviceaccount:kubevirt:virt-handler` or examine the ClusterRoleBinding for the virt-handler service account
    Affected if If the service account has permissions to update/modify node specs, the environment is vulnerable to the privilege escalation described in this CVE

The environment is affected if KubeVirt version 0.59.0 or lower is installed AND the virt-handler service account has permissions to modify node specifications.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to a release after 0.59.0
Interim mitigation

Implement a Gatekeeper (OPA) admission controller webhook to block the virt-handler service account from modifying node specs, as no vendor patch is currently available.

Recommended fix High confidence
  1. 1. Deploy OPA Gatekeeper or a similar admission controller in the Kubernetes cluster if not already present.
  2. 2. Create a Gatekeeper ConstraintTemplate for validating node spec modifications (or use an existing mutate or validate webhook).
  3. 3. Configure the constraint to block or audit operations where the virt-handler service account attempts to modify the spec of any Node resource.
  4. 4. Apply the Gatekeeper constraint to enforce the policy cluster-wide.
  5. 5. Verify the policy blocks virt-handler from modifying node specs by testing with a dry-run or observing admission webhook logs.

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Kubevirt Scoped from the published advisory
  • Consultation6.0 h
  • Implementation12.0 h
  • Testing8.0 h
  • Review / QA4.0 h
30.0 hours of engineering $5,280
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $8,448.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2023-26484 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2023-26484 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data