CWE-829
AllowedInclusion of Functionality from Untrusted Control Sphere
Abstraction: Base · Status: Incomplete
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
393 vulnerabilities reference this CWE, most recent first.
GHSA-M98H-48V7-G4F9
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14The wp-publications WordPress plugin is vulnerable to restrictive local file inclusion via the Q_FILE parameter found in the ~/bibtexbrowser.php file which allows attackers to include local zip files and achieve remote code execution, in versions up to and including 0.0.
{
"affected": [],
"aliases": [
"CVE-2021-38360"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-10T14:15:00Z",
"severity": "HIGH"
},
"details": "The wp-publications WordPress plugin is vulnerable to restrictive local file inclusion via the Q_FILE parameter found in the ~/bibtexbrowser.php file which allows attackers to include local zip files and achieve remote code execution, in versions up to and including 0.0.",
"id": "GHSA-m98h-48v7-g4f9",
"modified": "2022-05-24T19:14:09Z",
"published": "2022-05-24T19:14:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38360"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-publications/trunk/bibtexbrowser.php?rev=1830330#L49"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/vulnerability-advisories/#CVE-2021-38360"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-MC84-XR9P-938R
Vulnerability from github – Published: 2019-09-23 18:31 – Updated: 2021-09-15 18:50Generated code uses repository configuration that downloads over HTTP instead of HTTPS
Impact
Gradle users were using the http://repo.spring.io/plugins-release repositories in plain HTTP, and not HTTPS, so a man-in-the-middle attack was possible at build time.
Patches
Maven users should at least upgrade to 6.3.0 while Gradle users should update to 6.3.1.
If you are not able to upgrade make sure not to use a Maven repository via http in your build file.
Workarounds
Replace all custom repository definitions in build.gradle or pom.xml with their https version.
e.g.
<repository>
<id>oss.sonatype.org-snapshot</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url> // <-- must be httpS
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
maven { url "https://repo.spring.io/plugins-release" } // <-- must be httpS
References
- https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
- https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/
For more information
If you have any questions or comments about this advisory: * Open an issue in https://github.com/jhipster/generator-jhipster/issues
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "generator-jhipster"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-494",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:45:50Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Generated code uses repository configuration that downloads over HTTP instead of HTTPS\n\n### Impact\nGradle users were using the http://repo.spring.io/plugins-release repositories in plain HTTP, and not HTTPS, so a man-in-the-middle attack was possible at build time.\n\n### Patches\n\nMaven users should at least upgrade to 6.3.0 while Gradle users should update to 6.3.1.\nIf you are not able to upgrade make sure not to use a Maven repository via `http` in your build file.\n\n### Workarounds\n\nReplace all custom repository definitions in `build.gradle` or `pom.xml` with their `https` version.\n\ne.g.\n\n```xml\n \u003crepository\u003e\n \u003cid\u003eoss.sonatype.org-snapshot\u003c/id\u003e\n \u003curl\u003ehttps://oss.sonatype.org/content/repositories/snapshots\u003c/url\u003e // \u003c-- must be httpS\n \u003creleases\u003e\n \u003cenabled\u003efalse\u003c/enabled\u003e\n \u003c/releases\u003e\n \u003csnapshots\u003e\n \u003cenabled\u003etrue\u003c/enabled\u003e\n \u003c/snapshots\u003e\n\u003c/repository\u003e\n```\n\n```gradle\nmaven { url \"https://repo.spring.io/plugins-release\" } // \u003c-- must be httpS\n```\n\n### References\n* https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H\n* https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [https://github.com/jhipster/generator-jhipster/issues](https://github.com/jhipster/generator-jhipster/issues)\n\n",
"id": "GHSA-mc84-xr9p-938r",
"modified": "2021-09-15T18:50:22Z",
"published": "2019-09-23T18:31:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jhipster/generator-jhipster/security/advisories/GHSA-mc84-xr9p-938r"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-mc84-xr9p-938r"
},
{
"type": "WEB",
"url": "https://github.com/jhipster/generator-jhipster"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-GENERATORJHIPSTER-536074"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "High severity vulnerability that affects generator-jhipster"
}
GHSA-MJ59-H3Q9-GHFH
Vulnerability from github – Published: 2026-04-25 23:48 – Updated: 2026-05-19 15:56Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
< 2026.4.20 - Patched version:
2026.4.20
Impact
Workspace MCP stdio configuration could pass dangerous process-startup environment variables such as NODE_OPTIONS, LD_PRELOAD, or BASH_ENV to the spawned MCP server process. In a malicious workspace, this could make the MCP child load attacker-controlled code when the operator starts a session that uses that MCP server.
The impact is limited to local/workspace trust boundaries and requires the operator to run OpenClaw in a workspace containing the malicious MCP configuration. Severity is therefore medium, not high/critical.
Fix
OpenClaw now filters MCP stdio environment entries through the host environment safety denylist before spawning stdio MCP servers.
Fix commits:
62fa5071896e95edc7f67d1cebc70a2859e283af85d86ebc4bf3d2226d39d132a484f4f7a299fa1b
Release
Fixed in OpenClaw 2026.4.20.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44995"
],
"database_specific": {
"cwe_ids": [
"CWE-427",
"CWE-454",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:48:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c 2026.4.20`\n- Patched version: `2026.4.20`\n\n## Impact\n\nWorkspace MCP stdio configuration could pass dangerous process-startup environment variables such as `NODE_OPTIONS`, `LD_PRELOAD`, or `BASH_ENV` to the spawned MCP server process. In a malicious workspace, this could make the MCP child load attacker-controlled code when the operator starts a session that uses that MCP server.\n\nThe impact is limited to local/workspace trust boundaries and requires the operator to run OpenClaw in a workspace containing the malicious MCP configuration. Severity is therefore medium, not high/critical.\n\n## Fix\n\nOpenClaw now filters MCP stdio environment entries through the host environment safety denylist before spawning stdio MCP servers.\n\nFix commits:\n\n- `62fa5071896e95edc7f67d1cebc70a2859e283af`\n- `85d86ebc4bf3d2226d39d132a484f4f7a299fa1b`\n\n## Release\n\nFixed in OpenClaw `2026.4.20`.",
"id": "GHSA-mj59-h3q9-ghfh",
"modified": "2026-05-19T15:56:20Z",
"published": "2026-04-25T23:48:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-mj59-h3q9-ghfh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44995"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/62fa5071896e95edc7f67d1cebc70a2859e283af"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/85d86ebc4bf3d2226d39d132a484f4f7a299fa1b"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-arbitrary-code-execution-via-mcp-stdio-environment-variables"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: MCP stdio server env could load dangerous startup variables from workspace config"
}
GHSA-MJ72-XC2R-JG2M
Vulnerability from github – Published: 2026-03-09 18:31 – Updated: 2026-03-11 15:31An issue pertaining to CWE-829: Inclusion of Functionality from Untrusted Control Sphere was discovered in Miazzy oa-front-service master.
{
"affected": [],
"aliases": [
"CVE-2025-70046"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-09T16:16:15Z",
"severity": "CRITICAL"
},
"details": "An issue pertaining to CWE-829: Inclusion of Functionality from Untrusted Control Sphere was discovered in Miazzy oa-front-service master.",
"id": "GHSA-mj72-xc2r-jg2m",
"modified": "2026-03-11T15:31:37Z",
"published": "2026-03-09T18:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-70046"
},
{
"type": "WEB",
"url": "https://gist.github.com/zcxlighthouse/a29d9de46c4eac2de5c4d5a7b6c6c532"
},
{
"type": "WEB",
"url": "https://github.com/Miazzy"
},
{
"type": "WEB",
"url": "https://github.com/Miazzy/oa-front-service"
}
],
"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"
}
]
}
GHSA-MPM8-CX2P-626Q
Vulnerability from github – Published: 2026-05-08 18:46 – Updated: 2026-05-13 13:32Impact
Arbitrary local code execution via deep links, CLI --opts, or crafted shortcuts. Affected users: electerm installs that accept protocol URLs or CLI options (affected versions listed in the original report). Exploit requires clicking a crafted electerm://... link or opening a crafted shortcut/command that launches electerm with attacker-controlled opts.
Patches
Fixed in version > 3.8.8
commits:
- https://github.com/electerm/electerm/commit/8a6a17951e96d715f5a231532bbd8303fe208700
- https://github.com/electerm/electerm/commit/a79e06f4a1f0ac6376c3d2411ef4690fa0377742
- https://github.com/electerm/electerm/commit/0599e67069b00e376a2e962649aaad6096e63507
Workarounds
- Disable or unregister electerm protocol handlers (Deep Link settings) and avoid clicking
electerm://links. - Do not run electerm with untrusted
--optsarguments or open.lnk/.desktopfiles from untrusted sources. - Restrict which users can launch electerm on shared machines and avoid leaving electerm installed in locations reachable by other users.
- As a temporary measure, run electerm in a confined account or sandbox (non-admin user) to reduce impact.
References
- Report / credit: https://github.com/Curly-Haired-Baboon
- Electerm releases: https://github.com/electerm/electerm/releases
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "electerm"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.6"
},
{
"fixed": "3.8.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43944"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-829",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T18:46:04Z",
"nvd_published_at": "2026-05-08T04:16:24Z",
"severity": "CRITICAL"
},
"details": "### Impact\n_Arbitrary local code execution via deep links, CLI `--opts`, or crafted shortcuts. Affected users: electerm installs that accept protocol URLs or CLI options (affected versions listed in the original report). Exploit requires clicking a crafted `electerm://...` link or opening a crafted shortcut/command that launches electerm with attacker-controlled `opts`._\n\n### Patches\nFixed in version \u003e 3.8.8\n\ncommits:\n\n- https://github.com/electerm/electerm/commit/8a6a17951e96d715f5a231532bbd8303fe208700\n- https://github.com/electerm/electerm/commit/a79e06f4a1f0ac6376c3d2411ef4690fa0377742\n- https://github.com/electerm/electerm/commit/0599e67069b00e376a2e962649aaad6096e63507\n\n### Workarounds\n- Disable or unregister electerm protocol handlers (Deep Link settings) and avoid clicking `electerm://` links.\n- Do not run electerm with untrusted `--opts` arguments or open `.lnk` / `.desktop` files from untrusted sources.\n- Restrict which users can launch electerm on shared machines and avoid leaving electerm installed in locations reachable by other users.\n- As a temporary measure, run electerm in a confined account or sandbox (non-admin user) to reduce impact.\n\n### References\n- Report / credit: https://github.com/Curly-Haired-Baboon\n- Electerm releases: https://github.com/electerm/electerm/releases",
"id": "GHSA-mpm8-cx2p-626q",
"modified": "2026-05-13T13:32:30Z",
"published": "2026-05-08T18:46:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/security/advisories/GHSA-mpm8-cx2p-626q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43944"
},
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/commit/0599e67069b00e376a2e962649aaad6096e63507"
},
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/commit/8a6a17951e96d715f5a231532bbd8303fe208700"
},
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/commit/a79e06f4a1f0ac6376c3d2411ef4690fa0377742"
},
{
"type": "PACKAGE",
"url": "https://github.com/electerm/electerm"
},
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/releases/tag/v3.8.15"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Electerm users can run dangrous code through link or command line"
}
GHSA-MQXH-6GQ7-558M
Vulnerability from github – Published: 2026-06-17 13:55 – Updated: 2026-06-17 13:55Pi loads project-local extensions without approval
Pi before 0.79.0 loaded project-local configuration and resources from a repository's .pi directory without first asking the user to trust that repository. This included project-local extensions, which are executable TypeScript or JavaScript modules loaded into the Pi process.
An attacker who controls a repository could place Pi-specific project resources in that repository. If a user then started Pi from that working tree, the project-local extension code could run with the same privileges as the local Pi process without the user having a convenient way to make a trust decision.
Info
The affected component is Pi's project resource loading path. Before 0.79.0, startup loaded project .pi/settings.json, auto-discovered .pi resources, project package-managed resources, and project instruction files as part of normal session initialization. Project-local extensions were included in the same extension set as user/global extensions and were initialized before there was a project trust boundary.
Extensions like pi itself are not sandboxed. They run in the Pi process and can register commands, tools, and event handlers. The vulnerable behavior was not a privilege escalation across an operating-system boundary, but it allowed repository-controlled Pi extension code to execute implicitly when a user ran Pi in that repository.
Impact
Exploitation requires user interaction: the attacker must get a user to open or otherwise work in an attacker-controlled repository and start Pi there. The attacker does not need an account on the user's machine or prior privileges in Pi.
If exploited, project-local extension code runs with the same permissions as the user running Pi. It can access files, environment variables, credentials available to the process, the network, and local tools available to that user. In CVSS terms, this advisory rates the impact as limited confidentiality and integrity impact without a distinct availability impact because exploitation requires local user action in an untrusted repository and does not cross a privilege boundary.
This risk is most relevant for users who run Pi in repositories they have not reviewed or do not trust. Pi's security guidance requires users to trust the codebases they work with, or to use an external sandbox or isolation boundary for untrusted repositories.
Affected versions
- Affected:
< 0.79.0 - Patched:
0.79.0
The solution
Pi 0.79.0 added project trust gating for project-local inputs. On interactive startup, Pi now asks before loading project-local settings, instructions, resources, package-managed resources, or extensions when a trust decision has not already been saved for the working directory.
Non-interactive modes do not prompt. Without a saved trust decision, they ignore project-local inputs unless --approve or -a is passed. Users can also pass --no-approve or -na to ignore project-local inputs for a single run even when a project is already trusted.
Before trust is resolved, Pi loads only user/global extensions and extensions passed explicitly on the command line. Those extensions can participate in the project_trust event; project-local extensions are not loaded until after the project is trusted.
Recommendations
Upgrade @earendil-works/pi-coding-agent to version 0.79.0 or later.
After upgrading, review project trust prompts carefully and only trust repositories whose Pi-specific configuration and extensions you are willing to run. The upgrade makes this trust decision explicit, but it does not change Pi's security model: users should work only in trusted repositories, or use external isolation for untrusted code. Use --no-approve for one-off runs where project-local inputs should be ignored. For untrusted repositories or unattended automation, follow Pi's security guidance and run Pi inside an operating-system sandbox, container, VM, or other isolation boundary with only the files and credentials required for the task.
Workarounds
Before and after this change, Pi users should only run Pi in repositories they trust, or in an external sandbox or isolation boundary when working with untrusted code. Pi 0.79.0 adds an explicit trust prompt as a defense-in-depth and user-safety improvement; it is not a sandbox and it does not make untrusted repositories safe.
If upgrading is not possible and your workflow already enforces this trust boundary, continue to avoid running Pi directly in untrusted repositories. Inspect and remove project-local Pi configuration and resources before use, especially project-local extensions and package configuration. Disabling extensions and other project resources with command-line flags can reduce exposure, but trusted or isolated execution remains the primary mitigation.
Timeline
- 2026-05-25: Report received.
- 2026-06-05: Project trust gating committed.
- 2026-06-08: Project trust refinements and security model documentation completed.
- 2026-06-08: Fixed version 0.79.0 released.
- 2026-06-08: Advisory published.
Credits
Reported by @qerogram, @urianpaul94, @EQSTLab, and @kamalmarhubi.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@earendil-works/pi-coding-agent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.79.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54325"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T13:55:44Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "# Pi loads project-local extensions without approval\n\nPi before 0.79.0 loaded project-local configuration and resources from a repository\u0027s `.pi` directory without first asking the user to trust that repository. This included project-local extensions, which are executable TypeScript or JavaScript modules loaded into the Pi process.\n\nAn attacker who controls a repository could place Pi-specific project resources in that repository. If a user then started Pi from that working tree, the project-local extension code could run with the same privileges as the local Pi process without the user having a convenient way to make a trust decision.\n\n## Info\n\nThe affected component is Pi\u0027s project resource loading path. Before 0.79.0, startup loaded project `.pi/settings.json`, auto-discovered `.pi` resources, project package-managed resources, and project instruction files as part of normal session initialization. Project-local extensions were included in the same extension set as user/global extensions and were initialized before there was a project trust boundary.\n\nExtensions like pi itself are not sandboxed. They run in the Pi process and can register commands, tools, and event handlers. The vulnerable behavior was not a privilege escalation across an operating-system boundary, but it allowed repository-controlled Pi extension code to execute implicitly when a user ran Pi in that repository.\n\n## Impact\n\nExploitation requires user interaction: the attacker must get a user to open or otherwise work in an attacker-controlled repository and start Pi there. The attacker does not need an account on the user\u0027s machine or prior privileges in Pi.\n\nIf exploited, project-local extension code runs with the same permissions as the user running Pi. It can access files, environment variables, credentials available to the process, the network, and local tools available to that user. In CVSS terms, this advisory rates the impact as limited confidentiality and integrity impact without a distinct availability impact because exploitation requires local user action in an untrusted repository and does not cross a privilege boundary.\n\nThis risk is most relevant for users who run Pi in repositories they have not reviewed or do not trust. Pi\u0027s security guidance requires users to trust the codebases they work with, or to use an external sandbox or isolation boundary for untrusted repositories.\n\n## Affected versions\n\n- Affected: `\u003c 0.79.0`\n- Patched: `0.79.0`\n\n## The solution\n\nPi 0.79.0 added project trust gating for project-local inputs. On interactive startup, Pi now asks before loading project-local settings, instructions, resources, package-managed resources, or extensions when a trust decision has not already been saved for the working directory.\n\nNon-interactive modes do not prompt. Without a saved trust decision, they ignore project-local inputs unless `--approve` or `-a` is passed. Users can also pass `--no-approve` or `-na` to ignore project-local inputs for a single run even when a project is already trusted.\n\nBefore trust is resolved, Pi loads only user/global extensions and extensions passed explicitly on the command line. Those extensions can participate in the `project_trust` event; project-local extensions are not loaded until after the project is trusted.\n\n## Recommendations\n\nUpgrade `@earendil-works/pi-coding-agent` to version 0.79.0 or later.\n\nAfter upgrading, review project trust prompts carefully and only trust repositories whose Pi-specific configuration and extensions you are willing to run. The upgrade makes this trust decision explicit, but it does not change Pi\u0027s security model: users should work only in trusted repositories, or use external isolation for untrusted code. Use `--no-approve` for one-off runs where project-local inputs should be ignored. For untrusted repositories or unattended automation, follow Pi\u0027s [security guidance](https://pi.dev/docs/latest/security) and run Pi inside an operating-system sandbox, container, VM, or other isolation boundary with only the files and credentials required for the task.\n\n## Workarounds\n\nBefore and after this change, Pi users should only run Pi in repositories they trust, or in an external sandbox or isolation boundary when working with untrusted code. Pi 0.79.0 adds an explicit trust prompt as a defense-in-depth and user-safety improvement; it is not a sandbox and it does not make untrusted repositories safe.\n\nIf upgrading is not possible and your workflow already enforces this trust boundary, continue to avoid running Pi directly in untrusted repositories. Inspect and remove project-local Pi configuration and resources before use, especially project-local extensions and package configuration. Disabling extensions and other project resources with command-line flags can reduce exposure, but trusted or isolated execution remains the primary mitigation.\n\n## Timeline\n\n- 2026-05-25: Report received.\n- 2026-06-05: Project trust gating committed.\n- 2026-06-08: Project trust refinements and security model documentation completed.\n- 2026-06-08: Fixed version 0.79.0 released.\n- 2026-06-08: Advisory published.\n\n## Credits\n\nReported by [@qerogram](https://github.com/qerogram), [@urianpaul94](https://github.com/urianpaul94), [@EQSTLab](https://github.com/EQSTLab), and [@kamalmarhubi](https://github.com/kamalmarhubi).",
"id": "GHSA-mqxh-6gq7-558m",
"modified": "2026-06-17T13:55:44Z",
"published": "2026-06-17T13:55:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/earendil-works/pi/security/advisories/GHSA-mqxh-6gq7-558m"
},
{
"type": "WEB",
"url": "https://github.com/earendil-works/pi/commit/38f18be44727e669eb0a6e2eb8edb51b0232d83c"
},
{
"type": "WEB",
"url": "https://github.com/earendil-works/pi/commit/718215bd95b6fc6fa251580d27ea8aab857de390"
},
{
"type": "WEB",
"url": "https://github.com/earendil-works/pi/commit/89a92207f1c9303d53d822fd9b0ac21578834cb4"
},
{
"type": "WEB",
"url": "https://github.com/earendil-works/pi/commit/ce3a72444e1cc1eaa50475fb3378c7ffbb53ef49"
},
{
"type": "WEB",
"url": "https://github.com/earendil-works/pi/commit/ff3e9df5f5b32368c20b0ef553a6834b3dee9350"
},
{
"type": "PACKAGE",
"url": "https://github.com/earendil-works/pi"
},
{
"type": "WEB",
"url": "https://github.com/earendil-works/pi/releases/tag/v0.79.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Pi Agent: Pi loads project-local extensions without approval"
}
GHSA-P37G-3W4V-6868
Vulnerability from github – Published: 2022-09-14 00:00 – Updated: 2022-09-18 00:00The component "cuppa/api/index.php" of CuppaCMS v1.0 is Vulnerable to LFI. An authenticated user can read system files via crafted POST request using [function] parameter value as LFI payload.
{
"affected": [],
"aliases": [
"CVE-2022-37191"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-13T23:15:00Z",
"severity": "MODERATE"
},
"details": "The component \"cuppa/api/index.php\" of CuppaCMS v1.0 is Vulnerable to LFI. An authenticated user can read system files via crafted POST request using [function] parameter value as LFI payload.",
"id": "GHSA-p37g-3w4v-6868",
"modified": "2022-09-18T00:00:34Z",
"published": "2022-09-14T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37191"
},
{
"type": "WEB",
"url": "https://github.com/CuppaCMS/CuppaCMS/issues/20"
},
{
"type": "WEB",
"url": "https://github.com/badru8612/CuppaCMS-Authenticated-LFI-Vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P3M6-JR2H-HHXJ
Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-18 15:30Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-mj59-h3q9-ghfh. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.4.20 contains an improper environment variable validation vulnerability in MCP stdio server configuration that allows attackers to execute arbitrary code. Malicious workspace configurations can pass dangerous startup variables like NODE_OPTIONS, LD_PRELOAD, or BASH_ENV to spawned MCP server processes, enabling code injection when operators start sessions using those servers.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T15:30:14Z",
"nvd_published_at": "2026-05-11T18:16:39Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-mj59-h3q9-ghfh. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.4.20 contains an improper environment variable validation vulnerability in MCP stdio server configuration that allows attackers to execute arbitrary code. Malicious workspace configurations can pass dangerous startup variables like NODE_OPTIONS, LD_PRELOAD, or BASH_ENV to spawned MCP server processes, enabling code injection when operators start sessions using those servers.",
"id": "GHSA-p3m6-jr2h-hhxj",
"modified": "2026-05-18T15:30:14Z",
"published": "2026-05-11T18:31:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-mj59-h3q9-ghfh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44995"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/62fa5071896e95edc7f67d1cebc70a2859e283af"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/85d86ebc4bf3d2226d39d132a484f4f7a299fa1b"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-arbitrary-code-execution-via-mcp-stdio-environment-variables"
}
],
"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:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/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"
}
],
"summary": "Duplicate Advisory: OpenClaw: MCP stdio server env could load dangerous startup variables from workspace config",
"withdrawn": "2026-05-18T15:30:14Z"
}
GHSA-P4WH-CR8M-GM6C
Vulnerability from github – Published: 2026-03-03 21:36 – Updated: 2026-06-08 23:24Summary
shell-env fallback trusted prefix-based executable paths for $SHELL, allowing execution of attacker-controlled binaries in local/runtime-env influence scenarios.
Details
In affected versions, shell selection accepted either:
1. a shell listed in /etc/shells, or
2. any executable under hardcoded trusted prefixes (/bin, /usr/bin, /usr/local/bin, /opt/homebrew/bin, /run/current-system/sw/bin).
The selected shell was then executed as a login shell (-l -c 'env -0') for PATH/environment probing.
On systems where a trusted-prefix directory is writable (for example common Homebrew layouts under /opt/homebrew/bin) and runtime $SHELL can be influenced, this enabled attacker-controlled binary execution in OpenClaw process context.
The fix removes the trusted-prefix executable fallback and now trusts only shells explicitly registered in /etc/shells; otherwise it falls back to /bin/sh.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
>= 2026.2.22, <= 2026.2.22-2 - Latest published vulnerable version:
2026.2.22-2 - Patched versions (released):
>= 2026.2.23
Fix Commit(s)
ff10fe8b91670044a6bb0cd85deb736a0ec8fb55
Release Process Note
This advisory sets patched_versions to the released version (2026.2.23).
This advisory now reflects released fix version 2026.2.23.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "2026.2.22"
},
{
"fixed": "2026.2.23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22217"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T21:36:16Z",
"nvd_published_at": "2026-03-18T02:16:23Z",
"severity": "MODERATE"
},
"details": "### Summary\n`shell-env` fallback trusted prefix-based executable paths for `$SHELL`, allowing execution of attacker-controlled binaries in local/runtime-env influence scenarios.\n\n### Details\nIn affected versions, shell selection accepted either:\n1. a shell listed in `/etc/shells`, or\n2. any executable under hardcoded trusted prefixes (`/bin`, `/usr/bin`, `/usr/local/bin`, `/opt/homebrew/bin`, `/run/current-system/sw/bin`).\n\nThe selected shell was then executed as a login shell (`-l -c \u0027env -0\u0027`) for PATH/environment probing.\n\nOn systems where a trusted-prefix directory is writable (for example common Homebrew layouts under `/opt/homebrew/bin`) and runtime `$SHELL` can be influenced, this enabled attacker-controlled binary execution in OpenClaw process context.\n\nThe fix removes the trusted-prefix executable fallback and now trusts only shells explicitly registered in `/etc/shells`; otherwise it falls back to `/bin/sh`.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003e= 2026.2.22, \u003c= 2026.2.22-2`\n- Latest published vulnerable version: `2026.2.22-2`\n- Patched versions (released): `\u003e= 2026.2.23`\n\n### Fix Commit(s)\n- `ff10fe8b91670044a6bb0cd85deb736a0ec8fb55`\n\n### Release Process Note\nThis advisory sets `patched_versions` to the released version (`2026.2.23`).\nThis advisory now reflects released fix version `2026.2.23`.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-p4wh-cr8m-gm6c",
"modified": "2026-06-08T23:24:01Z",
"published": "2026-03-03T21:36:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-p4wh-cr8m-gm6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22217"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/ff10fe8b91670044a6bb0cd85deb736a0ec8fb55"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-arbitrary-binary-execution-via-shell-environment-variable-trusted-prefix-fallback"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: shell-env trusted-prefix fallback allowed attacker-controlled binary execution via $SHELL"
}
GHSA-P779-V69C-4294
Vulnerability from github – Published: 2025-12-15 00:30 – Updated: 2025-12-15 00:30NXLog Agent before 6.11 can load a file specified by the OPENSSL_CONF environment variable.
{
"affected": [],
"aliases": [
"CVE-2025-67900"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-14T23:15:37Z",
"severity": "HIGH"
},
"details": "NXLog Agent before 6.11 can load a file specified by the OPENSSL_CONF environment variable.",
"id": "GHSA-p779-v69c-4294",
"modified": "2025-12-15T00:30:25Z",
"published": "2025-12-15T00:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67900"
},
{
"type": "WEB",
"url": "https://docs.nxlog.co/agent/current/release-notes.html#nxlog-agent-6-11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-4
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
Mitigation MIT-21.1
Strategy: Enforcement by Conversion
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
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 MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-5.1
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
- Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-34
Strategy: Attack Surface Reduction
- Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
- This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
Mitigation MIT-6
Strategy: Attack Surface Reduction
- Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
- Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-175: Code Inclusion
An adversary exploits a weakness on the target to force arbitrary code to be retrieved locally or from a remote location and executed. This differs from code injection in that code injection involves the direct inclusion of code while code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-201: Serialized Data External Linking
An adversary creates a serialized data file (e.g. XML, YAML, etc...) that contains an external data reference. Because serialized data parsers may not validate documents with external references, there may be no checks on the nature of the reference in the external data. This can allow an adversary to open arbitrary files or connections, which may further lead to the adversary gaining access to information on the system that they would normally be unable to obtain.
CAPEC-228: DTD Injection
An attacker injects malicious content into an application's DTD in an attempt to produce a negative technical impact. DTDs are used to describe how XML documents are processed. Certain malformed DTDs (for example, those with excessive entity expansion as described in CAPEC 197) can cause the XML parsers that process the DTDs to consume excessive resources resulting in resource depletion.
CAPEC-251: Local Code Inclusion
The attacker forces an application to load arbitrary code files from the local machine. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-252: PHP Local File Inclusion
The attacker loads and executes an arbitrary local PHP file on a target machine. The attacker could use this to try to load old versions of PHP files that have known vulnerabilities, to load PHP files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-253: Remote Code Inclusion
The attacker forces an application to load arbitrary code files from a remote location. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load malicious files that the attacker placed on the remote machine, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-263: Force Use of Corrupted Files
This describes an attack where an application is forced to use a file that an attacker has corrupted. The result is often a denial of service caused by the application being unable to process the corrupted file, but other results, including the disabling of filters or access controls (if the application fails in an unsafe way rather than failing by locking down) or buffer overflows are possible.
CAPEC-538: Open-Source Library Manipulation
Adversaries implant malicious code in open source software (OSS) libraries to have it widely distributed, as OSS is commonly downloaded by developers and other users to incorporate into software development projects. The adversary can have a particular system in mind to target, or the implantation can be the first stage of follow-on attacks on many systems.
CAPEC-549: Local Execution of Code
An adversary installs and executes malicious code on the target system in an effort to achieve a negative technical impact. Examples include rootkits, ransomware, spyware, adware, and others.
CAPEC-640: Inclusion of Code in Existing Process
The adversary takes advantage of a bug in an application failing to verify the integrity of the running process to execute arbitrary code in the address space of a separate live process. The adversary could use running code in the context of another process to try to access process's memory, system/network resources, etc. The goal of this attack is to evade detection defenses and escalate privileges by masking the malicious code under an existing legitimate process. Examples of approaches include but not limited to: dynamic-link library (DLL) injection, portable executable injection, thread execution hijacking, ptrace system calls, VDSO hijacking, function hooking, reflective code loading, and more.
CAPEC-660: Root/Jailbreak Detection Evasion via Hooking
An adversary forces a non-restricted mobile application to load arbitrary code or code files, via Hooking, with the goal of evading Root/Jailbreak detection. Mobile device users often Root/Jailbreak their devices in order to gain administrative control over the mobile operating system and/or to install third-party mobile applications that are not provided by authorized application stores (e.g. Google Play Store and Apple App Store). Adversaries may further leverage these capabilities to escalate privileges or bypass access control on legitimate applications. Although many mobile applications check if a mobile device is Rooted/Jailbroken prior to authorized use of the application, adversaries may be able to "hook" code in order to circumvent these checks. Successfully evading Root/Jailbreak detection allows an adversary to execute administrative commands, obtain confidential data, impersonate legitimate users of the application, and more.
CAPEC-695: Repo Jacking
An adversary takes advantage of the redirect property of directly linked Version Control System (VCS) repositories to trick users into incorporating malicious code into their applications.
CAPEC-698: Install Malicious Extension
An adversary directly installs or tricks a user into installing a malicious extension into existing trusted software, with the goal of achieving a variety of negative technical impacts.