Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package local-static-provisioner version 2.6.0-r1 fixes 18 vulnerabilities: ghsa-7fxm-f474-hf8w, ghsa-q78c-gwqw-jcmc, CVE-2023-3676, CVE-2023-3955, ghsa-hq6q-c2x6-hmch...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "local-static-provisioner"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.0-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.6.0-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package local-static-provisioner version 2.6.0-r1 fixes 18 vulnerabilities: ghsa-7fxm-f474-hf8w, ghsa-q78c-gwqw-jcmc, CVE-2023-3676, CVE-2023-3955, ghsa-hq6q-c2x6-hmch...",
"id": "CLEANSTART-2026-IF32046",
"modified": "2026-08-14T05:57:16Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in local-static-provisioner 2.6.0-r1",
"upstream": [
"ghsa-7fxm-f474-hf8w",
"ghsa-q78c-gwqw-jcmc",
"CVE-2023-3676",
"CVE-2023-3955",
"ghsa-hq6q-c2x6-hmch",
"CVE-2023-5528",
"ghsa-pxhw-596r-rwq5",
"CVE-2024-3177",
"ghsa-82m2-cv7p-4m75",
"CVE-2024-5321",
"ghsa-p77j-4mvh-x3m3",
"CVE-2026-33186",
"ghsa-m425-mq94-257g",
"CVE-2023-44487",
"ghsa-8r3f-844c-mc37",
"CVE-2024-24786",
"ghsa-cgrx-mc8f-2prm",
"CVE-2025-52881"
]
}
GHSA-82M2-CV7P-4M75
Vulnerability from github – Published: 2024-07-18 21:30 – Updated: 2024-11-18 16:26A security issue was discovered in Kubernetes clusters with Windows nodes where BUILTIN\Users may be able to read container logs and NT AUTHORITY\Authenticated Users may be able to modify container logs.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.28.0"
},
{
"fixed": "1.28.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.29.0"
},
{
"fixed": "1.29.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.30.0"
},
{
"fixed": "1.30.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-5321"
],
"database_specific": {
"cwe_ids": [
"CWE-276"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-18T21:58:12Z",
"nvd_published_at": "2024-07-18T19:15:12Z",
"severity": "HIGH"
},
"details": "A security issue was discovered in Kubernetes clusters with Windows nodes where BUILTIN\\Users\u00a0may be able to read container logs and NT AUTHORITY\\Authenticated Users\u00a0may be able to modify container logs.",
"id": "GHSA-82m2-cv7p-4m75",
"modified": "2024-11-18T16:26:53Z",
"published": "2024-07-18T21:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5321"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/126161"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/23660a78ae462a6c8c75ac7ffd9af97550dda1aa"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/84beb2915fa28ae477fe0676be8ba94ccd2b811a"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/90589b8f63d28bcd3db89749950ebc48ed07c190"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/de2033033b1d202ecaaa79d41861a075df8b49c1"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubernetes/kubernetes"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/kubernetes-security-announce/c/81c0BHkKNt0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kubernetes sets incorrect permissions on Windows containers logs"
}
GHSA-8R3F-844C-MC37
Vulnerability from github – Published: 2024-03-06 00:31 – Updated: 2024-11-07 19:19The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.33.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/protobuf/encoding/protojson"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.33.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/protobuf/internal/encoding/json"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.33.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-24786"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-13T21:01:28Z",
"nvd_published_at": "2024-03-05T23:15:07Z",
"severity": "MODERATE"
},
"details": "The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set.",
"id": "GHSA-8r3f-844c-mc37",
"modified": "2024-11-07T19:19:40Z",
"published": "2024-03-06T00:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24786"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf-go/commit/f01a588e5810b90996452eec4a28f22a0afae023"
},
{
"type": "PACKAGE",
"url": "https://github.com/protocolbuffers/protobuf-go"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf-go/releases/tag/v1.33.0"
},
{
"type": "WEB",
"url": "https://go.dev/cl/569356"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JDMBHAVSDU2FBDZ45U3A2VLSM35OJ2HU"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-2611"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240517-0002"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/03/08/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Golang protojson.Unmarshal function infinite loop when unmarshaling certain forms of invalid JSON"
}
GHSA-CGRX-MC8F-2PRM
Vulnerability from github – Published: 2025-11-05 18:40 – Updated: 2025-11-18 18:38Impact
This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy tmpfs file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.
Rather than using a fake tmpfs file for /proc/self/attr/<label>, an attacker could instead (through various means) make /proc/self/attr/<label> reference a real procfs file, but one that would still be a no-op (such as /proc/self/sched). This would have the same effect but would clear the "is a procfs file" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as "future work" at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.
In all known versions of runc, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts.
Note that while /proc/self/attr/<label> was the example used above (which is LSM-specific), this issue affect all writes to /proc in runc and thus also affects sysctls (written to /proc/sys/...) and some other APIs.
Additional Impacts
While investigating this issue, runc discovered that another risk with these redirected writes is that they could be redirected to dangerous files such as /proc/sysrq-trigger rather than just no-op files like /proc/self/sched. For instance, the default AppArmor profile name in Docker is docker-default, which when written to /proc/sysrq-trigger would cause the host system to crash.
When this was discovered, runc conducted an audit of other write operations within runc and found several possible areas where runc could be used as a semi-arbitrary write gadget when combined with the above race attacks. The most concerning attack scenario was the configuration of sysctls. Because the contents of the sysctl are free-form text, an attacker could use a misdirected write to write to /proc/sys/kernel/core_pattern and break out of the container (as described in CVE-2025-31133, kernel upcalls are not namespaced and so coredump helpers will run with complete root privileges on the host). Even if the attacker cannot configure custom sysctls, a valid sysctl string (when redirected to /proc/sysrq-trigger) can easily cause the machine to hang.
Note that the fact that this attack allows you to disable LSM labels makes it a very useful attack to combine with CVE-2025-31133 (as one of the only mitigations available to most users for that issue is AppArmor, and this attack would let you bypass that). However, the misdirected write issue above means that you could also achieve most of the same goals without needing to chain together attacks.
Patches
This advisory is being published as part of a set of three advisories:
- CVE-2025-31133
- CVE-2025-52881
- CVE-2025-52565
The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:
- db19bbed5348 ("internal/sys: add VerifyInode helper")
- 6fc191449109 ("internal: move utils.MkdirAllInRoot to internal/pathrs")
- ff94f9991bd3 ("*: switch to safer securejoin.Reopen")
- 44a0fcf685db ("go.mod: update to github.com/cyphar/filepath-securejoin@v0.5.0")
- 77889b56db93 ("internal: add wrappers for securejoin.Proc*")
- fdcc9d3cad2f ("apparmor: use safe procfs API for labels")
- ff6fe1324663 ("utils: use safe procfs for /proc/self/fd loop code")
- b3dd1bc562ed ("utils: remove unneeded EnsureProcHandle")
- 77d217c7c377 ("init: write sysctls using safe procfs API")
- 435cc81be6b7 ("init: use securejoin for /proc/self/setgroups")
- d61fd29d854b ("libct/system: use securejoin for /proc/$pid/stat")
- 4b37cd93f86e ("libct: align param type for mountCgroupV1/V2 functions")
- d40b3439a961 ("rootfs: switch to fd-based handling of mountpoint targets")
- ed6b1693b8b3 ("selinux: use safe procfs API for labels")
-
Please note that this patch includes a private patch for
github.com/opencontainers/selinuxthat could not be made public through a public pull request (as it would necessarily disclose this embargoed security issue).The patch includes a complete copy of the forked code and a
replacedirective (as well asgo mod vendorapplied), which should still work with downstream build systems. If you cannot apply this patch, you can safely drop it -- some of the other patches in this series should block these kinds of racing mount attacks entirely.See https://github.com/opencontainers/selinux/pull/237 for the upstream patch. * 3f925525b44d ("rootfs: re-allow dangling symlinks in mount targets") * a41366e74080 ("openat2: improve resilience on busy systems")
runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per runc's new release model, runc 1.1.x and earlier are no longer supported and thus have not been patched.
Mitigations
-
Do not run untrusted container images from unknown or unverified sources.
-
For the basic no-op attack, this attack allows a container process to run with the same LSM labels as
runc. For most AppArmor deployments this means it will beunconfined, and for SELinux it will likely becontainer_runtime_t. Runc has not conducted in-depth testing of the impact on SELinux -- it is possible that it provides some reasonable protection but it seems likely that an attacker could cause harm to systems even with such an SELinux setup. -
For the more involved redirect and write gadget attacks, unfortunately most LSM profiles (including the standard container-selinux profiles) provide the container runtime access to sysctl files (including
/proc/sysrq-trigger) and so LSMs likely do not provide much protection against these attacks. -
Using rootless containers provides some protection against these kinds of bugs (privileged writes in runc being redirected) -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. For this particular bug, the privilege escalation caused by the inadvertent write issue is entirely mitigated with rootless containers because the unprivileged user that the
runcprocess is executing as cannot write to the aforementioned procfs files (even intentionally).
Other Runtimes
As this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.
Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to use the host's /proc for all procfs operations, and so is likely not vulnerable to this issue (this is a trade-off -- runc uses the container's procfs to avoid CVE-2016-9962-style attacks).
Credits
Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@tonistiigi from Docker) for both independently discovering this vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.
Additional thanks go to Tõnis Tiigi for finding some very useful exploit templates for these kinds of race attacks using docker buildx build.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.2.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.12.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/selinux"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.0-rc.1"
},
{
"fixed": "1.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.0-rc.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0-rc.1"
},
{
"fixed": "1.4.0-rc.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-52881"
],
"database_specific": {
"cwe_ids": [
"CWE-363",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-05T18:40:40Z",
"nvd_published_at": "2025-11-06T21:15:42Z",
"severity": "HIGH"
},
"details": "### Impact ###\n\nThis attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy `tmpfs` file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.\n\nRather than using a fake `tmpfs` file for `/proc/self/attr/\u003clabel\u003e`, an attacker could instead (through various means) make `/proc/self/attr/\u003clabel\u003e` reference a real `procfs` file, but one that would still be a no-op (such as `/proc/self/sched`). This would have the same effect but would clear the \"is a procfs file\" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as \"future work\" at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.\n\nIn all known versions of runc, an attacker can trick runc into misdirecting writes to `/proc` to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with `docker buildx build` as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a `tmpfs` or theoretically other methods such as regular bind-mounts.\n\nNote that while `/proc/self/attr/\u003clabel\u003e` was the example used above (which is LSM-specific), this issue affect all writes to `/proc` in runc and thus also affects sysctls (written to `/proc/sys/...`) and some other APIs.\n\n#### Additional Impacts ####\n\nWhile investigating this issue, runc discovered that another risk with these redirected writes is that they could be redirected to dangerous files such as `/proc/sysrq-trigger` rather than just no-op files like `/proc/self/sched`. For instance, the default AppArmor profile name in Docker is `docker-default`, which when written to `/proc/sysrq-trigger` would cause the host system to crash.\n\nWhen this was discovered, runc conducted an audit of other write operations within runc and found several possible areas where runc could be used as a semi-arbitrary write gadget when combined with the above race attacks. The most concerning attack scenario was the configuration of sysctls. Because the contents of the sysctl are free-form text, an attacker could use a misdirected write to write to `/proc/sys/kernel/core_pattern` and break out of the container (as described in CVE-2025-31133, kernel upcalls are not namespaced and so coredump helpers will run with complete root privileges on the host). Even if the attacker cannot configure custom sysctls, a valid sysctl string (when redirected to `/proc/sysrq-trigger`) can easily cause the machine to hang.\n\nNote that the fact that this attack allows you to disable LSM labels makes it a very useful attack to combine with CVE-2025-31133 (as one of the only mitigations available to most users for that issue is AppArmor, and this attack would let you bypass that). However, the misdirected write issue above means that you could also achieve most of the same goals without needing to chain together attacks.\n\n### Patches ###\n\nThis advisory is being published as part of a set of three advisories:\n\n * CVE-2025-31133\n * CVE-2025-52881\n * CVE-2025-52565\n\nThe patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:\n\n * db19bbed5348 (\"internal/sys: add VerifyInode helper\")\n * 6fc191449109 (\"internal: move utils.MkdirAllInRoot to internal/pathrs\")\n * ff94f9991bd3 (\"*: switch to safer securejoin.Reopen\")\n * 44a0fcf685db (\"go.mod: update to github.com/cyphar/filepath-securejoin@v0.5.0\")\n * 77889b56db93 (\"internal: add wrappers for securejoin.Proc*\")\n * fdcc9d3cad2f (\"apparmor: use safe procfs API for labels\")\n * ff6fe1324663 (\"utils: use safe procfs for /proc/self/fd loop code\")\n * b3dd1bc562ed (\"utils: remove unneeded EnsureProcHandle\")\n * 77d217c7c377 (\"init: write sysctls using safe procfs API\")\n * 435cc81be6b7 (\"init: use securejoin for /proc/self/setgroups\")\n * d61fd29d854b (\"libct/system: use securejoin for /proc/$pid/stat\")\n * 4b37cd93f86e (\"libct: align param type for mountCgroupV1/V2 functions\")\n * d40b3439a961 (\"rootfs: switch to fd-based handling of mountpoint targets\")\n * ed6b1693b8b3 (\"selinux: use safe procfs API for labels\")\n - Please note that this patch includes a private patch for `github.com/opencontainers/selinux` that could not be made public through a public pull request (as it would necessarily disclose this embargoed security issue).\n\n The patch includes a complete copy of the forked code and a `replace` directive (as well as `go mod vendor` applied), which should still work with downstream build systems. If you cannot apply this patch, you can safely drop it -- some of the other patches in this series should block these kinds of racing mount attacks entirely.\n\n See https://github.com/opencontainers/selinux/pull/237 for the upstream patch.\n * 3f925525b44d (\"rootfs: re-allow dangling symlinks in mount targets\")\n * a41366e74080 (\"openat2: improve resilience on busy systems\")\n\nrunc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per [runc\u0027s new release model][RELEASES.md], runc 1.1.x and earlier are no longer supported and thus have not been patched.\n\n[CVE-2025-31133]: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2\n[CVE-2025-52565]: https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r\n[CVE-2025-52881]: https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm\n[RELEASES.md]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md\n\n### Mitigations ###\n\n * Do not run untrusted container images from unknown or unverified sources.\n\n * For the basic no-op attack, this attack allows a container process to run with the same LSM labels as `runc`. For most AppArmor deployments this means it will be `unconfined`, and for SELinux it will likely be `container_runtime_t`. Runc has not conducted in-depth testing of the impact on SELinux -- it is possible that it provides some reasonable protection but it seems likely that an attacker could cause harm to systems even with such an SELinux setup.\n\n * For the more involved redirect and write gadget attacks, unfortunately most LSM profiles (including the standard container-selinux profiles) provide the container runtime access to sysctl files (including `/proc/sysrq-trigger`) and so LSMs likely do not provide much protection against these attacks.\n\n * Using rootless containers provides some protection against these kinds of bugs (privileged writes in runc being redirected) -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. For this particular bug, the privilege escalation caused by the inadvertent write issue is entirely mitigated with rootless containers because the unprivileged user that the `runc` process is executing as cannot write to the aforementioned procfs files (even intentionally).\n\n### Other Runtimes ###\n\nAs this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.\n\nBased on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to use the host\u0027s `/proc` for all procfs operations, and so is likely not vulnerable to this issue (this is a trade-off -- runc uses the container\u0027s procfs to avoid CVE-2016-9962-style attacks).\n\n[CVE-2016-9962]: https://seclists.org/fulldisclosure/2017/Jan/21\n\n### Credits ###\n\nThanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and T\u00f5nis Tiigi (@tonistiigi from Docker) for both independently discovering this vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.\n\nAdditional thanks go to T\u00f5nis Tiigi for finding some very useful exploit templates for these kinds of race attacks using `docker buildx build`.",
"id": "GHSA-cgrx-mc8f-2prm",
"modified": "2025-11-18T18:38:01Z",
"published": "2025-11-05T18:40:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-fh74-hm69-rqjw"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52881"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/selinux/pull/237"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/ff94f9991bd32076c871ef0ad8bc1b763458e480"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/ff6fe1324663538167eca8b3d3eec61e1bd4fa51"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/fdcc9d3cad2f85954a241ccb910a61aaa1ef47f3"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/ed6b1693b8b3ae7eb0250a7e76fc888cdacf98c1"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/db19bbed5348847da433faa9d69e9f90192bfa64"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/d61fd29d854b416feaaf128bf650325cd2182165"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/d40b3439a9614a86e87b81a94c6811ec6fa2d7d2"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/b3dd1bc562ed9996d1a0f249e056c16624046d28"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/a41366e74080fa9f26a2cd3544e2801449697322"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/77d217c7c3775d8ca5af89e477e81568ef4572db"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/77889b56db939c323d29d1130f28f9aea2edb544"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/6fc191449109ea14bb7d61238f24a33fe08c651f"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/4b37cd93f86e72feac866442988b549b5b7bf3e6"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/44a0fcf685db051c80b8c269812bb177f5802c58"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/435cc81be6b79cdec73b4002c0dae549b2f6ae6d"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/3f925525b44d247e390e529e772a0dc0c0bc3557"
},
{
"type": "WEB",
"url": "https://youtu.be/tGseJW_uBB8"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/github.com/cyphar/filepath-securejoin/pathrs-lite/procfs"
},
{
"type": "WEB",
"url": "https://youtu.be/y1PaBzxwRWQ"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/selinux/releases/tag/v1.13.0"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md"
},
{
"type": "PACKAGE",
"url": "https://github.com/opencontainers/runc"
},
{
"type": "WEB",
"url": "http://github.com/opencontainers/runc/commit/a41366e74080fa9f26a2cd3544e2801449697322"
},
{
"type": "WEB",
"url": "http://github.com/opencontainers/runc/commit/fdcc9d3cad2f85954a241ccb910a61aaa1ef47f3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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": "runc container escape and denial of service due to arbitrary write gadgets and procfs write redirects"
}
GHSA-HQ6Q-C2X6-HMCH
Vulnerability from github – Published: 2023-11-14 21:31 – Updated: 2024-09-06 16:58A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.28.0"
},
{
"fixed": "1.28.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.27.0"
},
{
"fixed": "1.27.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.26.0"
},
{
"fixed": "1.26.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.25.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-5528"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-14T22:25:07Z",
"nvd_published_at": "2023-11-14T21:15:14Z",
"severity": "HIGH"
},
"details": "A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.",
"id": "GHSA-hq6q-c2x6-hmch",
"modified": "2024-09-06T16:58:25Z",
"published": "2023-11-14T21:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5528"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/121879"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/121881"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/121882"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/121883"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/121884"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/121885"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubernetes/kubernetes"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/kubernetes-security-announce/c/SL_d4NR8pzA"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3JH444PWZBINXLLFV7XLIJIZJHSK6UEZ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4XZIX727JIKF5RQW7RVVBLWXBCDIBJA7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7MPGMITSZXUCAVO7Q75675SOLXC2XXU4"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240119-0009"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Kubernetes Improper Input Validation vulnerability"
}
GHSA-M425-MQ94-257G
Vulnerability from github – Published: 2023-10-25 21:17 – Updated: 2024-07-19 16:32Impact
In affected releases of gRPC-Go, it is possible for an attacker to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit.
Patches
This vulnerability was addressed by #6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0.
Along with applying the patch, users should also ensure they are using the grpc.MaxConcurrentStreams server option to apply a limit to the server's resources used for any single connection.
Workarounds
None.
References
6703
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/grpc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.56.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/grpc"
},
"ranges": [
{
"events": [
{
"introduced": "1.57.0"
},
{
"fixed": "1.57.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/grpc"
},
"ranges": [
{
"events": [
{
"introduced": "1.58.0"
},
{
"fixed": "1.58.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [],
"github_reviewed": true,
"github_reviewed_at": "2023-10-25T21:17:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nIn affected releases of gRPC-Go, it is possible for an attacker to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit.\n\n### Patches\nThis vulnerability was addressed by #6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0.\n\nAlong with applying the patch, users should also ensure they are using the `grpc.MaxConcurrentStreams` server option to apply a limit to the server\u0027s resources used for any single connection.\n\n### Workarounds\nNone.\n\n### References\n#6703\n",
"id": "GHSA-m425-mq94-257g",
"modified": "2024-07-19T16:32:30Z",
"published": "2023-10-25T21:17:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-m425-mq94-257g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44487"
},
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/pull/6703"
},
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/commit/f2180b4d5403d2210b30b93098eb7da31c05c721"
},
{
"type": "PACKAGE",
"url": "https://github.com/grpc/grpc-go"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "gRPC-Go HTTP/2 Rapid Reset vulnerability"
}
GHSA-P77J-4MVH-X3M3
Vulnerability from github – Published: 2026-03-18 20:10 – Updated: 2026-03-25 18:12Impact
What kind of vulnerability is it? Who is impacted?
It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.
The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.
Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:
1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).
The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.
Patches
Has the problem been patched? What versions should users upgrade to?
Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.
Users should upgrade to the following versions (or newer): * v1.79.3 * The latest master branch.
It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:
1. Use a Validating Interceptor (Recommended Mitigation)
Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:
func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
if info.FullMethod == "" || info.FullMethod[0] != '/' {
return nil, status.Errorf(codes.Unimplemented, "malformed method name")
}
return handler(ctx, req)
}
// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)
2. Infrastructure-Level Normalization
If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.
3. Policy Hardening
Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/grpc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.79.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33186"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T20:10:29Z",
"nvd_published_at": "2026-03-20T23:16:45Z",
"severity": "CRITICAL"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIt is an **Authorization Bypass** resulting from **Improper Input Validation** of the HTTP/2 `:path` pseudo-header.\n\nThe gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, \"deny\" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback \"allow\" rule was present.\n\n**Who is impacted?**\nThis affects gRPC-Go servers that meet both of the following criteria:\n1. They use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`.\n2. Their security policy contains specific \"deny\" rules for canonical paths but allows other requests by default (a fallback \"allow\" rule).\n\nThe vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nYes, the issue has been patched. The fix ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.\n\nUsers should upgrade to the following versions (or newer):\n* **v1.79.3**\n* The latest **master** branch.\n\nIt is recommended that all users employing path-based authorization (especially `grpc/authz`) upgrade as soon as the patch is available in a tagged release.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nWhile upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:\n\n#### 1. Use a Validating Interceptor (Recommended Mitigation)\nAdd an \"outermost\" interceptor to your server that validates the path before any other authorization logic runs:\n\n```go\nfunc pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {\n if info.FullMethod == \"\" || info.FullMethod[0] != \u0027/\u0027 {\n return nil, status.Errorf(codes.Unimplemented, \"malformed method name\")\n } \n return handler(ctx, req)\n}\n\n// Ensure this is the FIRST interceptor in your chain\ns := grpc.NewServer(\n grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),\n)\n```\n\n#### 2. Infrastructure-Level Normalization\nIf your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the `:path` header does not start with a leading slash.\n\n#### 3. Policy Hardening\nSwitch to a \"default deny\" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.",
"id": "GHSA-p77j-4mvh-x3m3",
"modified": "2026-03-25T18:12:09Z",
"published": "2026-03-18T20:10:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33186"
},
{
"type": "PACKAGE",
"url": "https://github.com/grpc/grpc-go"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "gRPC-Go has an authorization bypass via missing leading slash in :path"
}
GHSA-PXHW-596R-RWQ5
Vulnerability from github – Published: 2024-04-23 00:30 – Updated: 2024-07-03 20:24A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.29.3"
},
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.29.0"
},
{
"fixed": "1.29.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.28.8"
},
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.28.0"
},
{
"fixed": "1.28.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-3177"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-23T16:19:54Z",
"nvd_published_at": "2024-04-22T23:15:51Z",
"severity": "LOW"
},
"details": "A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account\u2019s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.\n\n",
"id": "GHSA-pxhw-596r-rwq5",
"modified": "2024-07-03T20:24:58Z",
"published": "2024-04-23T00:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3177"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/124336"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/7c861b1ecad97e1ab9332c970c9294a72065111a"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/a619ca3fd3ee3c222d9df784622020de398076d2"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/f9fb6cf52a769a599a45e700375115c2ecc86e9b"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-pxhw-596r-rwq5"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubernetes/kubernetes"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/kubernetes-security-announce/c/JxjHf7fkVd8/m/oVCzypyOAQAJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QRYFHIQ6XRKRYBI2F5UESH67BJBQXUPT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WL54MTLGMTBZZO5PYGEGEBERTMADC4WC"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-2746"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/04/16/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Kubernetes allows bypassing mountable secrets policy imposed by the ServiceAccount admission plugin"
}
GHSA-Q78C-GWQW-JCMC
Vulnerability from github – Published: 2023-10-31 21:32 – Updated: 2025-02-13 19:20A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.28.0"
},
{
"fixed": "1.28.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.28.0"
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.27.0"
},
{
"fixed": "1.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.26.0"
},
{
"fixed": "1.26.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.25.0"
},
{
"fixed": "1.25.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.24.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-3955"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-01T17:16:38Z",
"nvd_published_at": "2023-10-31T21:15:08Z",
"severity": "HIGH"
},
"details": "A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.",
"id": "GHSA-q78c-gwqw-jcmc",
"modified": "2025-02-13T19:20:56Z",
"published": "2023-10-31T21:32:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3955"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/119595"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/120128"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/120134"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/120135"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/120136"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/120137"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/120138"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/38c97fa67ed35f36e730856728c9e3807f63546a"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/50334505cd27cbe7cf71865388f25a00e29b2596"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/7da6d72c05dffb3b87e62e2bc8c3228ea12ba1b9"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/b7547e28f898af37aa2f1107a49111f963250fe6"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/commit/c4e17abb04728e3a3f9bb26e727b0f978df20ec9"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubernetes/kubernetes"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/kubernetes-security-announce/c/JrX4bb7d83E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20231221-0002"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Kubernetes privilege escalation vulnerability"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.