deps(deps): update actions/checkout action to v6 #117

docs: update README.md by @motss in #1971
Add internal repos for checking out multiple repositories by @mouismail in #1977
Documentation update - add recommended permissions to Readme by @benwells in #2043
Adjust positioning of user email note and permissions heading by @joshmgross in #2044
Update README.md by @nebuk89 in #2194
Update CODEOWNERS for actions by @TingluoHuang in #2224
Update package dependencies by @salmanmkc in #2236
Prepare release v4.3.0 by @salmanmkc in #2237

New Contributors

@motss made their first contribution in #1971
@mouismail made their first contribution in #1977
@benwells made their first contribution in #2043
@nebuk89 made their first contribution in #2194
@salmanmkc made their first contribution in #2236

Full Changelog: actions/checkout@v4...v4.3.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

github-actions · 2025-11-20T16:37:38Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-11-20T16:37:40Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:37:41Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:37:44Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:37:44Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:37:45Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:37:47Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:37:47Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:37:54Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:37:54Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:37:55Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:37:57Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:37:57Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:37:58Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:37:59Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:37:59Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:38:00Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-11-20T16:38:04Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:38:04Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:38:04Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:38:05Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:38:11Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-11-20T16:38:30Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.075%`
EPSS Percentile	`19th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.033%`
EPSS Percentile	`5th percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scals non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.055%`
EPSS Percentile	`13th percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.018%`
EPSS Percentile	`2nd percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

github-actions · 2025-11-20T16:38:33Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-12-02T20:52:10Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.022%`
EPSS Percentile	`5th percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-12-02T20:52:12Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-12-02T20:52:13Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.022%`
EPSS Percentile	`5th percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-12-02T20:52:14Z

Outdated

🔍 Vulnerabilities of `wayofdev/php-dev:latest`

📦 Image Reference wayofdev/php-dev:latest

digest	`sha256:39ce5ec112f8197fee6165925a8f3d7e5d10967b4188e40f55b62a6a1284baf9`
vulnerabilities
platform	linux/amd64
size	109 MB
packages	250

📦 Base Image php:8.3-fpm-alpine

also known as	`8.3-fpm-alpine3.22` `8.3.28-fpm-alpine` `8.3.28-fpm-alpine3.22`
digest	`sha256:079d120f7788bf6670213591c3a55507fd6b67f75afe6ef903dc5c63380f7217`
vulnerabilities

golang.org/x/crypto 0.17.0 (golang)

pkg:golang/golang.org/x/[email protected]

Improper Authorization

Affected range	`<0.31.0`
Fixed version	`0.31.0`
CVSS Score	`9.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
EPSS Score	`42.906%`
EPSS Percentile	`97th percentile`

Description

Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass.

The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions.

For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key.

Since this API is widely misused, as a partial mitigation golang.org/x/[email protected] enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth.

Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Affected range	`<0.35.0`
Fixed version	`0.35.0`
EPSS Score	`0.217%`
EPSS Percentile	`44th percentile`

Description

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

libpng 1.6.47-r0 (apk)

pkg:apk/alpine/[email protected]?os_name=alpine&os_version=3.22

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.018%`
EPSS Percentile	`4th percentile`

Description

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.033%`
EPSS Percentile	`9th percentile`

Description

stdlib 1.24.8 (golang)

pkg:golang/[email protected]

Affected range	`<1.24.9`
Fixed version	`1.24.9`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github-actions · 2025-12-02T20:52:14Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.022%`
EPSS Percentile	`5th percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-12-02T20:52:16Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-12-02T20:52:17Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-12-02T20:52:17Z

Outdated

Recommended fixes for image `wayofdev/php-dev:latest`

Base image is php:8.3-fpm-alpine

Name	8.3.28-fpm-alpine3.22
Digest	sha256:079d120f7788bf6670213591c3a55507fd6b67f75afe6ef903dc5c63380f7217
Vulnerabilities
Pushed	1 week ago
Size	33 MB
Packages	61
Flavor	alpine
OS	3.22
Runtime	8.3.28

The base image is also available under the supported tag(s): 8.3-fpm-alpine3.22, 8.3.28-fpm-alpine, 8.3.28-fpm-alpine3.22

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`8.4-fpm-alpine` Minor runtime version update Also known as: 8.4.15-fpm-alpine 8.4.15-fpm-alpine3.22 8.4-fpm-alpine3.22	Benefits: Same OS detected Minor runtime version update Image has similar size Image has same number of vulnerabilities Image contains equal number of packages Image details: Size: 36 MB Flavor: alpine OS: 3.22 Runtime: 8.4.15	1 week ago
`8.5-fpm-alpine` Image has same number of vulnerabilities Also known as: 8.5.0-fpm-alpine 8.5.0-fpm-alpine3.22 8.5-fpm-alpine3.22 8-fpm-alpine 8-fpm-alpine3.22 fpm-alpine fpm-alpine3.22	Benefits: Same OS detected Image contains 1 fewer package Image has similar size Image has same number of vulnerabilities Image details: Size: 38 MB Flavor: alpine OS: 3.22	1 week ago

github-actions · 2025-12-02T20:52:26Z

Outdated

🔍 Vulnerabilities of `wayofdev/php-dev:latest`

📦 Image Reference wayofdev/php-dev:latest

digest	`sha256:ce1a0ec59c7c71e8cab0103406b742200813fe3a9247b8afaf2e1828d41f6b83`
vulnerabilities
platform	linux/amd64
size	114 MB
packages	249

📦 Base Image php:8.3-alpine

also known as	`8.3-alpine3.22` `8.3-cli-alpine` `8.3-cli-alpine3.22` `8.3.28-alpine` `8.3.28-alpine3.22` `8.3.28-cli-alpine` `8.3.28-cli-alpine3.22`
digest	`sha256:d472137436dccea12eb4ebea28f394c1bf206260229ea6d7f4418d8f14c03174`
vulnerabilities

golang.org/x/crypto 0.17.0 (golang)

pkg:golang/golang.org/x/[email protected]

Improper Authorization

Affected range	`<0.31.0`
Fixed version	`0.31.0`
CVSS Score	`9.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
EPSS Score	`42.906%`
EPSS Percentile	`97th percentile`

Description

Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass.

The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions.

For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key.

Since this API is widely misused, as a partial mitigation golang.org/x/[email protected] enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth.

Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Affected range	`<0.35.0`
Fixed version	`0.35.0`
EPSS Score	`0.217%`
EPSS Percentile	`44th percentile`

Description

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

libpng 1.6.47-r0 (apk)

pkg:apk/alpine/[email protected]?os_name=alpine&os_version=3.22

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.018%`
EPSS Percentile	`4th percentile`

Description

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.033%`
EPSS Percentile	`9th percentile`

Description

stdlib 1.24.8 (golang)

pkg:golang/[email protected]

Affected range	`<1.24.9`
Fixed version	`1.24.9`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github-actions · 2025-12-02T20:52:26Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.022%`
EPSS Percentile	`5th percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-12-02T20:52:26Z

Outdated

🔍 Vulnerabilities of `wayofdev/php-dev:latest`

📦 Image Reference wayofdev/php-dev:latest

digest	`sha256:f57c54c8f7d97baa0cf8720fceeb39b3be6dbb706b1625594c1426cecb5bfbf9`
vulnerabilities
platform	linux/amd64
size	118 MB
packages	249

📦 Base Image php:8.4-alpine

also known as	`8.4-alpine3.22` `8.4-cli-alpine` `8.4-cli-alpine3.22` `8.4.15-alpine` `8.4.15-alpine3.22` `8.4.15-cli-alpine` `8.4.15-cli-alpine3.22`
digest	`sha256:13069fa0e1d5051c408265677497514a9ef952bff6caea7ed2fae4b79bac5b64`
vulnerabilities

golang.org/x/crypto 0.17.0 (golang)

pkg:golang/golang.org/x/[email protected]

Improper Authorization

Affected range	`<0.31.0`
Fixed version	`0.31.0`
CVSS Score	`9.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
EPSS Score	`42.906%`
EPSS Percentile	`97th percentile`

Description

Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass.

The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions.

For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key.

Since this API is widely misused, as a partial mitigation golang.org/x/[email protected] enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth.

Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Affected range	`<0.35.0`
Fixed version	`0.35.0`
EPSS Score	`0.217%`
EPSS Percentile	`44th percentile`

Description

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

libpng 1.6.47-r0 (apk)

pkg:apk/alpine/[email protected]?os_name=alpine&os_version=3.22

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.018%`
EPSS Percentile	`4th percentile`

Description

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.033%`
EPSS Percentile	`9th percentile`

Description

stdlib 1.24.8 (golang)

pkg:golang/[email protected]

Affected range	`<1.24.9`
Fixed version	`1.24.9`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github-actions · 2025-12-02T20:52:29Z

Outdated

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.022%`
EPSS Percentile	`5th percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-12-02T20:52:30Z

Outdated

🔍 Vulnerabilities of `wayofdev/php-dev:latest`

📦 Image Reference wayofdev/php-dev:latest

digest	`sha256:9dea12f91104f5c0b410cbcf516961b02bc535d4f9f864908cba6c1e68eae0df`
vulnerabilities
platform	linux/amd64
size	133 MB
packages	284

📦 Base Image php:8.3-alpine

also known as	`8.3-alpine3.22` `8.3-cli-alpine` `8.3-cli-alpine3.22` `8.3.28-alpine` `8.3.28-alpine3.22` `8.3.28-cli-alpine` `8.3.28-cli-alpine3.22`
digest	`sha256:d472137436dccea12eb4ebea28f394c1bf206260229ea6d7f4418d8f14c03174`
vulnerabilities

golang.org/x/crypto 0.17.0 (golang)

pkg:golang/golang.org/x/[email protected]

Improper Authorization

Affected range	`<0.31.0`
Fixed version	`0.31.0`
CVSS Score	`9.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
EPSS Score	`42.906%`
EPSS Percentile	`97th percentile`

Description

Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass.

The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions.

For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key.

Since this API is widely misused, as a partial mitigation golang.org/x/[email protected] enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth.

Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Affected range	`<0.35.0`
Fixed version	`0.35.0`
EPSS Score	`0.217%`
EPSS Percentile	`44th percentile`

Description

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

libpng 1.6.47-r0 (apk)

pkg:apk/alpine/[email protected]?os_name=alpine&os_version=3.22

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.018%`
EPSS Percentile	`4th percentile`

Description

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.033%`
EPSS Percentile	`9th percentile`

Description

stdlib 1.24.8 (golang)

pkg:golang/[email protected]

Affected range	`<1.24.9`
Fixed version	`1.24.9`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github-actions · 2025-12-02T20:52:30Z

Outdated

🔍 Vulnerabilities of `wayofdev/php-dev:latest`

📦 Image Reference wayofdev/php-dev:latest

digest	`sha256:43b1e45d76440a4f38492497a717ffe6d42c5efd1a7133c7603a2c45e6b132dd`
vulnerabilities
platform	linux/amd64
size	136 MB
packages	284

📦 Base Image php:8.4-alpine

also known as	`8.4-alpine3.22` `8.4-cli-alpine` `8.4-cli-alpine3.22` `8.4.15-alpine` `8.4.15-alpine3.22` `8.4.15-cli-alpine` `8.4.15-cli-alpine3.22`
digest	`sha256:13069fa0e1d5051c408265677497514a9ef952bff6caea7ed2fae4b79bac5b64`
vulnerabilities

golang.org/x/crypto 0.17.0 (golang)

pkg:golang/golang.org/x/[email protected]

Improper Authorization

Affected range	`<0.31.0`
Fixed version	`0.31.0`
CVSS Score	`9.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
EPSS Score	`42.906%`
EPSS Percentile	`97th percentile`

Description

Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass.

The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions.

For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key.

Since this API is widely misused, as a partial mitigation golang.org/x/[email protected] enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth.

Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Affected range	`<0.35.0`
Fixed version	`0.35.0`
EPSS Score	`0.217%`
EPSS Percentile	`44th percentile`

Description

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

libpng 1.6.47-r0 (apk)

pkg:apk/alpine/[email protected]?os_name=alpine&os_version=3.22

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.018%`
EPSS Percentile	`4th percentile`

Description

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.033%`
EPSS Percentile	`9th percentile`

Description

stdlib 1.24.8 (golang)

pkg:golang/[email protected]

Affected range	`<1.24.9`
Fixed version	`1.24.9`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github-actions · 2025-12-02T20:52:30Z

Outdated

🔍 Vulnerabilities of `wayofdev/php-dev:latest`

📦 Image Reference wayofdev/php-dev:latest

digest	`sha256:61d1178fc39ffe106abf9ffbd0334a44559dd0cbc27f0dd8eaa328c82f82d262`
vulnerabilities
platform	linux/amd64
size	112 MB
packages	250

📦 Base Image php:8.4-fpm-alpine

also known as	`8.4-fpm-alpine3.22` `8.4.15-fpm-alpine` `8.4.15-fpm-alpine3.22`
digest	`sha256:9af4cb7d0b7e71f238f9f6a8e540f58237050c7478cd6e135de986064f618142`
vulnerabilities

golang.org/x/crypto 0.17.0 (golang)

pkg:golang/golang.org/x/[email protected]

Improper Authorization

Affected range	`<0.31.0`
Fixed version	`0.31.0`
CVSS Score	`9.1`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`
EPSS Score	`42.906%`
EPSS Percentile	`97th percentile`

Description

Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass.

The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions.

For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key.

Since this API is widely misused, as a partial mitigation golang.org/x/[email protected] enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth.

Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Affected range	`<0.35.0`
Fixed version	`0.35.0`
EPSS Score	`0.217%`
EPSS Percentile	`44th percentile`

Description

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

libpng 1.6.47-r0 (apk)

pkg:apk/alpine/[email protected]?os_name=alpine&os_version=3.22

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.018%`
EPSS Percentile	`4th percentile`

Description

Affected range	`<1.6.51-r0`
Fixed version	`1.6.51-r0`
EPSS Score	`0.033%`
EPSS Percentile	`9th percentile`

Description

stdlib 1.24.8 (golang)

pkg:golang/[email protected]

Affected range	`<1.24.9`
Fixed version	`1.24.9`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github-actions · 2025-12-02T20:52:30Z

Outdated

Recommended fixes for image `wayofdev/php-dev:latest`

Base image is php:8.3-alpine

Name	8.3.28-alpine3.22
Digest	sha256:d472137436dccea12eb4ebea28f394c1bf206260229ea6d7f4418d8f14c03174
Vulnerabilities
Pushed	1 week ago
Size	37 MB
Packages	60
Flavor	alpine
OS	3.22
Runtime	8.3.28

The base image is also available under the supported tag(s): 8.3-alpine3.22, 8.3-cli-alpine, 8.3-cli-alpine3.22, 8.3.28-alpine, 8.3.28-alpine3.22, 8.3.28-cli-alpine, 8.3.28-cli-alpine3.22

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`8.5-alpine` Minor runtime version update Also known as: 8.5.0-cli-alpine 8.5.0-cli-alpine3.22 8.5-cli-alpine 8.5-cli-alpine3.22 8-cli-alpine 8-cli-alpine3.22 cli-alpine cli-alpine3.22 alpine alpine3.22 8.5.0-alpine3.22 8.5-alpine3.22 8-alpine 8-alpine3.22	Benefits: Same OS detected Minor runtime version update Image contains 1 fewer package Image has similar size Image has same number of vulnerabilities Image details: Size: 44 MB Flavor: alpine OS: 3.22 Runtime: 8.5.0	1 week ago
`8.4-alpine` Minor runtime version update Also known as: 8.4.15-cli-alpine 8.4.15-cli-alpine3.22 8.4-cli-alpine 8.4-cli-alpine3.22 8.4.15-alpine 8.4.15-alpine3.22 8.4-alpine3.22	Benefits: Same OS detected Minor runtime version update Image has similar size Image has same number of vulnerabilities Image contains equal number of packages Image details: Size: 41 MB Flavor: alpine OS: 3.22 Runtime: 8.4.15	1 week ago

github-actions · 2025-12-02T20:52:30Z

Outdated

Recommended fixes for image `wayofdev/php-dev:latest`

Base image is php:8.4-alpine

Name	8.4.15-alpine3.22
Digest	sha256:13069fa0e1d5051c408265677497514a9ef952bff6caea7ed2fae4b79bac5b64
Vulnerabilities
Pushed	1 week ago
Size	41 MB
Packages	60
Flavor	alpine
OS	3.22
Runtime	8.4.15

The base image is also available under the supported tag(s): 8.4-alpine3.22, 8.4-cli-alpine, 8.4-cli-alpine3.22, 8.4.15-alpine, 8.4.15-alpine3.22, 8.4.15-cli-alpine, 8.4.15-cli-alpine3.22

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`8.5-alpine` Minor runtime version update Also known as: 8.5.0-cli-alpine 8.5.0-cli-alpine3.22 8.5-cli-alpine 8.5-cli-alpine3.22 8-cli-alpine 8-cli-alpine3.22 cli-alpine cli-alpine3.22 alpine alpine3.22 8.5.0-alpine3.22 8.5-alpine3.22 8-alpine 8-alpine3.22	Benefits: Same OS detected Minor runtime version update Image contains 1 fewer package Image has similar size Image has same number of vulnerabilities Image details: Size: 44 MB Flavor: alpine OS: 3.22 Runtime: 8.5.0	1 week ago

github-actions · 2025-12-02T20:52:31Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-12-02T20:52:34Z

Outdated

Recommended fixes for image `wayofdev/php-dev:latest`

Base image is php:8.4-fpm-alpine

Name	8.4.15-fpm-alpine3.22
Digest	sha256:9af4cb7d0b7e71f238f9f6a8e540f58237050c7478cd6e135de986064f618142
Vulnerabilities
Pushed	1 week ago
Size	36 MB
Packages	61
Flavor	alpine
OS	3.22
Runtime	8.4.15

The base image is also available under the supported tag(s): 8.4-fpm-alpine3.22, 8.4.15-fpm-alpine, 8.4.15-fpm-alpine3.22

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`8.5-fpm-alpine` Image has same number of vulnerabilities Also known as: 8.5.0-fpm-alpine 8.5.0-fpm-alpine3.22 8.5-fpm-alpine3.22 8-fpm-alpine 8-fpm-alpine3.22 fpm-alpine fpm-alpine3.22	Benefits: Same OS detected Image contains 1 fewer package Image has similar size Image has same number of vulnerabilities Image details: Size: 38 MB Flavor: alpine OS: 3.22	1 week ago

github-actions · 2025-12-02T20:52:34Z

Outdated

Recommended fixes for image `wayofdev/php-dev:latest`

Base image is php:8.3-alpine

Name	8.3.28-alpine3.22
Digest	sha256:d472137436dccea12eb4ebea28f394c1bf206260229ea6d7f4418d8f14c03174
Vulnerabilities
Pushed	1 week ago
Size	37 MB
Packages	60
Flavor	alpine
OS	3.22
Runtime	8.3.28

The base image is also available under the supported tag(s): 8.3-alpine3.22, 8.3-cli-alpine, 8.3-cli-alpine3.22, 8.3.28-alpine, 8.3.28-alpine3.22, 8.3.28-cli-alpine, 8.3.28-cli-alpine3.22

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`8.5-alpine` Minor runtime version update Also known as: 8.5.0-cli-alpine 8.5.0-cli-alpine3.22 8.5-cli-alpine 8.5-cli-alpine3.22 8-cli-alpine 8-cli-alpine3.22 cli-alpine cli-alpine3.22 alpine alpine3.22 8.5.0-alpine3.22 8.5-alpine3.22 8-alpine 8-alpine3.22	Benefits: Same OS detected Minor runtime version update Image contains 1 fewer package Image has similar size Image has same number of vulnerabilities Image details: Size: 44 MB Flavor: alpine OS: 3.22 Runtime: 8.5.0	1 week ago
`8.4-alpine` Minor runtime version update Also known as: 8.4.15-cli-alpine 8.4.15-cli-alpine3.22 8.4-cli-alpine 8.4-cli-alpine3.22 8.4.15-alpine 8.4.15-alpine3.22 8.4-alpine3.22	Benefits: Same OS detected Minor runtime version update Image has similar size Image has same number of vulnerabilities Image contains equal number of packages Image details: Size: 41 MB Flavor: alpine OS: 3.22 Runtime: 8.4.15	1 week ago

github-actions · 2025-12-02T20:52:34Z

Outdated

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

github-actions · 2025-12-02T20:52:35Z

Outdated

Recommended fixes for image `wayofdev/php-dev:latest`

Base image is php:8.4-alpine

Name	8.4.15-alpine3.22
Digest	sha256:13069fa0e1d5051c408265677497514a9ef952bff6caea7ed2fae4b79bac5b64
Vulnerabilities
Pushed	1 week ago
Size	41 MB
Packages	60
Flavor	alpine
OS	3.22
Runtime	8.4.15

The base image is also available under the supported tag(s): 8.4-alpine3.22, 8.4-cli-alpine, 8.4-cli-alpine3.22, 8.4.15-alpine, 8.4.15-alpine3.22, 8.4.15-cli-alpine, 8.4.15-cli-alpine3.22

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`8.5-alpine` Minor runtime version update Also known as: 8.5.0-cli-alpine 8.5.0-cli-alpine3.22 8.5-cli-alpine 8.5-cli-alpine3.22 8-cli-alpine 8-cli-alpine3.22 cli-alpine cli-alpine3.22 alpine alpine3.22 8.5.0-alpine3.22 8.5-alpine3.22 8-alpine 8-alpine3.22	Benefits: Same OS detected Minor runtime version update Image contains 1 fewer package Image has similar size Image has same number of vulnerabilities Image details: Size: 44 MB Flavor: alpine OS: 3.22 Runtime: 8.5.0	1 week ago

github-actions · 2025-12-02T20:52:48Z

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

📦 Image Reference moby/buildkit:buildx-stable-1

digest	`sha256:fe0990fb85c4586aaa94e599905b75a2676664f065f29bea67ebcd5b2fe88acb`
vulnerabilities
platform	linux/amd64
size	111 MB
packages	251

📦 Base Image alpine:3

also known as	`3.22` `3.22.2` `af829cb99e2e0ed9843029ba4b20af63bf652e3f57b9aaa049744a8b64d7c608` `latest`
digest	`sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f`
vulnerabilities

stdlib 1.25.0 (golang)

pkg:golang/[email protected]

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.026%`
EPSS Percentile	`6th percentile`

Description

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Affected range	`>=1.25.0 <1.25.2`
Fixed version	`1.25.2`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Affected range	`>=1.25.0 <1.25.3`
Fixed version	`1.25.3`
EPSS Score	`0.014%`
EPSS Percentile	`2nd percentile`

Description

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

github.com/opencontainers/selinux 1.12.0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

Race Condition Enabling Link Following

Affected range	`<=1.12.0`
Fixed version	`1.13.0`
CVSS Score	`7.3`
CVSS Vector	`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`
EPSS Score	`0.022%`
EPSS Percentile	`5th percentile`

Description

Impact

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/[email protected]")

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/selinux that 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 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.

See selinux: migrate to pathrs-lite procfs API opencontainers/selinux#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 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.

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 runc process 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.

golang.org/x/crypto 0.42.0 (golang)

pkg:golang/golang.org/x/[email protected]

Affected range	`<0.43.0`
Fixed version	`0.43.0`
EPSS Score	`0.018%`
EPSS Percentile	`3rd percentile`

Description

SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

github-actions · 2025-12-02T20:52:54Z

Recommended fixes for image `moby/buildkit:buildx-stable-1`

Base image is alpine:3

Name	3.22.2
Digest	sha256:85f2b723e106c34644cd5851d7e81ee87da98ac54672b29947c052a45d31dc2f
Vulnerabilities
Pushed	1 month ago
Size	3.8 MB
Packages	20
OS	3.22.2

The base image is also available under the supported tag(s): 3.22, 3.22.2, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
`3.21` Tag is preferred tag Also known as: 3.21.5	Benefits: Image is smaller by 156 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image has same number of vulnerabilities Image details: Size: 3.6 MB OS: 3.21.5	1 month ago

renovate bot requested a review from lotyp as a code owner November 20, 2025 16:36

renovate bot enabled auto-merge (squash) November 20, 2025 16:36

github-actions bot added the type: maintenance For maintenance, refactor and testing (perf, chore, style, revert, refactor, test, build, ci) label Nov 20, 2025

deps(deps): update actions/checkout action to v6

03171fb

renovate bot force-pushed the renovate/actions-checkout-6.x branch from 58f0489 to 03171fb Compare December 2, 2025 20:51

Uh oh!

deps(deps): update actions/checkout action to v6 #117

Are you sure you want to change the base?

deps(deps): update actions/checkout action to v6 #117

Conversation

renovate bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Release Notes

v6.0.1

v6.0.0

v5.0.1

What's Changed

v5.0.0

What's Changed

⚠️ Minimum Compatible Runner Version

v4.3.1

What's Changed

v4.3.0

What's Changed

New Contributors

Configuration

Uh oh!

github-actions bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

Impact

Additional Impacts

Patches

Mitigations

Other Runtimes

Credits

Uh oh!

github-actions bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Recommended fixes for image moby/buildkit:buildx-stable-1

Refresh base image

Change base image

Uh oh!

github-actions bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

Impact

Additional Impacts

Patches

Mitigations

Other Runtimes

Credits

Uh oh!

github-actions bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

Impact

Additional Impacts

Patches

Mitigations

Other Runtimes

Credits

Uh oh!

github-actions bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

Impact

Additional Impacts

Patches

Mitigations

Other Runtimes

Credits

Uh oh!

github-actions bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Recommended fixes for image moby/buildkit:buildx-stable-1

Refresh base image

Change base image

Uh oh!

github-actions bot commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Recommended fixes for image moby/buildkit:buildx-stable-1

Refresh base image

Change base image

Uh oh!

renovate bot commented Nov 20, 2025 •

edited

Loading

`v6.0.1`

`v6.0.0`

`v5.0.1`

`v5.0.0`

`v4.3.1`

`v4.3.0`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

Recommended fixes for image `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

Recommended fixes for image `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

Recommended fixes for image `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

Recommended fixes for image `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

Recommended fixes for image `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

Recommended fixes for image `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

Recommended fixes for image `moby/buildkit:buildx-stable-1`

github-actions bot commented Nov 20, 2025 •

edited

Loading

🔍 Vulnerabilities of `moby/buildkit:buildx-stable-1`