cvelistv5 - cve-2023-26484

cve-2023-26484

Vulnerability from cvelistv5

Published

2023-03-15 20:40

Modified

2024-08-02 11:53

Severity ?

8.2 (High) - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

Summary

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.

References

URL	Tags
security-advisories@github.com	https://github.com/kubevirt/kubevirt/issues/9109	Issue Tracking, Third Party Advisory
security-advisories@github.com	https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2	Mitigation, Vendor Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/kubevirt/kubevirt/issues/9109	Issue Tracking, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2	Mitigation, Vendor Advisory

Impacted products

	Vendor	Product	Version
	kubevirt	kubevirt	Version: <= 0.59.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T11:53:54.297Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2",
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
          },
          {
            "name": "https://github.com/kubevirt/kubevirt/issues/9109",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/kubevirt/kubevirt/issues/9109"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "kubevirt",
          "vendor": "kubevirt",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c= 0.59.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-863",
              "description": "CWE-863: Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2023-03-15T20:40:17.424Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
        },
        {
          "name": "https://github.com/kubevirt/kubevirt/issues/9109",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/kubevirt/kubevirt/issues/9109"
        }
      ],
      "source": {
        "advisory": "GHSA-cp96-jpmq-xrr2",
        "discovery": "UNKNOWN"
      },
      "title": "On a compromised KubeVirt node, the virt-handler service account can be used to modify all node specs"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2023-26484",
    "datePublished": "2023-03-15T20:40:17.424Z",
    "dateReserved": "2023-02-23T23:22:58.575Z",
    "dateUpdated": "2024-08-02T11:53:54.297Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-26484\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2023-03-15T21:15:08.857\",\"lastModified\":\"2024-11-21T07:51:36.837\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N\",\"baseScore\":8.2,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":1.8,\"impactScore\":5.8},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N\",\"baseScore\":8.2,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":1.8,\"impactScore\":5.8}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-863\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:kubevirt:kubevirt:*:*:*:*:*:kubernetes:*:*\",\"versionEndIncluding\":\"0.59.0\",\"matchCriteriaId\":\"B0C470F6-1D95-437E-9A57-D0075ED16482\"}]}]}],\"references\":[{\"url\":\"https://github.com/kubevirt/kubevirt/issues/9109\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Issue Tracking\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Mitigation\",\"Vendor Advisory\"]},{\"url\":\"https://github.com/kubevirt/kubevirt/issues/9109\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Issue Tracking\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Mitigation\",\"Vendor Advisory\"]}]}}"
  }
}

ghsa-cp96-jpmq-xrr2

Vulnerability from github

Published

2023-03-16 16:04

Modified

2023-03-27 22:24

Severity ?

8.2 (High) - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

Summary

On a compromised node, the virt-handler service account can be used to modify all node specs

Details

Impact

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.

Since this requires a node to be compromised first, the severity of this finding is considered Medium.

Patches

Not yet available.

Workarounds

Gatekeeper users can add a webhook which will block the virt-handler service account to modify the spec of a node.

An example policy, preventing virt-handler from changing the node spec may look like this:

```yaml apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: virthandlerrestrictions spec: [...] targets: - libs: - |
[...]
is_virt_handler(username) { username == "system:serviceaccount:kubevirt:virt-handler" } mutates_node_in_unintended_way { # TODO # only allow kubevirt.io/ prefixed metadata node changes } rego: | [...]

    violation[{"msg": msg}] {
      is_virt_handler(username)
      mutates_node_in_unintended_way(input.review.object, input.review.oldObject)
      msg := sprintf("virt-handler tries to modify node <%v> in an unintended way.", [input.review.object.name])
    }

```

and applying this template to node modifications.

Credits

Special thanks to the discoverers of this issue:

Nanzi Yang (nzyang@stu.xidian.edu.cn) Xin Guo (guox@stu.xidian.edu.cn) Jietao Xiao (jietaoXiao@stu.xidian.edu.cn) Wenbo Shen (shenwenbo@zju.edu.cn) Jinku Li (jkli@xidian.edu.cn)

References

https://github.com/kubevirt/kubevirt/issues/9109

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "kubevirt.io/kubevirt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.59.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-16T16:04:42Z",
    "nvd_published_at": "2023-03-15T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nIf 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.\n\nThis 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.\n\nThe 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.\n\nSince this requires a node to be compromised first, the severity of this finding is considered Medium.\n\n### Patches\n\nNot yet available.\n\n### Workarounds\nGatekeeper users can add a webhook which will block the `virt-handler` service account to modify the spec of a node.\n\nAn example policy, preventing virt-handler from changing the node spec may look like this:\n\n```yaml\napiVersion: templates.gatekeeper.sh/v1\nkind: ConstraintTemplate\nmetadata:\n  name: virthandlerrestrictions\nspec:\n[...]\n  targets:\n    - libs:\n        - |         \n[...]          \n          is_virt_handler(username) {\n              username == \"system:serviceaccount:kubevirt:virt-handler\"\n          }\n          mutates_node_in_unintended_way {\n            # TODO\n            # only allow kubevirt.io/ prefixed metadata node changes\n          }\n      rego: |\n[...]\n        \n        violation[{\"msg\": msg}] {\n          is_virt_handler(username)\n          mutates_node_in_unintended_way(input.review.object, input.review.oldObject)\n          msg := sprintf(\"virt-handler tries to modify node \u003c%v\u003e in an unintended way.\", [input.review.object.name])\n        }\n```\n\nand applying this template to node modifications.\n\n\n### Credits\n\nSpecial thanks to the discoverers of this issue:\n\nNanzi Yang (nzyang@stu.xidian.edu.cn)\nXin Guo (guox@stu.xidian.edu.cn)\nJietao Xiao (jietaoXiao@stu.xidian.edu.cn)\nWenbo Shen (shenwenbo@zju.edu.cn)\nJinku Li (jkli@xidian.edu.cn)\n\n### References\n\nhttps://github.com/kubevirt/kubevirt/issues/9109",
  "id": "GHSA-cp96-jpmq-xrr2",
  "modified": "2023-03-27T22:24:34Z",
  "published": "2023-03-16T16:04:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26484"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/issues/9109"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubevirt/kubevirt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "On a compromised node, the virt-handler service account can be used to modify all node specs"
}

gsd-2023-26484

Vulnerability from gsd

Modified

2023-12-13 01:20

Details

Aliases

CVE-2023-26484

Aliases

CVE-2023-26484

JSON

To clipboard

{
  "GSD": {
    "alias": "CVE-2023-26484",
    "id": "GSD-2023-26484"
  },
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2023-26484"
      ],
      "details": "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.",
      "id": "GSD-2023-26484",
      "modified": "2023-12-13T01:20:53.607846Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "security-advisories@github.com",
        "ID": "CVE-2023-26484",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "kubevirt",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "=",
                          "version_value": "\u003c= 0.59.0"
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": "kubevirt"
            }
          ]
        }
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "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."
          }
        ]
      },
      "impact": {
        "cvss": [
          {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          }
        ]
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "cweId": "CWE-863",
                "lang": "eng",
                "value": "CWE-863: Incorrect Authorization"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://github.com/kubevirt/kubevirt/issues/9109",
            "refsource": "MISC",
            "url": "https://github.com/kubevirt/kubevirt/issues/9109"
          },
          {
            "name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2",
            "refsource": "MISC",
            "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
          }
        ]
      },
      "source": {
        "advisory": "GHSA-cp96-jpmq-xrr2",
        "discovery": "UNKNOWN"
      }
    },
    "gitlab.com": {
      "advisories": [
        {
          "affected_range": "\u003c=0.59.0",
          "affected_versions": "All versions up to 0.59.0",
          "cvss_v3": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
          "cwe_ids": [
            "CWE-1035",
            "CWE-863",
            "CWE-937"
          ],
          "date": "2023-03-27",
          "description": "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.",
          "fixed_versions": [],
          "identifier": "CVE-2023-26484",
          "identifiers": [
            "CVE-2023-26484",
            "GHSA-cp96-jpmq-xrr2"
          ],
          "not_impacted": "",
          "package_slug": "go/github.com/kubevirt/kubevirt",
          "pubdate": "2023-03-15",
          "solution": "Unfortunately, there is no solution available yet.",
          "title": "Incorrect Authorization",
          "urls": [
            "https://nvd.nist.gov/vuln/detail/CVE-2023-26484",
            "https://github.com/kubevirt/kubevirt/issues/9109",
            "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
          ],
          "uuid": "0425f36b-7efa-4f9c-8c49-fd5a5b4cd797"
        },
        {
          "affected_range": "\u003c=0.59.0",
          "affected_versions": "All versions up to 0.59.0",
          "cwe_ids": [
            "CWE-1035",
            "CWE-863",
            "CWE-937"
          ],
          "date": "2023-03-16",
          "description": "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.",
          "fixed_versions": [],
          "identifier": "CVE-2023-26484",
          "identifiers": [
            "GHSA-cp96-jpmq-xrr2",
            "CVE-2023-26484"
          ],
          "not_impacted": "",
          "package_slug": "go/kubevirt.io/kubevirt",
          "pubdate": "2023-03-16",
          "solution": "Unfortunately, there is no solution available yet.",
          "title": "Incorrect Authorization",
          "urls": [
            "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2",
            "https://nvd.nist.gov/vuln/detail/CVE-2023-26484",
            "https://github.com/kubevirt/kubevirt/issues/9109",
            "https://github.com/advisories/GHSA-cp96-jpmq-xrr2"
          ],
          "uuid": "51bc48c3-8d01-4292-bda2-9921cac4f179"
        }
      ]
    },
    "nvd.nist.gov": {
      "configurations": {
        "CVE_data_version": "4.0",
        "nodes": [
          {
            "children": [],
            "cpe_match": [
              {
                "cpe23Uri": "cpe:2.3:a:kubevirt:kubevirt:*:*:*:*:*:kubernetes:*:*",
                "cpe_name": [],
                "versionEndIncluding": "0.59.0",
                "vulnerable": true
              }
            ],
            "operator": "OR"
          }
        ]
      },
      "cve": {
        "CVE_data_meta": {
          "ASSIGNER": "security-advisories@github.com",
          "ID": "CVE-2023-26484"
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "en",
              "value": "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."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "en",
                  "value": "CWE-863"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://github.com/kubevirt/kubevirt/issues/9109",
              "refsource": "MISC",
              "tags": [
                "Issue Tracking",
                "Third Party Advisory"
              ],
              "url": "https://github.com/kubevirt/kubevirt/issues/9109"
            },
            {
              "name": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2",
              "refsource": "MISC",
              "tags": [
                "Mitigation",
                "Vendor Advisory"
              ],
              "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
            }
          ]
        }
      },
      "impact": {
        "baseMetricV3": {
          "cvssV3": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "exploitabilityScore": 1.8,
          "impactScore": 5.8
        }
      },
      "lastModifiedDate": "2023-03-27T16:58Z",
      "publishedDate": "2023-03-15T21:15Z"
    }
  }
}

fkie_cve-2023-26484

Vulnerability from fkie_nvd

Published

2023-03-15 21:15

Modified

2024-11-21 07:51

Severity ?

8.2 (High) - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
8.2 (High) - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

Summary

References

URL	Tags
security-advisories@github.com	https://github.com/kubevirt/kubevirt/issues/9109	Issue Tracking, Third Party Advisory
security-advisories@github.com	https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2	Mitigation, Vendor Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/kubevirt/kubevirt/issues/9109	Issue Tracking, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2	Mitigation, Vendor Advisory

Impacted products

	Vendor	Product	Version
	kubevirt	kubevirt	*

JSON

To clipboard

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:kubevirt:kubevirt:*:*:*:*:*:kubernetes:*:*",
              "matchCriteriaId": "B0C470F6-1D95-437E-9A57-D0075ED16482",
              "versionEndIncluding": "0.59.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    }
  ],
  "id": "CVE-2023-26484",
  "lastModified": "2024-11-21T07:51:36.837",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.8,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.8,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2023-03-15T21:15:08.857",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Issue Tracking",
        "Third Party Advisory"
      ],
      "url": "https://github.com/kubevirt/kubevirt/issues/9109"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Issue Tracking",
        "Third Party Advisory"
      ],
      "url": "https://github.com/kubevirt/kubevirt/issues/9109"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-863"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
Confirmed: The vulnerability is confirmed from an analyst perspective.
Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
Patched: This vulnerability was successfully patched by the user reporting the sighting.
Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
Not confirmed: The user expresses doubt about the veracity of the vulnerability.
Not patched: This vulnerability was not successfully patched by the user reporting the sighting.

Action not permitted

cve-2023-26484

Vulnerability from cvelistv5

ghsa-cp96-jpmq-xrr2

Vulnerability from github

Impact

Patches

Workarounds

Credits

References

gsd-2023-26484

Vulnerability from gsd

fkie_cve-2023-26484

Vulnerability from fkie_nvd

Tags

Sightings

Nomenclature