{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.32.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.33.0-alpha.0"
            },
            {
              "fixed": "1.33.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.34.0-alpha.0"
            },
            {
              "fixed": "1.34.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-13281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-16T00:48:30Z",
    "nvd_published_at": "2025-12-14T22:15:36Z",
    "severity": "MODERATE"
  },
  "details": "A half-blind Server Side Request Forgery (SSRF) vulnerability exists in kube-controller-manager when using the in-tree Portworx StorageClass. This vulnerability allows authorized users to leak arbitrary information from unprotected endpoints in the control plane\u2019s host network (including link-local or loopback services).",
  "id": "GHSA-r6j8-c6r2-37rr",
  "modified": "2025-12-20T03:27:50Z",
  "published": "2025-12-15T00:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13281"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/135525"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/commit/7506ce804c20696ba32cdb72126270ceaed06e24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/commit/97650c1c4fe15cbb7756ba95b3edc8a8665063ca"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/commit/dbe17dfe7773563eac95534040f413ada6d2b421"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-r6j8-c6r2-37rr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubernetes/kubernetes"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/kubernetes-security-announce/c/EORqZg0k1l4/m/TtD-q0v7AgAJ"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/12/01/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kube-controller-manager is vulnerable to half-blind Server Side Request Forgery through in-tree Portworx StorageClass"
}

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