GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

301 vulnerabilities reference this CWE, most recent first.

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.

Show details on source website

{
  "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.

Show details on source website

{
  "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-H3GQ-CX95-2RPP

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

Dell AppSync Version 4.6.0.0, Dell Metro Node Version 8.0.0, Dell UCC Edge Version 3.0.1, Dell VxRail Version 8.0.322, Dell PowerMax Version 10.3.0, Dell Unity Version 5.4, Dell PowerFlex Manager Version 4.5.4, Dell PowerFlex Intelligent Catalog Versions 46.377.00 and 46.382.00 and Dell PowerFlex Rack version 4.5.4 and prior versions, contain(s) an UNIX Symbolic Link (Symlink) Following vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32657"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-18T18:17:28Z",
    "severity": "HIGH"
  },
  "details": "Dell AppSync Version 4.6.0.0, Dell Metro Node Version 8.0.0, Dell UCC Edge Version 3.0.1, Dell VxRail Version 8.0.322, Dell PowerMax Version 10.3.0, Dell Unity Version 5.4, Dell PowerFlex Manager Version 4.5.4, Dell PowerFlex Intelligent Catalog Versions 46.377.00 and 46.382.00 and Dell PowerFlex Rack version 4.5.4 and prior versions, contain(s) an UNIX Symbolic Link (Symlink) Following vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges.",
  "id": "GHSA-h3gq-cx95-2rpp",
  "modified": "2026-08-18T18:32:01Z",
  "published": "2026-08-18T18:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32657"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000497857/dsa-2026-220-security-update-for-dell-product-vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "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.

Show details on source website

{
  "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

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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"
}

GHSA-J4MM-F543-FJ92

Vulnerability from github – Published: 2024-03-26 15:30 – Updated: 2024-03-26 15:30
VLAI
Details

Insecure UNIX Symbolic Link (Symlink) Following in TeamViewer Remote Client prior Version 15.52 for macOS allows an attacker with unprivileged access, to potentially elevate privileges or conduct a denial-of-service-attack by overwriting the symlink.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-1933"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-26T13:15:45Z",
    "severity": "HIGH"
  },
  "details": "Insecure UNIX Symbolic Link (Symlink) Following in TeamViewer Remote Client prior Version 15.52 for macOS allows an attacker with unprivileged access, to potentially elevate privileges or conduct a denial-of-service-attack by overwriting the symlink.",
  "id": "GHSA-j4mm-f543-fj92",
  "modified": "2024-03-26T15:30:49Z",
  "published": "2024-03-26T15:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1933"
    },
    {
      "type": "WEB",
      "url": "https://www.teamviewer.com/de/resources/trust-center/security-bulletins/tv-2024-1002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J4XF-2G29-59PH

Vulnerability from github – Published: 2026-03-20 17:25 – Updated: 2026-03-25 18:36
VLAI
Summary
tar-rs `unpack_in` can chmod arbitrary directories by following symlinks
Details

Summary

When unpacking a tar archive, the tar crate's unpack_dir function uses fs::metadata() to check whether a path that already exists is a directory. Because fs::metadata() follows symbolic links, a crafted tarball containing a symlink entry followed by a directory entry with the same name causes the crate to treat the symlink target as a valid existing directory — and subsequently apply chmod to it. This allows an attacker to modify the permissions of arbitrary directories outside the extraction root.

Reproducer

A malicious tarball contains two entries: (1) a symlink foo pointing to an arbitrary external directory, and (2) a directory entry foo/. (or just foo). When unpacked, create_dir("foo") fails with EEXIST because the symlink is already on disk. The fs::metadata() check then follows the symlink, sees a directory at the target, and allows processing to continue. The directory entry's mode bits are then applied via chmod, which also follows the symlink — modifying the permissions of the external target directory.

Fix

The fix is very simple, we now use fs::symlink_metadata() in unpack_dir, so symlinks are detected and rejected rather than followed.

Credit

This issue was reported by @xokdvium - thank you!

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.44"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "tar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T17:25:09Z",
    "nvd_published_at": "2026-03-20T08:16:11Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWhen unpacking a tar archive, the `tar` crate\u0027s `unpack_dir` function uses `fs::metadata()` to check whether a path that already exists is a directory. Because `fs::metadata()` follows symbolic links, a crafted tarball containing a symlink entry followed by a directory entry with the same name causes the crate to treat the symlink target as a valid existing directory \u2014 and subsequently apply `chmod` to it. This allows an attacker to modify the permissions of arbitrary directories outside the extraction root.\n\n## Reproducer\n\nA malicious tarball contains two entries: (1) a symlink `foo` pointing to an arbitrary external directory, and (2) a directory entry `foo/.` (or just `foo`). When unpacked, `create_dir(\"foo\")` fails with `EEXIST` because the symlink is already on disk. The `fs::metadata()` check then follows the symlink, sees a directory at the target, and allows processing to continue. The directory entry\u0027s mode bits are then applied via `chmod`, which also follows the symlink \u2014 modifying the permissions of the external target directory.\n\n## Fix \n\nThe fix is very simple, we now use `fs::symlink_metadata()` in `unpack_dir`, so symlinks are detected and rejected rather than followed.\n\n## Credit\n\nThis issue was reported by @xokdvium - thank you!",
  "id": "GHSA-j4xf-2g29-59ph",
  "modified": "2026-03-25T18:36:33Z",
  "published": "2026-03-20T17:25:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/alexcrichton/tar-rs/security/advisories/GHSA-j4xf-2g29-59ph"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33056"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alexcrichton/tar-rs/commit/17b1fd84e632071cb8eef9d3709bf347bd266446"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/alexcrichton/tar-rs"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0067.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "tar-rs `unpack_in` can chmod arbitrary directories by following symlinks"
}

GHSA-JC9G-44F2-XQH4

Vulnerability from github – Published: 2024-12-24 06:30 – Updated: 2025-02-06 09:31
VLAI
Details

A vulnerability was found in Pagure. Support of symbolic links during repository archiving of repositories allows the disclosure of local files. This flaw allows a malicious user to take advantage of the Pagure instance.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-47515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-24T04:15:05Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in Pagure. Support of symbolic links during repository archiving of repositories allows the disclosure of local files. This flaw allows a malicious user to take advantage of the Pagure instance.",
  "id": "GHSA-jc9g-44f2-xqh4",
  "modified": "2025-02-06T09:31:46Z",
  "published": "2024-12-24T06:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47515"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-47515"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2315806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.