CVE-2026-46383

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 <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 vulnerability is fixed in 0.13.0.

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 <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 vulnerability is fixed in 0.13.0.

Summary

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).drive
• PureWindowsPath(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…

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 <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 vulnerability is fixed in 0.13.0.

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 <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 vulnerability is fixed in 0.13.0.

Summary

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).drive
• PureWindowsPath(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…

Summary

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).drive
• PureWindowsPath(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…