{
  "affected": [],
  "aliases": [
    "CVE-2026-21916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-09T22:16:24Z",
    "severity": "HIGH"
  },
  "details": "A UNIX Symbolic Link (Symlink) Following vulnerability in the CLI of Juniper Networks Junos OS allows a local, authenticated attacker with low privileges to escalate their privileges to root which will lead to a complete compromise of the system.\n\nWhen after a user has performed a specific \u0027file link ...\u0027 CLI operation, another user commits (unrelated configuration changes), the first user can login as root.\n\nThis issue affects Junos OS:\n  *  all versions before 23.2R2-S7,\n  *  23.4 versions before 23.4R2-S6,\n  *  24.2 versions before 24.2R2-S3,\n  *  24.4 versions before 24.4R2-S2,\n  *  25.2 versions before 25.2R2.\n\n\nThis issue does not affect versions 25.4R1 or later.",
  "id": "GHSA-x5g9-73r3-vh5h",
  "modified": "2026-04-10T00:30:29Z",
  "published": "2026-04-10T00:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21916"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA107807"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:L/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:Y/R:U/V:X/RE:M/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-54661"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T05:15:07Z",
    "severity": "CRITICAL"
  },
  "details": "readline.sh in socat through 1.8.0.1 relies on the /tmp/$USER/stderr2 file.",
  "id": "GHSA-x9w4-r3mh-39fw",
  "modified": "2025-01-07T03:31:35Z",
  "published": "2024-12-04T06:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54661"
    },
    {
      "type": "WEB",
      "url": "https://repo.or.cz/socat.git/blob/6ff391324d2d3b9f6bfb58e7d16a20be43b47af7:/readline.sh#l29"
    },
    {
      "type": "WEB",
      "url": "http://www.dest-unreach.org/socat/contrib/socat-secadv9.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-39822"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-08T17:17:21Z",
    "severity": "HIGH"
  },
  "details": "On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /. For example, \u0027root.Open(\"symlink/\")\u0027 will open \"symlink\" even when \"symlink\" is a symbolic link pointing outside of the root.",
  "id": "GHSA-xcgv-8mv7-v8c7",
  "modified": "2026-07-08T21:30:27Z",
  "published": "2026-07-08T18:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39822"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/797880"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/79005"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/OrmQE_Yp5Sc"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4970"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-33225"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T18:16:11Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Resiliency Extension for Linux contains a vulnerability in log aggregation, where an attacker could cause predictable log-file names. A successful exploit of this vulnerability may lead to escalation of privileges, code execution, denial of service, information disclosure, and data tampering.",
  "id": "GHSA-xgc9-7wmv-qh48",
  "modified": "2025-12-16T18:31:35Z",
  "published": "2025-12-16T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33225"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5746"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-33225"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-45418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-25T20:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Symlink following in the installer for some Zoom apps for macOS before version 6.1.5 may allow an authenticated user to conduct an escalation of privilege via network access.",
  "id": "GHSA-xjc3-vjh6-m283",
  "modified": "2025-02-25T21:31:43Z",
  "published": "2025-02-25T21:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45418"
    },
    {
      "type": "WEB",
      "url": "https://www.zoom.com/en/trust/security-bulletin/zsb-24040"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "copier"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T22:08:48Z",
    "nvd_published_at": "2026-01-21T23:15:52Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nCopier suggests that it\u0027s safe to generate a project from a safe template, i.e. one that doesn\u0027t use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently include arbitrary files/directories outside the local template clone location by using symlinks along with [`_preserve_symlinks: false`](https://copier.readthedocs.io/en/stable/configuring/#preserve_symlinks) (which is Copier\u0027s default setting). \n\nImagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations and hopes for a user to push the generated project to a public location like [github.com](https://github.com/) where the template author can extract the secrets.\n\nReproducible example:\n\n- Illegally include a file in the generated project via symlink resolution:\n\n    ```shell\n    echo \"s3cr3t\" \u003e secret.txt\n\n    mkdir src/\n    pushd src/\n    ln -s ../secret.txt stolen-secret.txt\n    popd\n\n    uvx copier copy src/ dst/\n\n    cat dst/stolen-secret.txt\n    #s3cr3t\n    ```\n\n- Illegally include a directory in the generated project via symlink resolution:\n\n    ```shell\n    mkdir secrets/\n    pushd secrets/\n    echo \"s3cr3t\" \u003e secret.txt\n    popd\n\n    mkdir src/\n    pushd src/\n    ln -s ../secrets stolen-secrets\n    popd\n\n    uvx copier copy src/ dst/\n\n    tree dst/\n    # dst/\n    # \u2514\u2500\u2500 stolen-secrets\n    #     \u2514\u2500\u2500 secret.txt\n    #\n    # 1 directory, 1 file\n    cat dst/stolen-secrets/secret.txt\n    # s3cr3t\n    ```\n\n### Patches\n\nn/a\n\n### Workarounds\n\nn/a\n\n### References\n\nn/a",
  "id": "GHSA-xjhm-gp88-8pfx",
  "modified": "2026-02-02T16:33:40Z",
  "published": "2026-01-21T22:08:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/copier-org/copier/security/advisories/GHSA-xjhm-gp88-8pfx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23968"
    },
    {
      "type": "WEB",
      "url": "https://github.com/copier-org/copier/commit/b3a7b3772d17cf0e7a4481978188c9f536c8d8f6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/copier-org/copier"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Copier safe template has arbitrary filesystem read access via symlinks when _preserve_symlinks: false"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.0-rc.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0-rc.1"
            },
            {
              "fixed": "1.5.0-rc.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41579"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T20:01:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nWhen setting up the container rootfs, `setupPtmx` and `setupDevSymlinks` call `os.Remove` and `os.Symlink` with a `filepath.Join` string which allow an image with `/dev` as a symlink to trick runc into deleting files called `ptmx` on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.\n\nPlease note that this issue is not exploitable under Docker because [it creates a top-level `ro` layer that masks any malicious `/dev` symlink present in the container image](https://github.com/moby/moby/blob/docker-v29.4.1/daemon/initlayer/setup_unix.go) (this is also done without mounting the lower layers so there is no opportunity for the malicious `/dev` symlink to trick it into resolving to some other path). Unfortunately, Podman and containerd\u003csup\u003e\u0026dagger;\u003c/sup\u003e do not do this and so users using those higher-level runtimes with runc can be exploited via a malicious image.\n\nThis issue mirrors a [somewhat similar issue in crun](https://github.com/containers/crun/security/advisories/GHSA-7vwr-4279-7gq5), which was also published recently.\n\n###### \u0026dagger; Actually, at the time the issue was analysed, [containerd had dead code that implemented this feature](https://github.com/containerd/containerd/blob/v2.2.3/pkg/rootfs/init_linux.go) but the implementation contained several security issues that would arguably have made it more exploitable than in runc. Luckily, the code appears to have never been used (at least since 2017) and [the code has since been removed](https://github.com/containerd/containerd/issues/13238).\n\n#### Mitigating Factors ####\n\nThere are a few mitigating factors about this issue which reduce the impact for most users quite significantly, and is the reason why we decided to release the fix publicly without an embargo.\n\nWhile the deletion of `ptmx` seems like a significant issue, in practice it is quite limited. Notably, `devpts` does not permit you to unlink `/dev/pts/ptmx` regardless of privileges and so it is not a usable target for this attack. Additionally, while `/dev/ptmx` *can* be unlinked\u003csup\u003e\u0026ddagger;\u003c/sup\u003e, trying to use an image with a symlink from `/dev` to `/dev` will cause runc will return an error before it reaches the buggy code (it correctly detects a symlink loop while setting up the mount target and the code correctly scopes the lookup inside the container). Thus, the only files called `ptmx` that are *guaranteed* to exist on the system cannot actually be removed by this bug and so only some user file that happens to have that specific name could be deleted, which seems fairly unlikely to happen on real systems.\n\nAs for the issue of symlinks, again the impact is likely quite limited. While the creation of *arbitrary* symlinks could be used to create drop-in files for system services (and thus lead to a container breakout), the hardcoded set of symlink names and targets that this bug allows you to create on the host make it quite unlikely that you would be able to do much more than pollute the host system with dummy symlinks. Here is the complete list of symlinks that can be created with this attack:\n\n * `core` \u0026rarr; `/proc/kcore`\n * `fd` \u0026rarr; `/proc/self/fd/`\n * `ptmx` \u0026rarr; `pts/ptmx`\n * `stdin` \u0026rarr; `/proc/self/fd/0`\n * `stdout` \u0026rarr; `/proc/self/fd/1`\n * `stderr` \u0026rarr; `/proc/self/fd/2`\n\nNote that none of these symlinks are likely to point to user-controlled data -- the `/proc/self/fd/$n` symlinks are all properties of the process accessing them (so privileged processes will only see the state they were spawned with) and the `pts/ptmx` symlink is almost certainly in the same privilege scope as the directory the symlink itself is in. It seems the only somewhat plausible impact would be that a service could return an error when trying to parse one of these symlinks and thus treat it as an invalid configuration file. How arbitrary processes deal with this situation is a bit hard to analyse, but most daemons require configuration files to have certain suffixes (such as `.conf`) so it\u0027s not really clear how large the impact is in practice and it seems there are a few barriers to clear to use this to cause a DoS or other problems.\n\n###### \u0026ddagger; This would actually be quite problematic if it could occur because `glibc` seemingly only attempts to use `/dev/ptmx` when creating new terminals and thus most terminal managers (including `tmux`) and shell tools (including `sudo` -- but not `su`) would fail to start and thus bring the system to a halt. `setupPtmx` does add a symlink to `/dev/pts/ptmx` afterwards but on some systems the mode of the host `/dev/pts/ptmx` is set to `0o000` which would still cause the same DoS issue.\n\n### Patches\nThis issue has been patched in runc 1.3.6, runc 1.4.3, and runc 1.5.0-rc.3.\n\n### Workarounds\nUsing user namespaces restricts this attack fairly significantly such that the attacker can only create/delete inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don\u0027t use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create or delete inodes in world-writable directories.\n\nLSMs can restrict the scope of where in the host filesystem runc can be tricked into operating on, though how much this helps is questionable. The default `container_runtime_t` SELinux label rules (or custom AppArmor rules for the host `runc` context) may restrict the scope where these filesystem operations can operate on, but we have not done an in-depth analysis on the impact of those kinds of LSM protections.\n\n### Resources\n* commit opencontainers/runc@864db8042dbb (\"rootfs: make /dev initialisation code fd-based\")\n* https://github.com/containers/crun/security/advisories/GHSA-7vwr-4279-7gq5\n\n### Credits\nrunc thanks \"Davias\" for initially finding and reporting this issue. The same underlying issue (with varying levels of completeness) was later reported by Arthur Chan (@arthurscchan from Ada Logics), Junyi Liu (@mosskappa), and Derek Manzella (@Dmanzella).",
  "id": "GHSA-xjvp-4fhw-gc47",
  "modified": "2026-06-22T20:01:35Z",
  "published": "2026-06-22T20:01:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-xjvp-4fhw-gc47"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opencontainers/runc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "runc: Malicious image with /dev symlink can trigger limited host filesystem integrity violations "
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-39578"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-31T08:15:04Z",
    "severity": "MODERATE"
  },
  "details": "Dell PowerScale OneFS versions 8.2.2.x through 9.8.0.1 contains a UNIX symbolic link (symlink) following vulnerability. A local high privileged attacker could potentially exploit this vulnerability, leading to denial of service, information tampering.",
  "id": "GHSA-xmf5-8jhr-2q75",
  "modified": "2024-08-31T09:30:44Z",
  "published": "2024-08-31T09:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39578"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000228207/dsa-2024-346-security-update-for-dell-powerscale-onefs-for-multiple-security-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-52535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-25T15:15:07Z",
    "severity": "HIGH"
  },
  "details": "Dell SupportAssist for Home PCs versions 4.6.1 and prior and Dell SupportAssist for Business PCs versions 4.5.0 and prior, contain a symbolic link (symlink) attack vulnerability in the software remediation component. A low-privileged authenticated user could potentially exploit this vulnerability, gaining privileges escalation, leading to arbitrary deletion of files and folders from the system.",
  "id": "GHSA-xvw3-fvp9-cwjw",
  "modified": "2024-12-25T15:30:42Z",
  "published": "2024-12-25T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52535"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000261086/dsa-2024-470-security-update-for-dell-supportassist-for-home-pcs-and-dell-supportassist-for-business-pcs-vulnerabilities"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "astral-tokio-tar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T17:26:38Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\n\nIn versions 0.6.0 and earlier of astral-tokio-tar, the `unpack_in` API could inadvertently modify the permissions of external (i.e. non-archive) directories outside of the archive. An attacker could use this to contrite a tar archive that maliciously changes directory permissions outside of its intended hierarchy. This flaw only affects directories; individual file permissions cannot be modified via it.\n\nSee GHSA-j4xf-2g29-59ph for the equivalent flaw in the `tar` crate.\n\n### Patches\n\nVersions 0.6.1 and newer of astral-tokio-tar use `fs::symlink_metdata` rather than `fs::metadata`, avoiding the traversal. \n\n### Workarounds\n\nUsers are advised to upgrade to version 0.6.1 or newer to address this advisory.\n\nUsers should experience no breaking changes as a result of the patch above.\n\n### Resources\n\n- GHSA-j4xf-2g29-59ph for the original `tar` vulnerability\n\n### Attribution\n\n- Reporter: Adam Harvey (@lawngnome)",
  "id": "GHSA-xx64-wwv2-hcqq",
  "modified": "2026-05-06T17:26:39Z",
  "published": "2026-05-06T17:26:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/astral-sh/tokio-tar/security/advisories/GHSA-xx64-wwv2-hcqq"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-xx64-wwv2-hcqq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/astral-sh/tokio-tar"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0113.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "astral-tokio-tar: `unpack_in` can chmod arbitrary directories by following symlinks"
}