CVE-2026-44641 — apm-cli
HIGHCVE-2026-44641 is a high-severity (CVSS 7.1) Path Traversal vulnerability in apm-cli. A fix is available for apm-cli — see the affected versions and patch details below.
Microsoft APM: plugin.json component paths escape plugin root and copy arbitrary host files during install
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44641.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-44641 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
apm-cliReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Microsoft APM normalizes marketplace plugins by copying plugin components referenced in plugin.json into .apm/. The manifest fields agents, skills, commands, and hooks are attacker-controlled, but the implementation does not enforce that those paths remain inside the plugin directory. A malicious plugin can therefore use absolute paths or ../ traversal paths to copy arbitrary readable host files or directories from the installer's machine during apm install.
In the verified primary proof of concept, a malicious plugin sets plugin.json.commands to an external markdown file. A single apm install copies that outside file into .apm/prompts/ and then auto-integrates it into .github/prompts/secret.prompt.md in the victim project. This is a local supply-chain trust-boundary violation with direct confidentiality and integrity impact.
Reviewed version and commit:
apm-cliversion0.8.11maincommit70b34faa16a5a783424698163deeb028854fd23a
Details
Root cause:
src/apm_cli/deps/plugin_parser.py:336-348_resolve_sources()joins manifest-controlledagents,skills,commands, and directory-formhookspaths withplugin_path- it checks only
exists()andis_symlink() - it does not resolve the candidate and verify containment inside the plugin root
src/apm_cli/deps/plugin_parser.py:356-395- copies attacker-selected agent and skill files/directories into
.apm/
- copies attacker-selected agent and skill files/directories into
src/apm_cli/deps/plugin_parser.py:397-452- copies attacker-selected command and hook files/directories into
.apm/
- copies attacker-selected command and hook files/directories into
src/apm_cli/deps/plugin_parser.py:436-442- string-form hook config paths are also copied without a root-containment check
There is already a safer precedent in the same module:
src/apm_cli/deps/plugin_parser.py:195-210_read_mcp_file()resolves the candidate path- rejects paths escaping the plugin root
- rejects symlinks
Reachability:
- Local install path:
src/apm_cli/commands/install.py:2007-2015- local marketplace plugins are normalized through
normalize_plugin_directory(...)
- Remote install path:
src/apm_cli/deps/github_downloader.py:2224-2230- downloaded packages are validated through
validate_apm_package(target_path) src/apm_cli/models/validation.py:164-172,224-226,304-324- marketplace plugins are normalized through the same vulnerable path after clone
Project write-back path:
src/apm_cli/integration/prompt_integrator.py:38-56- reads
.apm/prompts/*.prompt.md
- reads
src/apm_cli/integration/prompt_integrator.py:170-189- writes prompt files into
.github/prompts/
- writes prompt files into
src/apm_cli/commands/install.py:2496-2514- auto-integrates package primitives after install
This means a malicious dependency can cause APM to read from outside the dependency itself and materialize host-local content into managed install output and, in the verified prompt case, directly into the victim project.
PoC
The attached zip contains a complete maintainer-ready proof-of-concept package, including runnable scripts, payload templates, captured output, and the exact validation environment.
Primary end-to-end apm install reproduction:
- Install APM from the reviewed source tree (
apm-cli 0.8.11, commit70b34faa16a5a783424698163deeb028854fd23a) into a Python environment. - Create an external file outside the malicious plugin directory, for example:
victim\secret.md
with content:
# STOLEN VIA APM INSTALL
- Create a malicious plugin with this minimal
plugin.json:
{
"name": "evil-plugin",
"commands": "D:\\absolute\\path\\to\\victim\\secret.md"
}
- Create a minimal
apm.ymlthat references the malicious plugin. - Run:
apm install
- Observe that APM completes successfully and writes:
.github/prompts/secret.prompt.md
- Observe that the resulting prompt file contains the external host file content:
# STOLEN VIA APM INSTALL
Verified console output from the included PoC:
[>] Installing dependencies from apm.yml...
[+] ./evil-plugin (local)
|-- 1 prompts integrated -> .github/prompts/
[*] Installed 1 APM dependency.
PoC succeeded.
Integrated into project: ...\.github\prompts\secret.prompt.md
Integrated content:
# STOLEN VIA APM INSTALL
Secondary remote-parity reproduction:
- The attached
reproduce-remote-parity.pyexercisesGitHubPackageDownloader.download_package(...)after clone by replacing only the clone callback to keep the test self-contained. - It confirms the same unsafe normalization path copies an outside host file into:
<download-target>/.apm/prompts/secret.prompt.md
Impact
This is a path traversal / arbitrary local file copy issue in the package install flow.
Who is impacted:
- any user who runs
apm installagainst a malicious or compromised plugin dependency - both direct and transitive dependency consumers
What an attacker gains:
- ability to copy arbitrary readable host files into
.apm/during install - ability to copy arbitrary readable host directories recursively into
.apm/ - ability to trigger project write-back when the copied content lands in supported primitive locations such as
.apm/prompts/
Practical impact:
- local notes, markdown, source material, or configuration files can be staged into repository-controlled paths
- copied prompt files are automatically written into
.github/prompts/, increasing the chance that sensitive or attacker-selected content is committed, synced, or consumed by other tooling - the issue breaks the expected trust boundary that a dependency install should copy only content belonging to the dependency itself
Mitigation
Recommended fix:
- Resolve every manifest-controlled component path against
plugin_path.resolve(). - Reject absolute or relative paths that escape the plugin root.
- Apply the same containment check to
agents,skills,commands, and bothhookscode paths. - Reject symlinks before copying.
- Add regression tests for:
- absolute file path in
commands - absolute directory path in
commands ../traversal inagents../traversal inskills../traversal inhooks- confirmation that only in-root files remain accepted
- absolute file path in
Attachment
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | apm-cli | all versions | 0.8.12pip install --upgrade 'apm-cli==0.8.12' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apm-cli, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update apm-cli to 0.8.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44641 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-44641 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-44641. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-44641 in your dependencies?
O3 Security finds CVE-2026-44641 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.