Common Weakness Enumeration

CWE-61

Allowed

UNIX Symbolic Link (Symlink) Following

Abstraction: Compound · Status: Incomplete

API response cwe.mitre.org

The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

270 vulnerabilities reference this CWE, most recent first.

GHSA-GF79-FRWR-2V77

Vulnerability from github – Published: 2025-02-13 18:32 – Updated: 2025-02-13 18:32
VLAI
Details

Dell SupportAssist OS Recovery versions prior to 5.5.13.1 contain a symbolic link attack vulnerability. A low-privileged attacker with local access could potentially exploit this vulnerability, leading to arbitrary file deletion and Elevation of Privileges.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-22480"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-13T16:16:48Z",
    "severity": "HIGH"
  },
  "details": "Dell SupportAssist OS Recovery versions prior to 5.5.13.1 contain a symbolic link attack vulnerability. A low-privileged attacker with local access could potentially exploit this vulnerability, leading to arbitrary file deletion and Elevation of Privileges.",
  "id": "GHSA-gf79-frwr-2v77",
  "modified": "2025-02-13T18:32:34Z",
  "published": "2025-02-13T18:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22480"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000275712/dsa-2025-051"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GGJM-F3G4-RWMM

Vulnerability from github – Published: 2025-08-20 19:09 – Updated: 2025-08-21 04:07
VLAI
Summary
n8n symlink traversal vulnerability in "Read/Write File" node allows access to restricted files
Details

Impact

A symlink traversal vulnerability was discovered in the Read/Write File node in n8n. While the node attempts to restrict access to sensitive directories and files, it does not properly account for symbolic links (symlinks). An attacker with the ability to create symlinks—such as by using the Execute Command node—could exploit this to bypass the intended directory restrictions and read from or write to otherwise inaccessible paths. Users of n8n.cloud are not impacted.

Patches

Affected users should update to version 1.106.0 or later.

Workarounds

Until the patch is applied:

  • Disable or restrict access to the Execute Command node and any other nodes that allow arbitrary file system access.
  • Avoid using the Read/Write File node on untrusted paths or inputs that could be manipulated via symlinks.
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.106.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-57749"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-20T19:09:55Z",
    "nvd_published_at": "2025-08-20T22:15:29Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA symlink traversal vulnerability was discovered in the `Read/Write File` node in n8n. While the node attempts to restrict access to sensitive directories and files, it does not properly account for symbolic links (symlinks). An attacker with the ability to create symlinks\u2014such as by using the `Execute Command` node\u2014could exploit this to bypass the intended directory restrictions and read from or write to otherwise inaccessible paths. Users of _n8n.cloud_ are not impacted.\n\n### Patches\nAffected users should update to version 1.106.0 or later.\n\n### Workarounds\nUntil the patch is applied:\n\n- Disable or restrict access to the `Execute Command` node and any other nodes that allow arbitrary file system access.\n- Avoid using the `Read/Write File` node on untrusted paths or inputs that could be manipulated via symlinks.",
  "id": "GHSA-ggjm-f3g4-rwmm",
  "modified": "2025-08-21T04:07:03Z",
  "published": "2025-08-20T19:09:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-ggjm-f3g4-rwmm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57749"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/pull/17735"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/c2c3e08cdf33570d9051e659812cbfbdd3c077fd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "n8n symlink traversal vulnerability in \"Read/Write File\" node allows access to restricted files"
}

GHSA-GHQ2-5C67-FPRM

Vulnerability from github – Published: 2026-06-10 20:32 – Updated: 2026-06-10 20:32
VLAI
Summary
PDM: Project-Local State and Config Writes Follow Symlinks
Details

Summary

PDM writes several project-local state or configuration files without symlink protection. If a malicious repository places those files as symlinks, local PDM operations can overwrite the symlink targets.

This creates an arbitrary file clobber primitive relative to the privileges of the invoking user.

Affected Behavior

  • Project-local config writes can affect files outside the repository
  • The most stable demonstrated sink is pdm.toml
  • Related sinks include .pdm-python and .python-version

Affected Code

  • src/pdm/project/config.py:303-350
  • src/pdm/project/core.py:209-217
  • src/pdm/cli/commands/use.py:187-189

Technical Details

Config.__init__() resolves the project-local pdm.toml path and _save_config() writes to the resolved target. If PROJECT_ROOT/pdm.toml is a symlink to another file, pdm config -l ... updates the target file instead of refusing the write.

The same general problem exists for other project-local persistence paths that are written directly with no lstat / O_NOFOLLOW protection.

For the pdm.toml PoC specifically, the target file must already contain parseable TOML. Otherwise the load step fails before the write path is reached. That parser constraint does not apply to the .pdm-python or .python-version sinks.

Impact

  • Arbitrary file clobber as the invoking user
  • Destructive modification of local files outside the repository root
  • Useful primitive for privilege abuse when pdm is run in elevated contexts

Reproduction

PoC:

# Replace this with a Python interpreter that can run `python -m pdm`.
PDM_PY=/path/to/python-with-pdm
tmpdir=$(mktemp -d)
target="$tmpdir/clobbered-target.toml"

cat > "$target" <<'EOF'
[seed]
value = 1
EOF

ln -s "$target" "$tmpdir/pdm.toml"

cat > "$tmpdir/pyproject.toml" <<'EOF'
[project]
name = "symlink-clobber-demo"
version = "0.0.1"
EOF

(
  cd "$tmpdir" &&
  "$PDM_PY" -m pdm config -l venv.in_project false
)

cat "$target"

Expected result:

  • A temporary project is created
  • pdm.toml is a symlink to another TOML file
  • Running pdm config -l venv.in_project false modifies the symlink target

Observed output from local validation:

--- target ---
[seed]
value = 1

[venv]
in_project = false

Severity

Medium

CVSS v4.0

  • Base score: 6.8 (Medium)
  • Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N

Rationale:

  • AV:L: exploitation requires local execution of pdm against an attacker-prepared checkout
  • AC:L: there is no complex constraint once the symlink sink exists
  • AT:N: no extra prerequisite beyond the victim running the relevant command is required
  • PR:N: the attacker does not need prior privileges on the victim system
  • UI:A: the victim must actively run a command that writes project-local state or config
  • VC:N: the demonstrated issue is a write primitive, not a direct read primitive
  • VI:H: the attacker can cause unauthorized modification of files outside the repository root
  • VA:L: file clobber can disrupt local operation, but direct same-step availability impact is lower than a full RCE
  • SC:N/SI:N/SA:N: the base score is limited to the directly affected system

Root Cause

Project-local file sinks are treated as trusted regular files and are written without symlink checks or guarded atomic replacement.

Recommended Remediation

  • Refuse to write project-local config/state files when the destination is a symlink
  • Use lstat and O_NOFOLLOW where available
  • Avoid resolving attacker-controlled project-local paths before writing
  • Use atomic temp-file replacement only after confirming the destination is a regular file

Disclosure Notes

This issue is independent from the code-execution issues above. It is best tracked as a separate CVE candidate because the root cause and remediation are different.

Severity
6.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pdm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T20:32:56Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nPDM writes several project-local state or configuration files without symlink protection. If a malicious repository places those files as symlinks, local PDM operations can overwrite the symlink targets.\n\nThis creates an arbitrary file clobber primitive relative to the privileges of the invoking user.\n\n## Affected Behavior\n\n- Project-local config writes can affect files outside the repository\n- The most stable demonstrated sink is `pdm.toml`\n- Related sinks include `.pdm-python` and `.python-version`\n\n## Affected Code\n\n- `src/pdm/project/config.py:303-350`\n- `src/pdm/project/core.py:209-217`\n- `src/pdm/cli/commands/use.py:187-189`\n\n## Technical Details\n\n`Config.__init__()` resolves the project-local `pdm.toml` path and `_save_config()` writes to the resolved target. If `PROJECT_ROOT/pdm.toml` is a symlink to another file, `pdm config -l ...` updates the target file instead of refusing the write.\n\nThe same general problem exists for other project-local persistence paths that are written directly with no `lstat` / `O_NOFOLLOW` protection.\n\nFor the `pdm.toml` PoC specifically, the target file must already contain parseable TOML. Otherwise the load step fails before the write path is reached. That parser constraint does not apply to the `.pdm-python` or `.python-version` sinks.\n\n## Impact\n\n- Arbitrary file clobber as the invoking user\n- Destructive modification of local files outside the repository root\n- Useful primitive for privilege abuse when `pdm` is run in elevated contexts\n\n## Reproduction\n\nPoC:\n\n```bash\n# Replace this with a Python interpreter that can run `python -m pdm`.\nPDM_PY=/path/to/python-with-pdm\ntmpdir=$(mktemp -d)\ntarget=\"$tmpdir/clobbered-target.toml\"\n\ncat \u003e \"$target\" \u003c\u003c\u0027EOF\u0027\n[seed]\nvalue = 1\nEOF\n\nln -s \"$target\" \"$tmpdir/pdm.toml\"\n\ncat \u003e \"$tmpdir/pyproject.toml\" \u003c\u003c\u0027EOF\u0027\n[project]\nname = \"symlink-clobber-demo\"\nversion = \"0.0.1\"\nEOF\n\n(\n  cd \"$tmpdir\" \u0026\u0026\n  \"$PDM_PY\" -m pdm config -l venv.in_project false\n)\n\ncat \"$target\"\n```\n\nExpected result:\n\n- A temporary project is created\n- `pdm.toml` is a symlink to another TOML file\n- Running `pdm config -l venv.in_project false` modifies the symlink target\n\nObserved output from local validation:\n\n```text\n--- target ---\n[seed]\nvalue = 1\n\n[venv]\nin_project = false\n```\n\n## Severity\n\nMedium\n\n## CVSS v4.0\n\n- Base score: `6.8` (`Medium`)\n- Vector: `CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N`\n\nRationale:\n\n- `AV:L`: exploitation requires local execution of `pdm` against an attacker-prepared checkout\n- `AC:L`: there is no complex constraint once the symlink sink exists\n- `AT:N`: no extra prerequisite beyond the victim running the relevant command is required\n- `PR:N`: the attacker does not need prior privileges on the victim system\n- `UI:A`: the victim must actively run a command that writes project-local state or config\n- `VC:N`: the demonstrated issue is a write primitive, not a direct read primitive\n- `VI:H`: the attacker can cause unauthorized modification of files outside the repository root\n- `VA:L`: file clobber can disrupt local operation, but direct same-step availability impact is lower than a full RCE\n- `SC:N/SI:N/SA:N`: the base score is limited to the directly affected system\n\n## Root Cause\n\nProject-local file sinks are treated as trusted regular files and are written without symlink checks or guarded atomic replacement.\n\n## Recommended Remediation\n\n- Refuse to write project-local config/state files when the destination is a symlink\n- Use `lstat` and `O_NOFOLLOW` where available\n- Avoid resolving attacker-controlled project-local paths before writing\n- Use atomic temp-file replacement only after confirming the destination is a regular file\n\n## Disclosure Notes\n\nThis issue is independent from the code-execution issues above. It is best tracked as a separate CVE candidate because the root cause and remediation are different.",
  "id": "GHSA-ghq2-5c67-fprm",
  "modified": "2026-06-10T20:32:56Z",
  "published": "2026-06-10T20:32:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pdm-project/pdm/security/advisories/GHSA-ghq2-5c67-fprm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pdm-project/pdm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pdm-project/pdm/releases/tag/2.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PDM: Project-Local State and Config Writes Follow Symlinks"
}

GHSA-GMW6-94GG-2RC2

Vulnerability from github – Published: 2021-08-31 16:03 – Updated: 2022-06-17 20:51
VLAI
Summary
UNIX Symbolic Link (Symlink) Following in @npmcli/arborist
Details

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

@npmcli/arborist, the library that calculates dependency trees and manages the node_modules folder hierarchy for the npm command line interface, aims to guarantee that package dependency contracts will be met, and the extraction of package contents will always be performed into the expected folder.

This is accomplished by extracting package contents into a project's node_modules folder.

If the node_modules folder of the root project or any of its dependencies is somehow replaced with a symbolic link, it could allow Arborist to write package dependencies to any arbitrary location on the file system.

Note that symbolic links contained within package artifact contents are filtered out, so another means of creating a node_modules symbolic link would have to be employed.

  1. A preinstall script could replace node_modules with a symlink. (This is prevented by using --ignore-scripts.)
  2. An attacker could supply the target with a git repository, instructing them to run npm install --ignore-scripts in the root. This may be successful, because npm install --ignore-scripts is typically not capable of making changes outside of the project directory, so it may be deemed safe.

Patches

2.8.2 (included in npm v7.20.7 and above)

Workarounds

Do not run npm install on untrusted codebases, without first ensuring that the node_modules directory in the project is not a symbolic link.

Fix

Prior to extracting any package contents, the node_modules folder into which it is extracted is verified to be a real directory. If it is not, then it is removed.

Caveat: if you are currently relying on creating a symbolic link to the node_modules folder in order to share dependencies between projects, then that will no longer be possible. Please use the npm link command, explicit file:... dependencies, and/or workspaces to share dependencies in a development environment.

Severity
8.2 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@npmcli/arborist"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-39135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-31T16:03:00Z",
    "nvd_published_at": "2021-08-31T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\n`@npmcli/arborist`, the library that calculates dependency trees and manages the node_modules folder hierarchy for the npm command line interface, aims to guarantee that package dependency contracts will be met, and the extraction of package contents will always be performed into the expected folder.\n\nThis is accomplished by extracting package contents into a project\u0027s `node_modules` folder.\n\nIf the `node_modules` folder of the root project or any of its dependencies is somehow replaced with a symbolic link, it could allow Arborist to write package dependencies to any arbitrary location on the file system.\n\nNote that symbolic links contained within package artifact contents are filtered out, so another means of creating a `node_modules` symbolic link would have to be employed.\n\n1. A `preinstall` script could replace `node_modules` with a symlink.  (This is prevented by using `--ignore-scripts`.)\n2. An attacker could supply the target with a git repository, instructing them to run `npm install --ignore-scripts` in the root.  This may be successful, because `npm install --ignore-scripts` is typically not capable of making changes outside of the project directory, so it may be deemed safe.\n\n### Patches\n\n2.8.2 (included in npm v7.20.7 and above)\n\n### Workarounds\n\nDo not run `npm install` on untrusted codebases, without first ensuring that the `node_modules` directory in the project is not a symbolic link.\n\n### Fix\n\nPrior to extracting any package contents, the `node_modules` folder into which it is extracted is verified to be a real directory.  If it is not, then it is removed.\n\nCaveat: if you are currently relying on creating a symbolic link to the `node_modules` folder in order to share dependencies between projects, then that will no longer be possible.  Please use the `npm link` command, explicit `file:...` dependencies, and/or `workspaces` to share dependencies in a development environment.",
  "id": "GHSA-gmw6-94gg-2rc2",
  "modified": "2022-06-17T20:51:19Z",
  "published": "2021-08-31T16:03:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/npm/arborist/security/advisories/GHSA-gmw6-94gg-2rc2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39135"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/npm/arborist"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/@npmcli/arborist"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "UNIX Symbolic Link (Symlink) Following in @npmcli/arborist"
}

GHSA-GV85-3994-QPRW

Vulnerability from github – Published: 2026-05-14 15:31 – Updated: 2026-05-14 15:31
VLAI
Details

Vvveb before 1.0.8.3 contains an unrestricted file upload vulnerability in the plugin upload endpoint that allows super_admin users to execute arbitrary PHP code by uploading a malicious plugin ZIP file. Attackers can craft a ZIP containing a plugin.php with a valid Slug header and a public/index.php file with arbitrary PHP code, which executes as the web server user when accessed via unauthenticated HTTP requests to the plugin's public path.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-41937"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-14T15:16:46Z",
    "severity": "HIGH"
  },
  "details": "Vvveb before 1.0.8.3 contains an unrestricted file upload vulnerability in the plugin upload endpoint that allows super_admin users to execute arbitrary PHP code by uploading a malicious plugin ZIP file. Attackers can craft a ZIP containing a plugin.php with a valid Slug header and a public/index.php file with arbitrary PHP code, which executes as the web server user when accessed via unauthenticated HTTP requests to the plugin\u0027s public path.",
  "id": "GHSA-gv85-3994-qprw",
  "modified": "2026-05-14T15:31:59Z",
  "published": "2026-05-14T15:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41937"
    },
    {
      "type": "WEB",
      "url": "https://github.com/givanz/Vvveb/commit/04f0294350ec429e307cd31c2e777a4797c868d6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/givanz/Vvveb/releases/tag/1.0.8.3"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vvveb-unrestricted-file-upload-rce-via-plugin-upload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/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"
    }
  ]
}

GHSA-GWQW-93FQ-PW78

Vulnerability from github – Published: 2026-06-11 21:31 – Updated: 2026-06-13 00:34
VLAI
Details

This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Sequoia 15.4. An app may be able to access protected user data.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-43278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-11T19:16:33Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Sequoia 15.4. An app may be able to access protected user data.",
  "id": "GHSA-gwqw-93fq-pw78",
  "modified": "2026-06-13T00:34:30Z",
  "published": "2026-06-11T21:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43278"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122373"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HR4R-FWPV-C95J

Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-18 14:56
VLAI
Summary
pgAdmin 4 File Manager has symbolic-link path traversal
Details

Symbolic-link path traversal (CWE-61, CWE-22) in pgAdmin 4 File Manager.

check_access_permission used os.path.abspath, which resolves '..' but does not resolve symbolic links, while the subsequent kernel write follows symlinks. An authenticated user could plant a symbolic link inside their own storage directory pointing outside it and induce pgAdmin to write to any path reachable by the pgAdmin process.

Fix switches the access check to os.path.realpath for both source and destination, and adds an _open_upload_target helper that opens the target with O_NOFOLLOW (mode 0o600) to close the leaf-component TOCTOU between the access check and the open. File mode is hardened from 0o644 to 0o600.

This issue affects pgAdmin 4: before 9.15.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
7.2 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pgadmin4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-7819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T14:56:48Z",
    "nvd_published_at": "2026-05-11T16:17:39Z",
    "severity": "HIGH"
  },
  "details": "Symbolic-link path traversal (CWE-61, CWE-22) in pgAdmin 4 File Manager.\n\ncheck_access_permission used os.path.abspath, which resolves \u0027..\u0027 but does not resolve symbolic links, while the subsequent kernel write follows symlinks. An authenticated user could plant a symbolic link inside their own storage directory pointing outside it and induce pgAdmin to write to any path reachable by the pgAdmin process.\n\nFix switches the access check to os.path.realpath for both source and destination, and adds an _open_upload_target helper that opens the target with O_NOFOLLOW (mode 0o600) to close the leaf-component TOCTOU between the access check and the open. File mode is hardened from 0o644 to 0o600.\n\nThis issue affects pgAdmin 4: before 9.15.",
  "id": "GHSA-hr4r-fwpv-c95j",
  "modified": "2026-05-18T14:56:48Z",
  "published": "2026-05-11T18:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7819"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgadmin-org/pgadmin4/issues/9902"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgadmin-org/pgadmin4/commit/435752b83"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pgadmin-org/pgadmin4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": " pgAdmin 4 File Manager has symbolic-link path traversal"
}

GHSA-J26P-6WX7-F3PW

Vulnerability from github – Published: 2025-08-14 16:39 – Updated: 2025-08-14 19:37
VLAI
Summary
Youki: If /proc and /sys in the rootfs are symbolic links, they can potentially be exploited to gain access to the host root filesystem.
Details

Summary

If /proc and /sys in the rootfs are symbolic links, they can potentially be exploited to gain access to the host root filesystem.

Details

For security reasons, container creation should be prohibited if /proc or /sys in the rootfs is a symbolic link. I verified this behavior with youki. When /proc or /sys is a symbolic link, runc fails to create the container, whereas youki successfully creates it.

This is the fix related to this issue in runc. * https://github.com/opencontainers/runc/pull/3756 * https://github.com/opencontainers/runc/pull/3773 * https://github.com/opencontainers/runc/blob/main/libcontainer/rootfs_linux.go#L590 * https://github.com/opencontainers/runc/blob/main/tests/integration/mask.bats#L60

Impact

The following advisory appears to be related to this vulnerability: * https://github.com/advisories/GHSA-vpvm-3wq2-2wvm * https://github.com/advisories/GHSA-fh74-hm69-rqjw

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "youki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-14T16:39:04Z",
    "nvd_published_at": "2025-08-14T16:15:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nIf `/proc` and `/sys` in the rootfs are symbolic links, they can potentially be exploited to gain access to the host root filesystem.\n\n### Details\n\nFor security reasons, container creation should be prohibited if `/proc` or `/sys` in the rootfs is a symbolic link.\nI verified this behavior with `youki`.\nWhen `/proc` or `/sys` is a symbolic link, `runc` fails to create the container, whereas `youki` successfully creates it.\n\nThis is the fix related to this issue in `runc`.\n* https://github.com/opencontainers/runc/pull/3756\n* https://github.com/opencontainers/runc/pull/3773\n* https://github.com/opencontainers/runc/blob/main/libcontainer/rootfs_linux.go#L590\n* https://github.com/opencontainers/runc/blob/main/tests/integration/mask.bats#L60\n\n\n### Impact\n\nThe following advisory appears to be related to this vulnerability:\n* https://github.com/advisories/GHSA-vpvm-3wq2-2wvm\n* https://github.com/advisories/GHSA-fh74-hm69-rqjw",
  "id": "GHSA-j26p-6wx7-f3pw",
  "modified": "2025-08-14T19:37:22Z",
  "published": "2025-08-14T16:39:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/youki-dev/youki/security/advisories/GHSA-j26p-6wx7-f3pw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54867"
    },
    {
      "type": "WEB",
      "url": "https://github.com/youki-dev/youki/commit/0d9b4f2aa5ceaf988f3eb568711d2acf0a4ace37"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/youki-dev/youki"
    },
    {
      "type": "WEB",
      "url": "https://github.com/youki-dev/youki/releases/tag/v0.5.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Youki: If /proc and /sys in the rootfs are symbolic links, they can potentially be exploited to gain access to the host root filesystem."
}

GHSA-J33G-47H2-2687

Vulnerability from github – Published: 2026-07-14 09:31 – Updated: 2026-07-14 09:31
VLAI
Details

A UNIX Symbolic Link (Symlink) Following vulnerability in openSUSE Tumbleweed suricata package allows the suricata user to escalate to root.

This issue affects openSUSE Tumbleweed: from ? before 8.0.5-2.1; openSUSE Tumbleweed: from ? before 8.0.5-2.1.

Severity
7.1 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P/S:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-59674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T08:16:22Z",
    "severity": "HIGH"
  },
  "details": "A UNIX Symbolic Link (Symlink) Following vulnerability in openSUSE Tumbleweed suricata package allows the suricata user to escalate to root.\n\n\n\n\n\n\nThis issue affects openSUSE Tumbleweed: from ? before 8.0.5-2.1; openSUSE Tumbleweed: from ? before 8.0.5-2.1.",
  "id": "GHSA-j33g-47h2-2687",
  "modified": "2026-07-14T09:31:42Z",
  "published": "2026-07-14T09:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59674"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2026-59674"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P/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:N/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-J3RW-FX6G-Q46J

Vulnerability from github – Published: 2025-12-02 21:10 – Updated: 2025-12-02 21:10
VLAI
Summary
Apptainer ineffectively applies selinux and apparmor --security options
Details

Impact

In Apptainer versions less than 1.4.5, a container can disable two of the forms of the little used --security option, in particular the forms --security=apparmor:<profile> and --security=selinux:<label> which otherwise put restrictions on operations that containers can do. The --security option has always been mentioned in Apptainer documentation as being a feature for the root user, although these forms do also work for unprivileged users on systems where the corresponding feature is enabled. Apparmor is enabled by default on Debian-based distributions and SElinux is enabled by default on RHEL-based distributions, but on SUSE it depends on the distribution version.

In addition, a bug in the detection of selinux support in Apptainer's suid mode means that --security selinux:<label> flags may not be applied, even in the absence of an attack. In that case a warning message is emitted indicating that selinux is unavailable, but the warning may be may be overlooked, mis-interpreted, or not seen when apptainer is run from a script or other tool. Failure to apply requested restrictions should result in a fatal error rather than just a warning message.

Patches

Ineffective write of selinux process labels is addressed via an update to the containers/selinux dependency in https://github.com/apptainer/apptainer/pull/3226. That update brings in the upstream fix for https://github.com/advisories/GHSA-cgrx-mc8f-2prm which was for a different but related vulnerability.

Ineffective write of apparmor process profiles is addressed in commit 4313b42.

Failure to detect apparmor / selinux support, when --security flags are provided, is made an error rather than a warning in commit 82f1790.

Workarounds

There are no known workarounds, other than to define system-wide apparmor / selinux policy for Apptainer itself. This would apply to all containers, not just those run with the --security flags, and could impact the operation of Apptainer itself.

References

Thanks to Sylabs for finding this issue, fixing it in https://github.com/sylabs/singularity/security/advisories/GHSA-wwrx-w7c9-rf87 which was easy to import into Apptainer, and disclosing it early to the Apptainer project for a coordinated release.

The related upstream runc disclosure which inspired the investigation is https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm.

Severity
4.5 (Medium)
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/apptainer/apptainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-65105"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61",
      "CWE-706"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-02T21:10:04Z",
    "nvd_published_at": "2025-12-02T18:15:48Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nIn Apptainer versions less than 1.4.5, a container can disable two of the forms of the little used `--security` option, in particular the forms `--security=apparmor:\u003cprofile\u003e` and `--security=selinux:\u003clabel\u003e` which otherwise put restrictions on operations that containers can do.  The `--security` option has always been mentioned in Apptainer documentation as being a feature for the root user, although these forms do also work for unprivileged users on systems where the corresponding feature is enabled.  Apparmor is enabled by default on Debian-based distributions and SElinux is enabled by default on RHEL-based distributions, but on SUSE it depends on the distribution version.\n\nIn addition, a bug in the detection of selinux support in Apptainer\u0027s suid mode means that `--security selinux:\u003clabel\u003e` flags may not be applied, even in the absence of an attack.  In that case a warning message is emitted indicating that selinux is unavailable, but the warning may be may be overlooked, mis-interpreted, or not seen when apptainer is run from a script or other tool.  Failure to apply requested restrictions should result in a fatal error rather than just a warning message.\n\n### Patches\nIneffective write of selinux process labels is addressed via an update to the containers/selinux dependency in https://github.com/apptainer/apptainer/pull/3226. That update brings in the upstream fix for https://github.com/advisories/GHSA-cgrx-mc8f-2prm which was for a different but related vulnerability.\n\nIneffective write of apparmor process profiles is addressed in commit 4313b42.\n\nFailure to detect apparmor / selinux support, when --security flags are provided, is made an error rather than a warning in commit 82f1790.\n\n### Workarounds\nThere are no known workarounds, other than to define system-wide apparmor / selinux policy for Apptainer itself. This would apply to all containers, not just those run with the `--security` flags, and could impact the operation of Apptainer itself.\n\n### References\nThanks to Sylabs for finding this issue, fixing it in https://github.com/sylabs/singularity/security/advisories/GHSA-wwrx-w7c9-rf87 which was easy to import into Apptainer, and disclosing it early to the Apptainer project for a coordinated release.\n\nThe related upstream runc disclosure which inspired the investigation is https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm.",
  "id": "GHSA-j3rw-fx6g-q46j",
  "modified": "2025-12-02T21:10:04Z",
  "published": "2025-12-02T21:10:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apptainer/apptainer/security/advisories/GHSA-j3rw-fx6g-q46j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sylabs/singularity/security/advisories/GHSA-wwrx-w7c9-rf87"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65105"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apptainer/apptainer/pull/3226"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apptainer/apptainer/commit/4313b42717e18a4add7dd7503528bc15af905981"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apptainer/apptainer/commit/82f17900a0c31bc769bf9b4612d271c7068d8bf2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apptainer/apptainer"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apptainer ineffectively applies selinux and apparmor --security options"
}
Mitigation
Implementation

Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.

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-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.

← Back to the CWE list