Action not permitted
Modal body text goes here.
Modal Title
Modal Body
BREW-APM-CVE-2026-46383 (CVE-2026-46383)
Vulnerability from osv_homebrew – Published: 2026-08-13 16:35 – Updated: 2026-10-04 04:18 – Source websiteMicrosoft APM is an open-source, community-driven dependency manager for AI agents. Prior to 0.13.0, Microsoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by apm install on supported Python 3.10 and 3.11 runtimes. When apm install is given a local .tar.gz that is not recognized as a plugin-format bundle, APM probes whether it is a legacy --format apm bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw tar.extractall() without rejecting Windows absolute member names such as D:/.... This vulnerability is fixed in 0.13.0.
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"upstream_fixed_in": "0.13.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "apm",
"purl": "pkg:brew/apm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.28.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "git",
"upstream_evidence": [
{
"ecosystem": "GIT",
"key": "https://github.com/microsoft/apm",
"name": "https://github.com/microsoft/apm",
"strategy": "git",
"subject_version": "0.33.0"
},
{
"ecosystem": "PyPI",
"key": "pkg:pypi/apm-cli@0.33.0",
"name": "apm-cli",
"strategy": "registry",
"subject_version": "0.33.0"
}
]
},
"details": "Microsoft APM is an open-source, community-driven dependency manager for AI agents. Prior to 0.13.0, Microsoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by apm install \u003cbundle\u003e on supported Python 3.10 and 3.11 runtimes. When apm install is given a local .tar.gz that is not recognized as a plugin-format bundle, APM probes whether it is a legacy --format apm bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw tar.extractall() without rejecting Windows absolute member names such as D:/.... This vulnerability is fixed in 0.13.0.",
"id": "BREW-apm-CVE-2026-46383",
"modified": "2026-10-04T04:18:27Z",
"published": "2026-08-13T16:35:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46383.json"
},
{
"type": "ADVISORY",
"url": "https://github.com/microsoft/apm/security/advisories/GHSA-mq5j-pw29-jcv3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46383"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Microsoft APM: Windows absolute-path tar member overwrite during legacy-bundle probing in `apm install`",
"upstream": [
"CVE-2026-46383",
"GHSA-mq5j-pw29-jcv3",
"PYSEC-2026-2378"
]
}
CVE-2026-46383 (GCVE-0-2026-46383)
Vulnerability from cvelistv5 – Published: 2026-05-15 16:04 – Updated: 2026-05-15 17:49| URL | Tags |
|---|---|
| https://github.com/microsoft/apm/security/advisor… | x_refsource_CONFIRM |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-46383",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-15T17:48:40.768904Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-15T17:49:11.229Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/microsoft/apm/security/advisories/GHSA-mq5j-pw29-jcv3"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "apm",
"vendor": "microsoft",
"versions": [
{
"status": "affected",
"version": "\u003c 0.13.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Microsoft APM is an open-source, community-driven dependency manager for AI agents. Prior to 0.13.0, Microsoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by apm install \u003cbundle\u003e on supported Python 3.10 and 3.11 runtimes. When apm install is given a local .tar.gz that is not recognized as a plugin-format bundle, APM probes whether it is a legacy --format apm bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw tar.extractall() without rejecting Windows absolute member names such as D:/.... This vulnerability is fixed in 0.13.0."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-73",
"description": "CWE-73: External Control of File Name or Path",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-15T16:04:24.050Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/microsoft/apm/security/advisories/GHSA-mq5j-pw29-jcv3",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/microsoft/apm/security/advisories/GHSA-mq5j-pw29-jcv3"
}
],
"source": {
"advisory": "GHSA-mq5j-pw29-jcv3",
"discovery": "UNKNOWN"
},
"title": "Microsoft APM: Windows absolute-path tar member overwrite during legacy-bundle probing in `apm install`"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-46383",
"datePublished": "2026-05-15T16:04:24.050Z",
"dateReserved": "2026-05-13T19:53:47.922Z",
"dateUpdated": "2026-05-15T17:49:11.229Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-MQ5J-PW29-JCV3
Vulnerability from github – Published: 2026-05-15 18:25 – Updated: 2026-05-15 23:50Summary
Microsoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by apm install <bundle> on supported Python 3.10 and 3.11 runtimes. When apm install is given a local .tar.gz that is not recognized as a plugin-format bundle, APM probes whether it is a legacy --format apm bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw tar.extractall() without rejecting Windows absolute member names such as D:/....
This issue is still present on the latest main commit at review time (2b7a931d58a73cbfc0bcf086cea332d204075e27) and on the latest release (v0.12.4). In both cases, a crafted legacy-looking tarball caused an external file to be created or overwritten outside the temporary extraction root before apm install finished rejecting the bundle with the expected legacy-format usage error.
This report is scoped narrowly to Windows installations running Python 3.10 or 3.11.
Details
The broken trust boundary is the boundary between an untrusted local bundle artifact and the host filesystem state that APM is allowed to modify while probing that artifact. The attacker-controlled input is the tar member name inside the .tar.gz bundle. A crafted archive can include a member whose name is a Windows absolute path such as D:/apm/run-main-install/outside/legacy-probe-outside-main.txt.
The current install caller path still reaches the legacy probe for .tar.gz inputs that are not recognized as plugin-format bundles. In src/apm_cli/commands/install.py, the local-bundle branch first calls detect_local_bundle(). If the path exists, is a tarball, and is not recognized as a plugin-format bundle, the caller still invokes _looks_like_legacy_apm_bundle() to distinguish a legacy bundle from an arbitrary tarball and to choose the error message.
The root cause is in src/apm_cli/bundle/local_bundle.py. _looks_like_legacy_apm_bundle():
- opens the tarball,
- rejects only symlink and hardlink members,
- and on Python versions earlier than 3.12 calls raw
tar.extractall(tmp).
That helper does not reject Windows absolute member names and does not perform the Windows-aware containment checks already present elsewhere in the same module.
This is particularly clear because the adjacent detect_local_bundle() path in the same file already contains safer pre-extraction validation. It rejects:
PureWindowsPath(name).drivePureWindowsPath(name).is_absolute()- path traversal via
validate_path_segments(...)
That safer validation is not reused by _looks_like_legacy_apm_bundle().
On Python versions earlier than 3.12, _looks_like_legacy_apm_bundle() performs extraction before legacy-format rejection is raised, so archive member names become filesystem writes during bundle classification rather than during an accepted install step. The write occurs before command rejection because the legacy probe must extract the tarball in order to look for apm.lock.yaml at the bundle root and confirm that plugin.json is absent. As a result, the out-of-root write happens during classification, before the caller raises the legacy-format usage error.
The issue is not limited to creating new files. On both latest main and latest release, the same vulnerable path overwrote an already-existing writable target file with attacker-controlled contents before the command finished legacy-format rejection. It was further verified the same overwrite primitive against a pre-existing project workflow file at .github/workflows/ci.yml, replacing its YAML contents before rejection.
This is a security issue rather than intended package-manager behavior. The user is asking APM to inspect or install a local bundle. The expected behavior is that bundle contents are handled within the extraction sandbox used for that operation. Writing to an arbitrary host path outside the extraction root during pre-install probing is not part of expected local-bundle behavior, and it happens even when APM ultimately rejects the tarball.
This issue is also distinct from the prior public APM plugin path-escape issue. The prior public issue involved manifest-controlled path escape during plugin normalization in plugin_parser.py, where attacker-controlled manifest entries were resolved outside the plugin root during install. This issue is different in input, timing, and code path: it is an archive-member extraction bug in src/apm_cli/bundle/local_bundle.py during legacy-bundle probing, before bundle classification completes and before apm install rejects the bundle. No manifest processing is required to trigger it.
As additional same-family scope information, the same Windows absolute-path extraction weakness is also reproducible in apm unpack.In src/apm_cli/bundle/unpacker.py, the unpacker rejects / and .. but still misses Windows absolute tar member names before calling tar.extractall() on Python versions earlier than 3.12. Because apm unpack is deprecated, I am not presenting it as a second standalone vulnerability title; I am including it only as additional affected surface from the same validation family.
PoC
Validation environment used for the included proof:
- Windows 11 Pro
- Python 3.11.9 x64
- Latest
maincommit:2b7a931d58a73cbfc0bcf086cea332d204075e27 - Latest release commit:
6aceef72be490a9c716547f600a2659f3f2826b7(v0.12.4)
Minimal malicious archive contents:
bundle/apm.lock.yamlD:/apm/run-main-install/outside/legacy-probe-outside-main.txt
The first member makes the archive look like a legacy APM bundle. The second member proves the out-of-root write. The outside target path must be writable by the user running APM. The proof uses a user-controlled directory for that reason.
One straightforward way to build this input is to use Python's tarfile module directly and add:
bundle/apm.lock.yamlTarInfo("D:/apm/run-main-install/outside/legacy-probe-outside-main.txt")
with file content such as:
outside write via install main
Reproduction steps for latest main:
- Check out
microsoft/apmat2b7a931d58a73cbfc0bcf086cea332d204075e27. - Use a real Windows Python 3.11 runtime.
- Ensure the
apm_cliimport resolves to the checked-out tree. - Create the malicious legacy-looking tarball described above.
- Run:
python -m apm_cli.cli install D:\apm\run-main-install\input\legacy-bundle.tar.gz
Expected safe behavior:
- APM rejects the tarball without creating or overwriting any host file outside the temporary extraction root.
Observed result on latest main:
- the import path resolved to the checked-out
maintree, - the command ended with the expected legacy-format rejection,
- the process exit code was
2, - and the file below had already been created outside the temporary extraction root:
D:\apm\run-main-install\outside\legacy-probe-outside-main.txt
The file contained:
outside write via install main
I also verified overwrite, not just creation, by pre-creating a writable target file and then running the same install path. The existing file contents changed from ORIGINAL-MAIN to OVERWRITTEN-MAIN before rejection.
I further verified overwrite of a pre-existing project workflow file. Before the run, the target file contained:
name: safe
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo safe
After the run, the same file contained attacker-controlled replacement YAML:
name: overwritten
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo overwritten-by-archive
Observed command output on latest main:
[!] Install interrupted after 0.0s.
Usage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...
Try 'python -m apm_cli.cli install --help' for help.
Error: 'D:\apm\run-main-install\input\legacy-bundle.tar.gz' was packed with '--format apm' (legacy format). 'apm install <bundle>' requires the plugin format. Repack with 'apm pack --format plugin --archive', or use 'apm unpack' to deploy the legacy bundle.
Reproduction steps for latest release v0.12.4:
- Check out tag
v0.12.4/ commit6aceef72be490a9c716547f600a2659f3f2826b7. - Use the same Windows Python 3.11 runtime.
- Ensure the
apm_cliimport resolves to thev0.12.4tree. - Create the same malicious tarball shape, for example with:
D:/apm/run-release-install/outside/legacy-probe-outside-release.txt
- Run:
python -m apm_cli.cli install D:\apm\run-release-install\input\legacy-bundle.tar.gz
Observed result on latest release:
- the import path resolved to the checked-out
v0.12.4tree, - the command ended with the expected legacy-format rejection,
- the process exit code was
2, - and the file below had already been created outside the temporary extraction root:
D:\apm\run-release-install\outside\legacy-probe-outside-release.txt
The file contained:
outside write via install release
I also verified overwrite, not just creation, on the latest release by pre-creating a writable target file. The existing file contents changed from ORIGINAL-RELEASE to OVERWRITTEN-RELEASE before rejection. The same workflow-file overwrite pattern was also reproducible on the latest release.
Observed command output on latest release:
[!] Install interrupted after 0.0s.
Usage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...
Try 'python -m apm_cli.cli install --help' for help.
Error: 'D:\apm\run-release-install\input\legacy-bundle.tar.gz' was packed with '--format apm' (legacy format). 'apm install <bundle>' requires the plugin format. Repack with 'apm pack --format plugin --archive', or use 'apm unpack' to deploy the legacy bundle.
Additional same-family affected surface:
apm unpackon latestmainand latest release also created an outside file when given a tarball containing a Windows absolute member name.- In that path the command completed successfully with exit code
0, which further confirms that the Windows absolute-path validation gap is present outside the primary install probe as well.
Impact
This is an arbitrary local file overwrite outside the intended extraction root during a current APM install path. The impacted population is Windows users running APM on supported Python 3.10 or 3.11 runtimes. The attacker capability required is the ability to supply a crafted local bundle and induce the victim to run apm install on it.
The strongest demonstrated real-world consequence is attacker-controlled overwrite of an existing writable file at an attacker-selected Windows path outside the extraction root, using the privileges of the user running APM. An overwrite of a project-controlled GitHub Actions workflow file with attacker-controlled YAML before rejection was verified. Workflow execution from this report hasn't been claimed; the demonstrated consequence is high-integrity modification of a trusted automation file outside the intended extraction boundary.
The issue is currently reachable on:
- latest
mainat2b7a931d58a73cbfc0bcf086cea332d204075e27 - latest release
v0.12.4
Mitigation
- Reuse the existing pre-extraction validation already implemented in
detect_local_bundle()for_looks_like_legacy_apm_bundle(). - Reject Windows absolute member names before any extraction step.
- Apply equivalent Windows absolute-path validation to the unpacker in
src/apm_cli/bundle/unpacker.py. - Add regression tests for:
- Windows absolute member paths in the legacy-bundle probe path
- Windows absolute member paths in the unpack path
- confirmation that no host write occurs before the legacy-format rejection is raised
Attachment
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.12.4"
},
"package": {
"ecosystem": "PyPI",
"name": "apm-cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46383"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-15T18:25:34Z",
"nvd_published_at": "2026-05-15T17:16:49Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nMicrosoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by `apm install \u003cbundle\u003e` on supported Python 3.10 and 3.11 runtimes. When `apm install` is given a local `.tar.gz` that is not recognized as a plugin-format bundle, APM probes whether it is a legacy `--format apm` bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw `tar.extractall()` without rejecting Windows absolute member names such as `D:/...`.\n\nThis issue is still present on the latest `main` commit at review time (`2b7a931d58a73cbfc0bcf086cea332d204075e27`) and on the latest release (`v0.12.4`). In both cases, a crafted legacy-looking tarball caused an external file to be created or overwritten outside the temporary extraction root before `apm install` finished rejecting the bundle with the expected legacy-format usage error.\n\nThis report is scoped narrowly to Windows installations running Python 3.10 or 3.11.\n\n### Details\n\nThe broken trust boundary is the boundary between an untrusted local bundle artifact and the host filesystem state that APM is allowed to modify while probing that artifact. The attacker-controlled input is the tar member name inside the `.tar.gz` bundle. A crafted archive can include a member whose name is a Windows absolute path such as `D:/apm/run-main-install/outside/legacy-probe-outside-main.txt`.\n\nThe current install caller path still reaches the legacy probe for `.tar.gz` inputs that are not recognized as plugin-format bundles. In `src/apm_cli/commands/install.py`, the local-bundle branch first calls `detect_local_bundle()`. If the path exists, is a tarball, and is not recognized as a plugin-format bundle, the caller still invokes `_looks_like_legacy_apm_bundle()` to distinguish a legacy bundle from an arbitrary tarball and to choose the error message.\n\nThe root cause is in `src/apm_cli/bundle/local_bundle.py`. `_looks_like_legacy_apm_bundle()`:\n\n- opens the tarball,\n- rejects only symlink and hardlink members,\n- and on Python versions earlier than 3.12 calls raw `tar.extractall(tmp)`.\n\nThat helper does not reject Windows absolute member names and does not perform the Windows-aware containment checks already present elsewhere in the same module.\n\nThis is particularly clear because the adjacent `detect_local_bundle()` path in the same file already contains safer pre-extraction validation. It rejects:\n\n- `PureWindowsPath(name).drive`\n- `PureWindowsPath(name).is_absolute()`\n- path traversal via `validate_path_segments(...)`\n\nThat safer validation is not reused by `_looks_like_legacy_apm_bundle()`.\n\nOn Python versions earlier than 3.12, `_looks_like_legacy_apm_bundle()` performs extraction before legacy-format rejection is raised, so archive member names become filesystem writes during bundle classification rather than during an accepted install step. The write occurs before command rejection because the legacy probe must extract the tarball in order to look for `apm.lock.yaml` at the bundle root and confirm that `plugin.json` is absent. As a result, the out-of-root write happens during classification, before the caller raises the legacy-format usage error.\n\nThe issue is not limited to creating new files. On both latest `main` and latest release, the same vulnerable path overwrote an already-existing writable target file with attacker-controlled contents before the command finished legacy-format rejection. It was further verified the same overwrite primitive against a pre-existing project workflow file at `.github/workflows/ci.yml`, replacing its YAML contents before rejection.\n\nThis is a security issue rather than intended package-manager behavior. The user is asking APM to inspect or install a local bundle. The expected behavior is that bundle contents are handled within the extraction sandbox used for that operation. Writing to an arbitrary host path outside the extraction root during pre-install probing is not part of expected local-bundle behavior, and it happens even when APM ultimately rejects the tarball.\n\nThis issue is also distinct from the prior public APM plugin path-escape issue. The prior public issue involved manifest-controlled path escape during plugin normalization in `plugin_parser.py`, where attacker-controlled manifest entries were resolved outside the plugin root during install. This issue is different in input, timing, and code path: it is an archive-member extraction bug in `src/apm_cli/bundle/local_bundle.py` during legacy-bundle probing, before bundle classification completes and before `apm install` rejects the bundle. No manifest processing is required to trigger it.\n\nAs additional same-family scope information, the same Windows absolute-path extraction weakness is also reproducible in apm unpack.In `src/apm_cli/bundle/unpacker.py`, the unpacker rejects `/` and `..` but still misses Windows absolute tar member names before calling `tar.extractall()` on Python versions earlier than 3.12. Because `apm unpack` is deprecated, I am not presenting it as a second standalone vulnerability title; I am including it only as additional affected surface from the same validation family.\n\n### PoC\n\nValidation environment used for the included proof:\n\n- Windows 11 Pro\n- Python 3.11.9 x64\n- Latest `main` commit: `2b7a931d58a73cbfc0bcf086cea332d204075e27`\n- Latest release commit: `6aceef72be490a9c716547f600a2659f3f2826b7` (`v0.12.4`)\n\nMinimal malicious archive contents:\n\n- `bundle/apm.lock.yaml`\n- `D:/apm/run-main-install/outside/legacy-probe-outside-main.txt`\n\nThe first member makes the archive look like a legacy APM bundle. The second member proves the out-of-root write. The outside target path must be writable by the user running APM. The proof uses a user-controlled directory for that reason.\n\nOne straightforward way to build this input is to use Python\u0027s `tarfile` module directly and add:\n\n- `bundle/apm.lock.yaml`\n- `TarInfo(\"D:/apm/run-main-install/outside/legacy-probe-outside-main.txt\")`\n\nwith file content such as:\n\n```text\noutside write via install main\n```\n\nReproduction steps for latest `main`:\n\n1. Check out `microsoft/apm` at `2b7a931d58a73cbfc0bcf086cea332d204075e27`.\n2. Use a real Windows Python 3.11 runtime.\n3. Ensure the `apm_cli` import resolves to the checked-out tree.\n4. Create the malicious legacy-looking tarball described above.\n5. Run:\n\n```powershell\npython -m apm_cli.cli install D:\\apm\\run-main-install\\input\\legacy-bundle.tar.gz\n```\n\nExpected safe behavior:\n\n- APM rejects the tarball without creating or overwriting any host file outside the temporary extraction root.\n\nObserved result on latest `main`:\n\n- the import path resolved to the checked-out `main` tree,\n- the command ended with the expected legacy-format rejection,\n- the process exit code was `2`,\n- and the file below had already been created outside the temporary extraction root:\n\n```text\nD:\\apm\\run-main-install\\outside\\legacy-probe-outside-main.txt\n```\n\nThe file contained:\n\n```text\noutside write via install main\n```\n\nI also verified overwrite, not just creation, by pre-creating a writable target file and then running the same install path. The existing file contents changed from `ORIGINAL-MAIN` to `OVERWRITTEN-MAIN` before rejection.\n\nI further verified overwrite of a pre-existing project workflow file. Before the run, the target file contained:\n\n```yaml\nname: safe\non: [push]\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - run: echo safe\n```\n\nAfter the run, the same file contained attacker-controlled replacement YAML:\n\n```yaml\nname: overwritten\non: [push]\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - run: echo overwritten-by-archive\n```\n\nObserved command output on latest `main`:\n\n```text\n[!] Install interrupted after 0.0s.\nUsage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...\nTry \u0027python -m apm_cli.cli install --help\u0027 for help.\n\nError: \u0027D:\\apm\\run-main-install\\input\\legacy-bundle.tar.gz\u0027 was packed with \u0027--format apm\u0027 (legacy format). \u0027apm install \u003cbundle\u003e\u0027 requires the plugin format. Repack with \u0027apm pack --format plugin --archive\u0027, or use \u0027apm unpack\u0027 to deploy the legacy bundle.\n```\n\nReproduction steps for latest release `v0.12.4`:\n\n1. Check out tag `v0.12.4` / commit `6aceef72be490a9c716547f600a2659f3f2826b7`.\n2. Use the same Windows Python 3.11 runtime.\n3. Ensure the `apm_cli` import resolves to the `v0.12.4` tree.\n4. Create the same malicious tarball shape, for example with:\n\n```text\nD:/apm/run-release-install/outside/legacy-probe-outside-release.txt\n```\n\n5. Run:\n\n```powershell\npython -m apm_cli.cli install D:\\apm\\run-release-install\\input\\legacy-bundle.tar.gz\n```\n\nObserved result on latest release:\n\n- the import path resolved to the checked-out `v0.12.4` tree,\n- the command ended with the expected legacy-format rejection,\n- the process exit code was `2`,\n- and the file below had already been created outside the temporary extraction root:\n\n```text\nD:\\apm\\run-release-install\\outside\\legacy-probe-outside-release.txt\n```\n\nThe file contained:\n\n```text\noutside write via install release\n```\n\nI also verified overwrite, not just creation, on the latest release by pre-creating a writable target file. The existing file contents changed from `ORIGINAL-RELEASE` to `OVERWRITTEN-RELEASE` before rejection. The same workflow-file overwrite pattern was also reproducible on the latest release.\n\nObserved command output on latest release:\n\n```text\n[!] Install interrupted after 0.0s.\nUsage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...\nTry \u0027python -m apm_cli.cli install --help\u0027 for help.\n\nError: \u0027D:\\apm\\run-release-install\\input\\legacy-bundle.tar.gz\u0027 was packed with \u0027--format apm\u0027 (legacy format). \u0027apm install \u003cbundle\u003e\u0027 requires the plugin format. Repack with \u0027apm pack --format plugin --archive\u0027, or use \u0027apm unpack\u0027 to deploy the legacy bundle.\n```\n\nAdditional same-family affected surface:\n\n- `apm unpack` on latest `main` and latest release also created an outside file when given a tarball containing a Windows absolute member name.\n- In that path the command completed successfully with exit code `0`, which further confirms that the Windows absolute-path validation gap is present outside the primary install probe as well.\n\n### Impact\n\nThis is an arbitrary local file overwrite outside the intended extraction root during a current APM install path. The impacted population is Windows users running APM on supported Python 3.10 or 3.11 runtimes. The attacker capability required is the ability to supply a crafted local bundle and induce the victim to run `apm install` on it.\n\nThe strongest demonstrated real-world consequence is attacker-controlled overwrite of an existing writable file at an attacker-selected Windows path outside the extraction root, using the privileges of the user running APM. An overwrite of a project-controlled GitHub Actions workflow file with attacker-controlled YAML before rejection was verified. Workflow execution from this report hasn\u0027t been claimed; the demonstrated consequence is high-integrity modification of a trusted automation file outside the intended extraction boundary.\n\nThe issue is currently reachable on:\n\n- latest `main` at `2b7a931d58a73cbfc0bcf086cea332d204075e27`\n- latest release `v0.12.4`\n\n### Mitigation\n\n1. Reuse the existing pre-extraction validation already implemented in `detect_local_bundle()` for `_looks_like_legacy_apm_bundle()`.\n2. Reject Windows absolute member names before any extraction step.\n3. Apply equivalent Windows absolute-path validation to the unpacker in `src/apm_cli/bundle/unpacker.py`.\n4. Add regression tests for:\n - Windows absolute member paths in the legacy-bundle probe path\n - Windows absolute member paths in the unpack path\n - confirmation that no host write occurs before the legacy-format rejection is raised\n\n### Attachment\n[apm-legacy-probe-windows-absolute-path-write-20260511.zip](https://github.com/user-attachments/files/27578792/apm-legacy-probe-windows-absolute-path-write-20260511.zip)",
"id": "GHSA-mq5j-pw29-jcv3",
"modified": "2026-05-15T23:50:07Z",
"published": "2026-05-15T18:25:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/microsoft/apm/security/advisories/GHSA-mq5j-pw29-jcv3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46383"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/apm/commit/77d1dda8303c8d7ccb6148788a6274fdece98499"
},
{
"type": "PACKAGE",
"url": "https://github.com/microsoft/apm"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/apm/releases/tag/v0.13.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Microsoft APM: Windows absolute-path tar member overwrite during legacy-bundle probing in `apm install`"
}
PYSEC-2026-2378
Vulnerability from pysec - Published: 2026-07-13 15:19 - Updated: 2026-07-13 16:03Summary
Microsoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by apm install <bundle> on supported Python 3.10 and 3.11 runtimes. When apm install is given a local .tar.gz that is not recognized as a plugin-format bundle, APM probes whether it is a legacy --format apm bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw tar.extractall() without rejecting Windows absolute member names such as D:/....
This issue is still present on the latest main commit at review time (2b7a931d58a73cbfc0bcf086cea332d204075e27) and on the latest release (v0.12.4). In both cases, a crafted legacy-looking tarball caused an external file to be created or overwritten outside the temporary extraction root before apm install finished rejecting the bundle with the expected legacy-format usage error.
This report is scoped narrowly to Windows installations running Python 3.10 or 3.11.
Details
The broken trust boundary is the boundary between an untrusted local bundle artifact and the host filesystem state that APM is allowed to modify while probing that artifact. The attacker-controlled input is the tar member name inside the .tar.gz bundle. A crafted archive can include a member whose name is a Windows absolute path such as D:/apm/run-main-install/outside/legacy-probe-outside-main.txt.
The current install caller path still reaches the legacy probe for .tar.gz inputs that are not recognized as plugin-format bundles. In src/apm_cli/commands/install.py, the local-bundle branch first calls detect_local_bundle(). If the path exists, is a tarball, and is not recognized as a plugin-format bundle, the caller still invokes _looks_like_legacy_apm_bundle() to distinguish a legacy bundle from an arbitrary tarball and to choose the error message.
The root cause is in src/apm_cli/bundle/local_bundle.py. _looks_like_legacy_apm_bundle():
- opens the tarball,
- rejects only symlink and hardlink members,
- and on Python versions earlier than 3.12 calls raw
tar.extractall(tmp).
That helper does not reject Windows absolute member names and does not perform the Windows-aware containment checks already present elsewhere in the same module.
This is particularly clear because the adjacent detect_local_bundle() path in the same file already contains safer pre-extraction validation. It rejects:
PureWindowsPath(name).drivePureWindowsPath(name).is_absolute()- path traversal via
validate_path_segments(...)
That safer validation is not reused by _looks_like_legacy_apm_bundle().
On Python versions earlier than 3.12, _looks_like_legacy_apm_bundle() performs extraction before legacy-format rejection is raised, so archive member names become filesystem writes during bundle classification rather than during an accepted install step. The write occurs before command rejection because the legacy probe must extract the tarball in order to look for apm.lock.yaml at the bundle root and confirm that plugin.json is absent. As a result, the out-of-root write happens during classification, before the caller raises the legacy-format usage error.
The issue is not limited to creating new files. On both latest main and latest release, the same vulnerable path overwrote an already-existing writable target file with attacker-controlled contents before the command finished legacy-format rejection. It was further verified the same overwrite primitive against a pre-existing project workflow file at .github/workflows/ci.yml, replacing its YAML contents before rejection.
This is a security issue rather than intended package-manager behavior. The user is asking APM to inspect or install a local bundle. The expected behavior is that bundle contents are handled within the extraction sandbox used for that operation. Writing to an arbitrary host path outside the extraction root during pre-install probing is not part of expected local-bundle behavior, and it happens even when APM ultimately rejects the tarball.
This issue is also distinct from the prior public APM plugin path-escape issue. The prior public issue involved manifest-controlled path escape during plugin normalization in plugin_parser.py, where attacker-controlled manifest entries were resolved outside the plugin root during install. This issue is different in input, timing, and code path: it is an archive-member extraction bug in src/apm_cli/bundle/local_bundle.py during legacy-bundle probing, before bundle classification completes and before apm install rejects the bundle. No manifest processing is required to trigger it.
As additional same-family scope information, the same Windows absolute-path extraction weakness is also reproducible in apm unpack.In src/apm_cli/bundle/unpacker.py, the unpacker rejects / and .. but still misses Windows absolute tar member names before calling tar.extractall() on Python versions earlier than 3.12. Because apm unpack is deprecated, I am not presenting it as a second standalone vulnerability title; I am including it only as additional affected surface from the same validation family.
PoC
Validation environment used for the included proof:
- Windows 11 Pro
- Python 3.11.9 x64
- Latest
maincommit:2b7a931d58a73cbfc0bcf086cea332d204075e27 - Latest release commit:
6aceef72be490a9c716547f600a2659f3f2826b7(v0.12.4)
Minimal malicious archive contents:
bundle/apm.lock.yamlD:/apm/run-main-install/outside/legacy-probe-outside-main.txt
The first member makes the archive look like a legacy APM bundle. The second member proves the out-of-root write. The outside target path must be writable by the user running APM. The proof uses a user-controlled directory for that reason.
One straightforward way to build this input is to use Python's tarfile module directly and add:
bundle/apm.lock.yamlTarInfo("D:/apm/run-main-install/outside/legacy-probe-outside-main.txt")
with file content such as:
outside write via install main
Reproduction steps for latest main:
- Check out
microsoft/apmat2b7a931d58a73cbfc0bcf086cea332d204075e27. - Use a real Windows Python 3.11 runtime.
- Ensure the
apm_cliimport resolves to the checked-out tree. - Create the malicious legacy-looking tarball described above.
- Run:
python -m apm_cli.cli install D:\apm\run-main-install\input\legacy-bundle.tar.gz
Expected safe behavior:
- APM rejects the tarball without creating or overwriting any host file outside the temporary extraction root.
Observed result on latest main:
- the import path resolved to the checked-out
maintree, - the command ended with the expected legacy-format rejection,
- the process exit code was
2, - and the file below had already been created outside the temporary extraction root:
D:\apm\run-main-install\outside\legacy-probe-outside-main.txt
The file contained:
outside write via install main
I also verified overwrite, not just creation, by pre-creating a writable target file and then running the same install path. The existing file contents changed from ORIGINAL-MAIN to OVERWRITTEN-MAIN before rejection.
I further verified overwrite of a pre-existing project workflow file. Before the run, the target file contained:
name: safe
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo safe
After the run, the same file contained attacker-controlled replacement YAML:
name: overwritten
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo overwritten-by-archive
Observed command output on latest main:
[!] Install interrupted after 0.0s.
Usage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...
Try 'python -m apm_cli.cli install --help' for help.
Error: 'D:\apm\run-main-install\input\legacy-bundle.tar.gz' was packed with '--format apm' (legacy format). 'apm install <bundle>' requires the plugin format. Repack with 'apm pack --format plugin --archive', or use 'apm unpack' to deploy the legacy bundle.
Reproduction steps for latest release v0.12.4:
- Check out tag
v0.12.4/ commit6aceef72be490a9c716547f600a2659f3f2826b7. - Use the same Windows Python 3.11 runtime.
- Ensure the
apm_cliimport resolves to thev0.12.4tree. - Create the same malicious tarball shape, for example with:
D:/apm/run-release-install/outside/legacy-probe-outside-release.txt
- Run:
python -m apm_cli.cli install D:\apm\run-release-install\input\legacy-bundle.tar.gz
Observed result on latest release:
- the import path resolved to the checked-out
v0.12.4tree, - the command ended with the expected legacy-format rejection,
- the process exit code was
2, - and the file below had already been created outside the temporary extraction root:
D:\apm\run-release-install\outside\legacy-probe-outside-release.txt
The file contained:
outside write via install release
I also verified overwrite, not just creation, on the latest release by pre-creating a writable target file. The existing file contents changed from ORIGINAL-RELEASE to OVERWRITTEN-RELEASE before rejection. The same workflow-file overwrite pattern was also reproducible on the latest release.
Observed command output on latest release:
[!] Install interrupted after 0.0s.
Usage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...
Try 'python -m apm_cli.cli install --help' for help.
Error: 'D:\apm\run-release-install\input\legacy-bundle.tar.gz' was packed with '--format apm' (legacy format). 'apm install <bundle>' requires the plugin format. Repack with 'apm pack --format plugin --archive', or use 'apm unpack' to deploy the legacy bundle.
Additional same-family affected surface:
apm unpackon latestmainand latest release also created an outside file when given a tarball containing a Windows absolute member name.- In that path the command completed successfully with exit code
0, which further confirms that the Windows absolute-path validation gap is present outside the primary install probe as well.
Impact
This is an arbitrary local file overwrite outside the intended extraction root during a current APM install path. The impacted population is Windows users running APM on supported Python 3.10 or 3.11 runtimes. The attacker capability required is the ability to supply a crafted local bundle and induce the victim to run apm install on it.
The strongest demonstrated real-world consequence is attacker-controlled overwrite of an existing writable file at an attacker-selected Windows path outside the extraction root, using the privileges of the user running APM. An overwrite of a project-controlled GitHub Actions workflow file with attacker-controlled YAML before rejection was verified. Workflow execution from this report hasn't been claimed; the demonstrated consequence is high-integrity modification of a trusted automation file outside the intended extraction boundary.
The issue is currently reachable on:
- latest
mainat2b7a931d58a73cbfc0bcf086cea332d204075e27 - latest release
v0.12.4
Mitigation
- Reuse the existing pre-extraction validation already implemented in
detect_local_bundle()for_looks_like_legacy_apm_bundle(). - Reject Windows absolute member names before any extraction step.
- Apply equivalent Windows absolute-path validation to the unpacker in
src/apm_cli/bundle/unpacker.py. - Add regression tests for:
- Windows absolute member paths in the legacy-bundle probe path
- Windows absolute member paths in the unpack path
- confirmation that no host write occurs before the legacy-format rejection is raised
Attachment
| Name | purl | apm-cli | pkg:pypi/apm-cli |
|---|
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "apm-cli",
"purl": "pkg:pypi/apm-cli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.13.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.1.0",
"0.1.1",
"0.1.2",
"0.1.4",
"0.1.5",
"0.1.6",
"0.1.7",
"0.10.0",
"0.11.0",
"0.12.0",
"0.12.1",
"0.12.2",
"0.12.3",
"0.12.4",
"0.2.0",
"0.3.0",
"0.4.0",
"0.4.1",
"0.4.2",
"0.4.3",
"0.5.0",
"0.5.1",
"0.5.2",
"0.5.3",
"0.5.4",
"0.5.5",
"0.5.6",
"0.5.7",
"0.5.8",
"0.5.9",
"0.6.0",
"0.6.1",
"0.6.2",
"0.6.3",
"0.7.0",
"0.7.1",
"0.7.2",
"0.7.3",
"0.7.4",
"0.7.5",
"0.7.6",
"0.7.7",
"0.7.8",
"0.7.9",
"0.8.0",
"0.8.1",
"0.8.10",
"0.8.11",
"0.8.12",
"0.8.2",
"0.8.3",
"0.8.4",
"0.8.5",
"0.8.6",
"0.8.7",
"0.8.8",
"0.8.9",
"0.9.0",
"0.9.1",
"0.9.2",
"0.9.3",
"0.9.4"
]
}
],
"aliases": [
"CVE-2026-46383",
"GHSA-mq5j-pw29-jcv3"
],
"details": "### Summary\n\nMicrosoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by `apm install \u003cbundle\u003e` on supported Python 3.10 and 3.11 runtimes. When `apm install` is given a local `.tar.gz` that is not recognized as a plugin-format bundle, APM probes whether it is a legacy `--format apm` bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw `tar.extractall()` without rejecting Windows absolute member names such as `D:/...`.\n\nThis issue is still present on the latest `main` commit at review time (`2b7a931d58a73cbfc0bcf086cea332d204075e27`) and on the latest release (`v0.12.4`). In both cases, a crafted legacy-looking tarball caused an external file to be created or overwritten outside the temporary extraction root before `apm install` finished rejecting the bundle with the expected legacy-format usage error.\n\nThis report is scoped narrowly to Windows installations running Python 3.10 or 3.11.\n\n### Details\n\nThe broken trust boundary is the boundary between an untrusted local bundle artifact and the host filesystem state that APM is allowed to modify while probing that artifact. The attacker-controlled input is the tar member name inside the `.tar.gz` bundle. A crafted archive can include a member whose name is a Windows absolute path such as `D:/apm/run-main-install/outside/legacy-probe-outside-main.txt`.\n\nThe current install caller path still reaches the legacy probe for `.tar.gz` inputs that are not recognized as plugin-format bundles. In `src/apm_cli/commands/install.py`, the local-bundle branch first calls `detect_local_bundle()`. If the path exists, is a tarball, and is not recognized as a plugin-format bundle, the caller still invokes `_looks_like_legacy_apm_bundle()` to distinguish a legacy bundle from an arbitrary tarball and to choose the error message.\n\nThe root cause is in `src/apm_cli/bundle/local_bundle.py`. `_looks_like_legacy_apm_bundle()`:\n\n- opens the tarball,\n- rejects only symlink and hardlink members,\n- and on Python versions earlier than 3.12 calls raw `tar.extractall(tmp)`.\n\nThat helper does not reject Windows absolute member names and does not perform the Windows-aware containment checks already present elsewhere in the same module.\n\nThis is particularly clear because the adjacent `detect_local_bundle()` path in the same file already contains safer pre-extraction validation. It rejects:\n\n- `PureWindowsPath(name).drive`\n- `PureWindowsPath(name).is_absolute()`\n- path traversal via `validate_path_segments(...)`\n\nThat safer validation is not reused by `_looks_like_legacy_apm_bundle()`.\n\nOn Python versions earlier than 3.12, `_looks_like_legacy_apm_bundle()` performs extraction before legacy-format rejection is raised, so archive member names become filesystem writes during bundle classification rather than during an accepted install step. The write occurs before command rejection because the legacy probe must extract the tarball in order to look for `apm.lock.yaml` at the bundle root and confirm that `plugin.json` is absent. As a result, the out-of-root write happens during classification, before the caller raises the legacy-format usage error.\n\nThe issue is not limited to creating new files. On both latest `main` and latest release, the same vulnerable path overwrote an already-existing writable target file with attacker-controlled contents before the command finished legacy-format rejection. It was further verified the same overwrite primitive against a pre-existing project workflow file at `.github/workflows/ci.yml`, replacing its YAML contents before rejection.\n\nThis is a security issue rather than intended package-manager behavior. The user is asking APM to inspect or install a local bundle. The expected behavior is that bundle contents are handled within the extraction sandbox used for that operation. Writing to an arbitrary host path outside the extraction root during pre-install probing is not part of expected local-bundle behavior, and it happens even when APM ultimately rejects the tarball.\n\nThis issue is also distinct from the prior public APM plugin path-escape issue. The prior public issue involved manifest-controlled path escape during plugin normalization in `plugin_parser.py`, where attacker-controlled manifest entries were resolved outside the plugin root during install. This issue is different in input, timing, and code path: it is an archive-member extraction bug in `src/apm_cli/bundle/local_bundle.py` during legacy-bundle probing, before bundle classification completes and before `apm install` rejects the bundle. No manifest processing is required to trigger it.\n\nAs additional same-family scope information, the same Windows absolute-path extraction weakness is also reproducible in apm unpack.In `src/apm_cli/bundle/unpacker.py`, the unpacker rejects `/` and `..` but still misses Windows absolute tar member names before calling `tar.extractall()` on Python versions earlier than 3.12. Because `apm unpack` is deprecated, I am not presenting it as a second standalone vulnerability title; I am including it only as additional affected surface from the same validation family.\n\n### PoC\n\nValidation environment used for the included proof:\n\n- Windows 11 Pro\n- Python 3.11.9 x64\n- Latest `main` commit: `2b7a931d58a73cbfc0bcf086cea332d204075e27`\n- Latest release commit: `6aceef72be490a9c716547f600a2659f3f2826b7` (`v0.12.4`)\n\nMinimal malicious archive contents:\n\n- `bundle/apm.lock.yaml`\n- `D:/apm/run-main-install/outside/legacy-probe-outside-main.txt`\n\nThe first member makes the archive look like a legacy APM bundle. The second member proves the out-of-root write. The outside target path must be writable by the user running APM. The proof uses a user-controlled directory for that reason.\n\nOne straightforward way to build this input is to use Python\u0027s `tarfile` module directly and add:\n\n- `bundle/apm.lock.yaml`\n- `TarInfo(\"D:/apm/run-main-install/outside/legacy-probe-outside-main.txt\")`\n\nwith file content such as:\n\n```text\noutside write via install main\n```\n\nReproduction steps for latest `main`:\n\n1. Check out `microsoft/apm` at `2b7a931d58a73cbfc0bcf086cea332d204075e27`.\n2. Use a real Windows Python 3.11 runtime.\n3. Ensure the `apm_cli` import resolves to the checked-out tree.\n4. Create the malicious legacy-looking tarball described above.\n5. Run:\n\n```powershell\npython -m apm_cli.cli install D:\\apm\\run-main-install\\input\\legacy-bundle.tar.gz\n```\n\nExpected safe behavior:\n\n- APM rejects the tarball without creating or overwriting any host file outside the temporary extraction root.\n\nObserved result on latest `main`:\n\n- the import path resolved to the checked-out `main` tree,\n- the command ended with the expected legacy-format rejection,\n- the process exit code was `2`,\n- and the file below had already been created outside the temporary extraction root:\n\n```text\nD:\\apm\\run-main-install\\outside\\legacy-probe-outside-main.txt\n```\n\nThe file contained:\n\n```text\noutside write via install main\n```\n\nI also verified overwrite, not just creation, by pre-creating a writable target file and then running the same install path. The existing file contents changed from `ORIGINAL-MAIN` to `OVERWRITTEN-MAIN` before rejection.\n\nI further verified overwrite of a pre-existing project workflow file. Before the run, the target file contained:\n\n```yaml\nname: safe\non: [push]\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - run: echo safe\n```\n\nAfter the run, the same file contained attacker-controlled replacement YAML:\n\n```yaml\nname: overwritten\non: [push]\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - run: echo overwritten-by-archive\n```\n\nObserved command output on latest `main`:\n\n```text\n[!] Install interrupted after 0.0s.\nUsage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...\nTry \u0027python -m apm_cli.cli install --help\u0027 for help.\n\nError: \u0027D:\\apm\\run-main-install\\input\\legacy-bundle.tar.gz\u0027 was packed with \u0027--format apm\u0027 (legacy format). \u0027apm install \u003cbundle\u003e\u0027 requires the plugin format. Repack with \u0027apm pack --format plugin --archive\u0027, or use \u0027apm unpack\u0027 to deploy the legacy bundle.\n```\n\nReproduction steps for latest release `v0.12.4`:\n\n1. Check out tag `v0.12.4` / commit `6aceef72be490a9c716547f600a2659f3f2826b7`.\n2. Use the same Windows Python 3.11 runtime.\n3. Ensure the `apm_cli` import resolves to the `v0.12.4` tree.\n4. Create the same malicious tarball shape, for example with:\n\n```text\nD:/apm/run-release-install/outside/legacy-probe-outside-release.txt\n```\n\n5. Run:\n\n```powershell\npython -m apm_cli.cli install D:\\apm\\run-release-install\\input\\legacy-bundle.tar.gz\n```\n\nObserved result on latest release:\n\n- the import path resolved to the checked-out `v0.12.4` tree,\n- the command ended with the expected legacy-format rejection,\n- the process exit code was `2`,\n- and the file below had already been created outside the temporary extraction root:\n\n```text\nD:\\apm\\run-release-install\\outside\\legacy-probe-outside-release.txt\n```\n\nThe file contained:\n\n```text\noutside write via install release\n```\n\nI also verified overwrite, not just creation, on the latest release by pre-creating a writable target file. The existing file contents changed from `ORIGINAL-RELEASE` to `OVERWRITTEN-RELEASE` before rejection. The same workflow-file overwrite pattern was also reproducible on the latest release.\n\nObserved command output on latest release:\n\n```text\n[!] Install interrupted after 0.0s.\nUsage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...\nTry \u0027python -m apm_cli.cli install --help\u0027 for help.\n\nError: \u0027D:\\apm\\run-release-install\\input\\legacy-bundle.tar.gz\u0027 was packed with \u0027--format apm\u0027 (legacy format). \u0027apm install \u003cbundle\u003e\u0027 requires the plugin format. Repack with \u0027apm pack --format plugin --archive\u0027, or use \u0027apm unpack\u0027 to deploy the legacy bundle.\n```\n\nAdditional same-family affected surface:\n\n- `apm unpack` on latest `main` and latest release also created an outside file when given a tarball containing a Windows absolute member name.\n- In that path the command completed successfully with exit code `0`, which further confirms that the Windows absolute-path validation gap is present outside the primary install probe as well.\n\n### Impact\n\nThis is an arbitrary local file overwrite outside the intended extraction root during a current APM install path. The impacted population is Windows users running APM on supported Python 3.10 or 3.11 runtimes. The attacker capability required is the ability to supply a crafted local bundle and induce the victim to run `apm install` on it.\n\nThe strongest demonstrated real-world consequence is attacker-controlled overwrite of an existing writable file at an attacker-selected Windows path outside the extraction root, using the privileges of the user running APM. An overwrite of a project-controlled GitHub Actions workflow file with attacker-controlled YAML before rejection was verified. Workflow execution from this report hasn\u0027t been claimed; the demonstrated consequence is high-integrity modification of a trusted automation file outside the intended extraction boundary.\n\nThe issue is currently reachable on:\n\n- latest `main` at `2b7a931d58a73cbfc0bcf086cea332d204075e27`\n- latest release `v0.12.4`\n\n### Mitigation\n\n1. Reuse the existing pre-extraction validation already implemented in `detect_local_bundle()` for `_looks_like_legacy_apm_bundle()`.\n2. Reject Windows absolute member names before any extraction step.\n3. Apply equivalent Windows absolute-path validation to the unpacker in `src/apm_cli/bundle/unpacker.py`.\n4. Add regression tests for:\n - Windows absolute member paths in the legacy-bundle probe path\n - Windows absolute member paths in the unpack path\n - confirmation that no host write occurs before the legacy-format rejection is raised\n\n### Attachment\n[apm-legacy-probe-windows-absolute-path-write-20260511.zip](https://github.com/user-attachments/files/27578792/apm-legacy-probe-windows-absolute-path-write-20260511.zip)",
"id": "PYSEC-2026-2378",
"modified": "2026-07-13T16:03:31.797125Z",
"published": "2026-07-13T15:19:08.625717Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/microsoft/apm/security/advisories/GHSA-mq5j-pw29-jcv3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46383"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/apm/commit/77d1dda8303c8d7ccb6148788a6274fdece98499"
},
{
"type": "PACKAGE",
"url": "https://github.com/microsoft/apm"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/apm/releases/tag/v0.13.0"
},
{
"type": "PACKAGE",
"url": "https://pypi.org/project/apm-cli"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-mq5j-pw29-jcv3"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Microsoft APM: Windows absolute-path tar member overwrite during legacy-bundle probing in `apm install`"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.