Common Weakness Enumeration

CWE-61

Allowed

UNIX Symbolic Link (Symlink) Following

Abstraction: Compound · Status: Incomplete

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-RCFC-7M3G-H5XH

Vulnerability from github – Published: 2026-06-24 21:30 – Updated: 2026-06-24 21:30
VLAI
Details

A flaw was found in KubeVirt's safepath package. The OpenAtNoFollow function uses O_PATH|O_NOFOLLOW to obtain a file descriptor to a path leaf, but downstream helpers operate via /proc/self/fd/N using link-following syscalls. When the leaf is a symlink, the kernel dereferences it, defeating the intended no-follow protection. An attacker with access to a virt-launcher pod can exploit this to cause virt-handler to apply file ownership or permission changes to an unintended host path.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-13201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T21:16:52Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in KubeVirt\u0027s safepath package. The OpenAtNoFollow function uses O_PATH|O_NOFOLLOW to obtain a file descriptor to a path leaf, but downstream helpers operate via /proc/self/fd/N using link-following syscalls. When the leaf is a symlink, the kernel dereferences it, defeating the intended no-follow protection. An attacker with access to a virt-launcher pod can exploit this to cause virt-handler to apply file ownership or permission changes to an unintended host path.",
  "id": "GHSA-rcfc-7m3g-h5xh",
  "modified": "2026-06-24T21:30:44Z",
  "published": "2026-06-24T21:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13201"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-13201"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492203"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RG2X-37C3-W2RH

Vulnerability from github – Published: 2026-05-18 17:53 – Updated: 2026-06-12 21:59
VLAI
Summary
Docker: Race condition in docker cp allows bind mount redirection to host path
Details

Summary

A race condition during docker cp mount setup allows a malicious container to redirect a bind mount target to an arbitrary host path, potentially overwriting host files or causing denial of service.

Details

When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination is created inside the container root and then a bind mount is attached using the container-relative path resolved to an absolute host path.

Between mountpoint creation and the mount() syscall, a process running inside the container can replace the destination (or a parent path component) with a symlink pointing to an arbitrary location on the host. The mount() syscall follows the symlink, causing the volume to be bind-mounted onto an arbitrary host path instead of the intended container path.

Impact

A malicious container can redirect a volume bind mount to an arbitrary host path. The impact depends on the volume content and mount options:

  • If the volume is writable, arbitrary host files at the redirected path could be overwritten with the volume's contents.
  • If the volume is read-only, the host path is masked by the mount for the duration of the operation, causing denial of service.
  • In all cases the mount is temporary (torn down after the docker cp completes), but the effects of any writes persist.

Conditions for exploitation

  • A container must have at least one volume mount.
  • A process inside the container must be able to rapidly create and swap symlinks at the volume mount destination path.
  • An operator must initiate a docker cp into that container, or call the PUT /containers/{id}/archive or HEAD /containers/{id}/archive API endpoints.

Not affected

  • Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.

Workarounds

  • Only run containers from trusted images.
  • Avoid using docker cp with untrusted running containers.
  • Use authorization plugins to restrict access to the archive API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive).
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "28.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/moby/moby/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0-beta.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/moby/moby"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "28.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:53:08Z",
    "nvd_published_at": "2026-06-12T19:16:27Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA race condition during `docker cp` mount setup allows a malicious container to redirect a bind mount target to an arbitrary host path, potentially overwriting host files or causing denial of service.\n\n## Details\n\nWhen copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination is created inside the container root and then a bind mount is attached using the container-relative path resolved to an absolute host path.\n\nBetween mountpoint creation and the `mount()` syscall, a process running inside the container can replace the destination (or a parent path component) with a symlink pointing to an arbitrary location on the host. The `mount()` syscall follows the symlink, causing the volume to be bind-mounted onto an arbitrary host path instead of the intended container path.\n\n## Impact\n\nA malicious container can redirect a volume bind mount to an arbitrary host path. The impact depends on the volume content and mount options:\n\n- If the volume is writable, arbitrary host files at the redirected path could be overwritten with the volume\u0027s contents.\n- If the volume is read-only, the host path is masked by the mount for the duration of the operation, causing denial of service.\n- In all cases the mount is temporary (torn down after the `docker cp` completes), but the effects of any writes persist.\n\n### Conditions for exploitation\n\n- A container must have at least one volume mount.\n- A process inside the container must be able to rapidly create and swap symlinks at the volume mount destination path.\n- An operator must initiate a `docker cp` into that container, or call the `PUT /containers/{id}/archive` or `HEAD /containers/{id}/archive` API endpoints.\n\n### Not affected\n\n- Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.\n\n## Workarounds\n\n- Only run containers from trusted images.\n- Avoid using `docker cp` with untrusted running containers.\n- Use authorization plugins to restrict access to the archive API endpoints (`PUT /containers/{id}/archive`, `HEAD /containers/{id}/archive`).",
  "id": "GHSA-rg2x-37c3-w2rh",
  "modified": "2026-06-12T21:59:32Z",
  "published": "2026-05-18T17:53:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-rg2x-37c3-w2rh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42306"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker: Race condition in docker cp allows bind mount redirection to host path"
}

GHSA-RG42-3854-X575

Vulnerability from github – Published: 2022-01-27 00:01 – Updated: 2022-10-13 19:00
VLAI
Details

A UNIX Symbolic Link (Symlink) Following vulnerability in the systemd service file for watchman of openSUSE Backports SLE-15-SP3, Factory allows local attackers to escalate to root. This issue affects: openSUSE Backports SLE-15-SP3 watchman versions prior to 4.9.0. openSUSE Factory watchman versions prior to 4.9.0-9.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-21944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-26T09:15:00Z",
    "severity": "HIGH"
  },
  "details": "A UNIX Symbolic Link (Symlink) Following vulnerability in the systemd service file for watchman of openSUSE Backports SLE-15-SP3, Factory allows local attackers to escalate to root. This issue affects: openSUSE Backports SLE-15-SP3 watchman versions prior to 4.9.0. openSUSE Factory watchman versions prior to 4.9.0-9.1.",
  "id": "GHSA-rg42-3854-x575",
  "modified": "2022-10-13T19:00:23Z",
  "published": "2022-01-27T00:01:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21944"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1194470"
    }
  ],
  "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-RGH6-RFWX-V388

Vulnerability from github – Published: 2026-06-19 19:35 – Updated: 2026-06-19 19:35
VLAI
Summary
Arbitrary host CRI log file read via symlink following in CRI checkpoint restore
Details

Impact

A bug was found in containerd where the CRI plugin restores container.log from a checkpoint image without validating a symlinked path. This could result in reading an arbitrary file on the host via kubectl logs.

Patches

This bug has been fixed in the following containerd versions:

  • 2.3.2
  • 2.2.5
  • 2.1.9

Users should update to these versions to resolve the issue.

Workarounds

Ensure that only trusted images and checkpoints are used.

Credits

The containerd project would like to thank @gouldnicholas and @davidrxchester, Yuming Zhang and Song Li of Zhejiang University, Sangwon Ryu (@sangwon090), Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, Robert Prast (@robertprast), Kyle Elliott (@kyle-elliott-tob) of Trail of Bits, and Zhenchen Wang (@Plucky923), who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.

For more information

If you have any questions or comments about this advisory:

To report a security issue in containerd: * Report a new vulnerability * Email us at security@containerd.io

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:35:36Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nA bug was found in containerd where the CRI plugin restores `container.log` from a checkpoint image without validating a symlinked path. This could result in reading an arbitrary file on the host via `kubectl logs`.\n\n### Patches\nThis bug has been fixed in the following containerd versions:\n\n* 2.3.2\n* 2.2.5\n* 2.1.9\n\nUsers should update to these versions to resolve the issue.\n\n### Workarounds\nEnsure that only trusted images and checkpoints are used.\n\n### Credits\nThe containerd project would like to thank @gouldnicholas and @davidrxchester, Yuming Zhang and Song Li of Zhejiang University, Sangwon Ryu (@sangwon090), Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, Robert Prast (@robertprast),\nKyle Elliott (@kyle-elliott-tob) of Trail of Bits, and Zhenchen Wang (@Plucky923), who independently discovered and responsibly disclosed this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)",
  "id": "GHSA-rgh6-rfwx-v388",
  "modified": "2026-06-19T19:35:36Z",
  "published": "2026-06-19T19:35:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/security/advisories/GHSA-rgh6-rfwx-v388"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containerd/containerd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Arbitrary host CRI log file read via symlink following in CRI checkpoint restore"
}

GHSA-V5FW-RCV7-V6F3

Vulnerability from github – Published: 2026-04-11 03:30 – Updated: 2026-04-11 03:30
VLAI
Details

Flatpak xdg-desktop-portal before 1.20.4 and 1.21.x before 1.21.1 allows any Flatpak app to trash any file in the host context via a symlink attack on g_file_trash.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-40354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-11T01:16:16Z",
    "severity": "LOW"
  },
  "details": "Flatpak xdg-desktop-portal before 1.20.4 and 1.21.x before 1.21.1 allows any Flatpak app to trash any file in the host context via a symlink attack on g_file_trash.",
  "id": "GHSA-v5fw-rcv7-v6f3",
  "modified": "2026-04-11T03:30:29Z",
  "published": "2026-04-11T03:30:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/flatpak/xdg-desktop-portal/security/advisories/GHSA-rqr9-jwwf-wxgj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40354"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flatpak/xdg-desktop-portal/releases/tag/1.20.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flatpak/xdg-desktop-portal/releases/tag/1.21.1"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/04/10/14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V8HJ-H8MW-M6G6

Vulnerability from github – Published: 2024-11-15 18:30 – Updated: 2024-11-15 18:30
VLAI
Details

Three vulnerabilities in the CLI of Cisco TelePresence CE and RoomOS could allow an authenticated, local attacker to overwrite arbitrary files on the local file system of an affected device.

These vulnerabilities are due to improper access controls on files that are on the local file system. An attacker could exploit these vulnerabilities by placing a symbolic link in a specific location on the local file system of an affected device. A successful exploit could allow the attacker to overwrite arbitrary files on the affected device. To exploit these vulnerabilities, an attacker would need to have a remote support user account. Note: CVE-2023-20092 does not affect Cisco DX70, DX80, TelePresence MX Series, or TelePresence SX Series devices. Cisco has released software updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20092"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-15T16:15:25Z",
    "severity": "MODERATE"
  },
  "details": "Three vulnerabilities in the CLI of Cisco TelePresence CE and RoomOS could allow an authenticated, local attacker to overwrite arbitrary files on the local file system of an affected device.\n\nThese vulnerabilities are due to improper access controls on files that are on the local file system. An attacker could exploit these vulnerabilities by placing a symbolic link in a specific location on the local file system of an affected device. A successful exploit could allow the attacker to overwrite arbitrary files on the affected device. To exploit these vulnerabilities, an attacker would need to have a remote support user account.\nNote: CVE-2023-20092 does not affect Cisco DX70, DX80, TelePresence MX Series, or TelePresence SX Series devices.\nCisco has released software updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities.",
  "id": "GHSA-v8hj-h8mw-m6g6",
  "modified": "2024-11-15T18:30:50Z",
  "published": "2024-11-15T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20092"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-roomos-file-write-rHKwegKf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VF95-55W6-QMRF

Vulnerability from github – Published: 2025-11-05 18:45 – Updated: 2025-11-15 02:25
VLAI
Summary
youki container escape and denial of service due to arbitrary write gadgets and procfs write redirects
Details

Impact

youki’s apparmor handling performs insufficiently strict write-target validation, which—combined with path substitution during pathname resolution—can allow writes to unintended procfs locations.

Weak write-target check youki only verifies that the destination lies somewhere under procfs. As a result, a write intended for /proc/self/attr/apparmor/exec can succeed even if the path has been redirected to /proc/sys/kernel/hostname(which is also in procfs).

Path substitution While resolving a path component-by-component, a shared-mount race can substitute intermediate components and redirect the final target.

This is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems. https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm

Credits

Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@tonistiigi from Docker) for both independently discovering runc's original vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "youki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-363",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-05T18:45:18Z",
    "nvd_published_at": "2025-11-06T00:15:37Z",
    "severity": "HIGH"
  },
  "details": "### Impact ###\n\nyouki\u2019s apparmor handling performs insufficiently strict write-target validation, which\u2014combined with path substitution during pathname resolution\u2014can allow writes to unintended procfs locations.\n\n**Weak write-target check**\nyouki only verifies that the destination lies somewhere under procfs. As a result, a write intended for `/proc/self/attr/apparmor/exec` can succeed even if the path has been redirected to `/proc/sys/kernel/hostname`(which is also in procfs).\n\n**Path substitution**\nWhile resolving a path component-by-component, a shared-mount race can substitute intermediate components and redirect the final target.\n\nThis is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems.\nhttps://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm\n\n### Credits ###\n\nThanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and T\u00f5nis Tiigi (@tonistiigi from Docker) for both independently discovering runc\u0027s original vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.",
  "id": "GHSA-vf95-55w6-qmrf",
  "modified": "2025-11-15T02:25:28Z",
  "published": "2025-11-05T18:45:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/youki-dev/youki/security/advisories/GHSA-vf95-55w6-qmrf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62596"
    },
    {
      "type": "WEB",
      "url": "https://github.com/youki-dev/youki/commit/5886c91073b9be748bd8d5aed49c4a820548030a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/youki-dev/youki"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/github.com/cyphar/filepath-securejoin/pathrs-lite/procfs"
    },
    {
      "type": "WEB",
      "url": "https://youtu.be/tGseJW_uBB8"
    },
    {
      "type": "WEB",
      "url": "https://youtu.be/y1PaBzxwRWQ"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "youki container escape and denial of service due to arbitrary write gadgets and procfs write redirects"
}

GHSA-VJ76-C3G6-QR5V

Vulnerability from github – Published: 2025-09-24 18:57 – Updated: 2025-11-03 21:34
VLAI
Summary
tar-fs has a symlink validation bypass if destination directory is predictable with a specific tarball
Details

Impact

v3.1.0, v2.1.3, v1.16.5 and below

Patches

Has been patched in 3.1.1, 2.1.4, and 1.16.6

Workarounds

You can use the ignore option to ignore non files/directories.

  ignore (_, header) {
    // pass files & directories, ignore e.g. symlinks
    return header.type !== 'file' && header.type !== 'directory'
  }

Credit

Reported by: Mapta / BugBunny_ai

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "tar-fs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "tar-fs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "tar-fs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.16.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59343"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-24T18:57:04Z",
    "nvd_published_at": "2025-09-24T18:15:42Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n v3.1.0, v2.1.3, v1.16.5 and below\n\n### Patches\nHas been patched in 3.1.1, 2.1.4, and 1.16.6\n\n### Workarounds\nYou can use the ignore option to ignore non files/directories.\n\n```js\n  ignore (_, header) {\n    // pass files \u0026 directories, ignore e.g. symlinks\n    return header.type !== \u0027file\u0027 \u0026\u0026 header.type !== \u0027directory\u0027\n  }\n```\n\n### Credit\nReported by: Mapta / BugBunny_ai",
  "id": "GHSA-vj76-c3g6-qr5v",
  "modified": "2025-11-03T21:34:35Z",
  "published": "2025-09-24T18:57:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mafintosh/tar-fs/security/advisories/GHSA-vj76-c3g6-qr5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59343"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mafintosh/tar-fs/commit/0bd54cdf06da2b7b5b95cd4b062c9f4e0a8c4e09"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mafintosh/tar-fs"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00028.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "tar-fs has a symlink validation bypass if destination directory is predictable with a specific tarball"
}

GHSA-VP62-88P7-QQF5

Vulnerability from github – Published: 2026-05-18 17:52 – Updated: 2026-06-12 21:59
VLAI
Summary
Docker: Race condition in docker cp allows creation of arbitrary empty files on the host via symlink swap
Details

Summary

A race condition during docker cp mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem.

This advisory covers the race during mountpoint creation. The related race during the subsequent mount syscall is tracked in GHSA-rg2x-37c3-w2rh

Details

When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination path is first resolved within the container's root filesystem using GetResourcePath, and then used to create the mountpoint (file or directory) if it does not already exist via createIfNotExists.

Between path resolution and mountpoint creation, a process running inside the container can swap a path component for a symlink pointing to an arbitrary location on the host. Because createIfNotExists operates on the already-resolved absolute path using standard os.MkdirAll and os.OpenFile — which follow symlinks in intermediate path components — the symlink is followed and the file or directory is created outside the container root filesystem, as root.

Impact

A malicious container can create empty files or directories at arbitrary absolute paths on the host filesystem, running as root. This enables persistent denial of service — for example:

  • Converting /etc/docker/daemon.json into a directory prevents the daemon from restarting
  • Creating /etc/nologin prevents user logins
  • Overwriting critical system paths with empty files can break host services

The container does not gain read or write access to existing host files — only the ability to create new empty files or directories at chosen paths.

Conditions for exploitation

  • A container must be running with a process that can rapidly create and swap symlinks at a volume mount destination path.
  • An operator must initiate a docker cp into that container, or call the PUT /containers/{id}/archive or HEAD /containers/{id}/archive API endpoints.

Not affected

  • Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.

Patches

Mountpoint creation is now scoped to the container root using os.Root (Go 1.24+), which refuses to follow symlinks that escape the opened root directory. All filesystem operations in createIfNotExists (MkdirAll, OpenFile) are performed through the os.Root handle, so even if a symlink swap occurs after path resolution, the creation stays confined to the container root.

Workarounds

  • Only run containers from trusted images.
  • Avoid using docker cp with untrusted running containers.
  • Use authorization plugins to restrict access to the archive API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive).
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "28.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/moby/moby/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0-beta.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/moby/moby"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "28.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-61",
      "CWE-81"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:52:55Z",
    "nvd_published_at": "2026-06-12T19:16:26Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA race condition during `docker cp` mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem.\n\nThis advisory covers the race during mountpoint creation. The related race during the subsequent mount syscall is tracked in GHSA-rg2x-37c3-w2rh\n\n## Details\n\nWhen copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination path is first resolved within the container\u0027s root filesystem using `GetResourcePath`, and then used to create the mountpoint (file or directory) if it does not already exist via `createIfNotExists`.\n\nBetween path resolution and mountpoint creation, a process running inside the container can swap a path component for a symlink pointing to an arbitrary location on the host. Because `createIfNotExists` operates on the already-resolved absolute path using standard `os.MkdirAll` and `os.OpenFile` \u2014 which follow symlinks in intermediate path components \u2014 the symlink is followed and the file or directory is created outside the container root filesystem, as root.\n\n## Impact\n\nA malicious container can create empty files or directories at arbitrary absolute paths on the host filesystem, running as root. This enables persistent denial of service \u2014 for example:\n\n- Converting `/etc/docker/daemon.json` into a directory prevents the daemon from restarting\n- Creating `/etc/nologin` prevents user logins\n- Overwriting critical system paths with empty files can break host services\n\nThe container does not gain read or write access to existing host files \u2014 only the ability to create new empty files or directories at chosen paths.\n\n### Conditions for exploitation\n\n- A container must be running with a process that can rapidly create and swap symlinks at a volume mount destination path.\n- An operator must initiate a `docker cp` into that container, or call the `PUT /containers/{id}/archive` or `HEAD /containers/{id}/archive` API endpoints.\n\n### Not affected\n\n- Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.\n\n## Patches\n\nMountpoint creation is now scoped to the container root using `os.Root` (Go 1.24+), which refuses to follow symlinks that escape the opened root directory. All filesystem operations in `createIfNotExists` (`MkdirAll`, `OpenFile`) are performed through the `os.Root` handle, so even if a symlink swap occurs after path resolution, the creation stays confined to the container root.\n\n## Workarounds\n\n- Only run containers from trusted images.\n- Avoid using `docker cp` with untrusted running containers.\n- Use authorization plugins to restrict access to the archive API endpoints (`PUT /containers/{id}/archive`, `HEAD /containers/{id}/archive`).",
  "id": "GHSA-vp62-88p7-qqf5",
  "modified": "2026-06-12T21:59:28Z",
  "published": "2026-05-18T17:52:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-vp62-88p7-qqf5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41568"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker: Race condition in docker cp allows creation of arbitrary empty files on the host via symlink swap"
}

GHSA-VP62-R36R-9XQP

Vulnerability from github – Published: 2026-04-21 18:51 – Updated: 2026-04-27 16:34
VLAI
Summary
Claude Code: Sandbox Escape via Symlink Following Allows Arbitrary File Write Outside Workspace
Details

Claude Code's sandbox did not prevent sandboxed processes from creating symlinks pointing to locations outside the workspace. When Claude Code subsequently wrote to a path within such a symlink, its unsandboxed process followed the symlink and wrote to the target location outside the workspace without prompting the user for confirmation. This allowed a sandbox escape where neither the sandboxed command nor the unsandboxed app could independently write outside the workspace, but their combination could write to arbitrary locations, potentially leading to code execution outside the sandbox. Reliably exploiting this required the ability to add untrusted content into a Claude Code context window to trigger sandboxed code execution via prompt injection.

Users on standard Claude Code auto-update have received this fix automatically. Users performing manual updates are advised to update to the latest version.

Claude Code thanks hackerone.com/philts for reporting this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@anthropic-ai/claude-code"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.64"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39861"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T18:51:21Z",
    "nvd_published_at": "2026-04-21T01:16:06Z",
    "severity": "HIGH"
  },
  "details": "Claude Code\u0027s sandbox did not prevent sandboxed processes from creating symlinks pointing to locations outside the workspace. When Claude Code subsequently wrote to a path within such a symlink, its unsandboxed process followed the symlink and wrote to the target location outside the workspace without prompting the user for confirmation. This allowed a sandbox escape where neither the sandboxed command nor the unsandboxed app could independently write outside the workspace, but their combination could write to arbitrary locations, potentially leading to code execution outside the sandbox. Reliably exploiting this required the ability to add untrusted content into a Claude Code context window to trigger sandboxed code execution via prompt injection.\n\nUsers on standard Claude Code auto-update have received this fix automatically. Users performing manual updates are advised to update to the latest version.\n\nClaude Code thanks hackerone.com/philts for reporting this issue.",
  "id": "GHSA-vp62-r36r-9xqp",
  "modified": "2026-04-27T16:34:21Z",
  "published": "2026-04-21T18:51:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/anthropics/claude-code/security/advisories/GHSA-vp62-r36r-9xqp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39861"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/anthropics/claude-code"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Claude Code: Sandbox Escape via Symlink Following Allows Arbitrary File Write Outside Workspace"
}

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.