nprasad2077/docker-docs
1
0 Fork 0
mirror of https://github.com/docker/docs.git synced 2026-11-04 10:01:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: freshness pass on security landing and announcements (#26202)

Browse Source 
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Alexa KristensenandCursor authored and GitHub committed 2026-09-29 09:10:32 -05:00
1 parent 0b2b9a410c
commit a7ff455cf8
2 files changed
+322 -127
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

content/manuals/security/_index.md
+26 -21
View File
@@ -1,11 +1,11 @@
---
title: Security
title: Secure Docker accounts and organizations
linkTitle: Security
description: >
description: >-
Secure Docker accounts, manage access, and control membership for
individuals and organizations in Docker Home.
keywords: docker, docker hub, security, 2FA, access tokens, SSO, OIDC,
provisioning, roles, Docker Home
keywords: docker, docker hub, security, account security, 2FA, access tokens,
SSO, OIDC, provisioning, roles, Docker Home
weight: 40
aliases:
- /security/for-developers/
@@ -15,19 +15,24 @@ params:
group: Accounts and admin
grid:
- title: Authentication
description: Two-factor authentication, single sign-on, and OIDC connections.
description: >-
Two-factor authentication, single sign-on, and OIDC connections.
icon: key
link: /security/authentication/
- title: Access tokens
description: Personal and organization access tokens for the Docker CLI and automation.
description: >-
Personal and organization access tokens for the Docker CLI and
automation.
icon: lock-closed
link: /security/access-tokens/
- title: Provisioning
description: Add users with SCIM, JIT, auto-provisioning, and domain management.
description: >-
Add users with SCIM, JIT, auto-provisioning, and domain management.
icon: arrow-path
link: /security/provisioning/
- title: Roles and permissions
description: Assign core or custom roles to control access in your organization.
description: >-
Assign core or custom roles to control access in your organization.
icon: shield-check
link: /security/roles-and-permissions/
---
@@ -41,12 +46,12 @@ settings in [Docker Home](https://app.docker.com/).
You sign in with your individual account.
- [Two-factor authentication](/manuals/security/authentication/2fa/_index.md)
(2FA) adds a time-based one-time password (TOTP) from an authenticator
app to your password.
(2FA) adds a time-based one-time password (TOTP) from an authenticator
app to your password.
- A [personal access token](/manuals/security/access-tokens/personal-access-tokens.md)
(PAT) authenticates the Docker CLI and tools without your password, and
is required for CLI sign-in when 2FA is on or single sign-on (SSO) is
enforced.
(PAT) authenticates the Docker CLI and tools without your password, and
is required for CLI sign-in when 2FA is on or single sign-on (SSO) is
enforced.
## Organization accounts
@@ -54,18 +59,18 @@ Organization and company owners set up how members sign in, add them to
the organization, configure automation, and control what members can do.
- [Single sign-on](/manuals/security/authentication/single-sign-on/_index.md)
(SSO) federates sign-in through your identity provider, which can cover
one organization or every organization in a company.
(SSO) federates sign-in through your identity provider, which can cover
one organization or every organization in a company.
- [Provisioning](/manuals/security/provisioning/_index.md) adds users with
System for Cross-domain Identity Management (SCIM), Just-in-Time (JIT)
provisioning, auto-provisioning, or domain matching.
System for Cross-domain Identity Management (SCIM), Just-in-Time (JIT)
provisioning, auto-provisioning, or domain matching.
- An [organization access token](/manuals/security/access-tokens/organization-access-tokens.md)
(OAT) stays with the organization when membership changes.
(OAT) stays with the organization when membership changes.
- [OIDC connections](/manuals/security/authentication/oidc-connections/_index.md)
use OpenID Connect to authenticate GitHub Actions with short-lived
tokens, as an alternative to a long-lived OAT.
use OpenID Connect to authenticate GitHub Actions with short-lived
tokens, as an alternative to a long-lived OAT.
- [Roles and permissions](/manuals/security/roles-and-permissions/_index.md)
control what members can do after they join.
control what members can do after they join.
## Next steps
content/manuals/security/security-announcements.md
+296 -106
View File
@@ -1,6 +1,9 @@
---
description: Docker security announcements
keywords: Docker, CVEs, security, notice, Log4J 2, Log4Shell, Text4Shell, announcements
description: >-
Security announcements for Docker products, including CVE fixes for Docker
Desktop, Docker Sandboxes, and Docker Official Images.
keywords: Docker security announcements, CVE, security advisory, vulnerability,
Docker Desktop security update, Log4j 2, Log4Shell, Text4Shell
title: Docker security announcements
linkTitle: Announcements
outputs: ["HTML", "markdown", "RSS"]
@@ -18,10 +21,24 @@ aliases:
## Docker Sandboxes 0.42.0 security update: CVE-2026-77179 and CVE-2026-79994
Two vulnerabilities in Docker Sandboxes were fixed on September 7 in the [0.42.0](/manuals/ai/sandboxes/release-notes.md#0420) release:
Two vulnerabilities in Docker Sandboxes were fixed on September 7 in the
[0.42.0](/manuals/ai/sandboxes/release-notes.md#0420) release:
- Addressed [CVE-2026-77179](https://www.cve.org/cverecord?id=CVE-2026-77179), where the virtio-fs host server on macOS followed symlinks when reopening an unlinked file from a stored path. A malicious guest could replace a parent directory with a symlink, escape the shared workspace, and read or modify arbitrary host files as the VMM user, potentially leading to code execution on the host. Versions 0.28.0 up to but not including 0.42.0 on macOS are affected. [Critical]
- Addressed [CVE-2026-79994](https://www.cve.org/cverecord?id=CVE-2026-79994), where the guest-to-host Unix domain socket relay checked that a socket path was inside an authorized workspace but reconnected using the path name. A malicious guest could replace an intermediate directory with a symlink between the check and the connection, causing the host to connect to an arbitrary `AF_UNIX` socket outside the shared workspace and exposing data or host-side capabilities provided by that socket. Versions 0.37.0 up to but not including 0.42.0 are affected. [High]
- Addressed [CVE-2026-77179](https://www.cve.org/cverecord?id=CVE-2026-77179),
where the virtio-fs host server on macOS followed symlinks when reopening an
unlinked file from a stored path. A malicious guest could replace a parent
directory with a symlink, escape the shared workspace, and read or modify
arbitrary host files as the VMM user, potentially leading to code execution on
the host. Versions 0.28.0 up to but not including 0.42.0 on macOS are
affected. [Critical]
- Addressed [CVE-2026-79994](https://www.cve.org/cverecord?id=CVE-2026-79994),
where the guest-to-host Unix domain socket relay checked that a socket path
was inside an authorized workspace but reconnected using the path name. A
malicious guest could replace an intermediate directory with a symlink between
the check and the connection, causing the host to connect to an arbitrary
`AF_UNIX` socket outside the shared workspace and exposing data or host-side
capabilities provided by that socket. Versions 0.37.0 up to but not including
0.42.0 are affected. [High]
If you can't update to [0.42.0](/manuals/ai/sandboxes/release-notes.md#0420) or
later, use [clone mode](/manuals/ai/sandboxes/usage.md#clone-mode) and avoid
@@ -29,134 +46,229 @@ adding read-write host mounts.
## Docker Desktop 4.86.0 security update: CVE-2026-17106
A vulnerability in Docker Desktop was fixed on August 10 in the [4.86.0](/manuals/desktop/release-notes.md#4860) release:
A vulnerability in Docker Desktop was fixed on August 10 in the
[4.86.0](/manuals/desktop/release-notes.md#4860) release:
- Addressed CVE-2026-17106, a destination-escape flaw in `docker container cp`.
- Addressed CVE-2026-17106, a destination-escape flaw in `docker container cp`.
## Docker Desktop 4.71.0 security update: CVE-2026-5843
A vulnerability in Docker Desktop was fixed on April 27 in the [4.71.0](/manuals/desktop/release-notes.md#4710) release:
A vulnerability in Docker Desktop was fixed on April 27 in the
[4.71.0](/manuals/desktop/release-notes.md#4710) release:
- Addressed [CVE-2026-5843](https://www.cve.org/cverecord?id=CVE-2026-5843), container-to-host code execution in the Docker Model Runner MLX inference backend.
- Addressed [CVE-2026-5843](https://www.cve.org/cverecord?id=CVE-2026-5843),
container-to-host code execution in the Docker Model Runner MLX inference
backend.
## Docker Desktop 4.68.0 security update: CVE-2026-5817
A vulnerability in Docker Desktop was fixed on April 7 in the [4.68.0](/manuals/desktop/release-notes.md#4680) release:
A vulnerability in Docker Desktop was fixed on April 7 in the
[4.68.0](/manuals/desktop/release-notes.md#4680) release:
- Addressed [CVE-2026-5817](https://www.cve.org/cverecord?id=CVE-2026-5817), container-to-host code execution in the Docker Model Runner vllm-metal inference backend.
- Addressed [CVE-2026-5817](https://www.cve.org/cverecord?id=CVE-2026-5817),
container-to-host code execution in the Docker Model Runner vllm-metal
inference backend.
## Docker Desktop 4.67.0 security update: CVE-2026-33990
A vulnerability in Docker Desktop was fixed on March 30 in the [4.67.0](/manuals/desktop/release-notes.md#4670) release:
A vulnerability in Docker Desktop was fixed on March 30 in the
[4.67.0](/manuals/desktop/release-notes.md#4670) release:
- Addressed [CVE-2026-33990](https://www.cve.org/cverecord?id=CVE-2026-33990), SSRF in Docker Model Runner OCI Registry Client
- Addressed [CVE-2026-33990](https://www.cve.org/cverecord?id=CVE-2026-33990),
SSRF in Docker Model Runner OCI Registry Client.
## Docker Desktop 4.62.0 security update: CVE-2026-28400
A vulnerability in Docker Desktop was fixed on February 23 in the [4.62.0](/manuals/desktop/release-notes.md#4620) release:
A vulnerability in Docker Desktop was fixed on February 23 in the
[4.62.0](/manuals/desktop/release-notes.md#4620) release:
- Addressed [CVE-2026-28400](https://www.cve.org/cverecord?id=CVE-2026-28400), runtime flag injection in Docker Model Runner.
- Addressed [CVE-2026-28400](https://www.cve.org/cverecord?id=CVE-2026-28400),
runtime flag injection in Docker Model Runner.
## Docker Desktop 4.62.0 security update: CVE-2026-2664
A vulnerability in Docker Desktop was fixed on February 23 in the [4.62.0](/manuals/desktop/release-notes.md#4620) release:
A vulnerability in Docker Desktop was fixed on February 23 in the
[4.62.0](/manuals/desktop/release-notes.md#4620) release:
- Fixed [CVE-2026-2664](https://www.cve.org/cverecord?id=CVE-2026-2664), out of bounds read in gRPC-FUSE kernel module.
- Fixed [CVE-2026-2664](https://www.cve.org/cverecord?id=CVE-2026-2664), out of
bounds read in gRPC-FUSE kernel module.
## Docker Desktop 4.54.0 security update: CVE-2025-13743
A vulnerability in Docker Desktop was fixed on December 4 in the [4.54.0](/manuals/desktop/release-notes.md#4540) release:
A vulnerability in Docker Desktop was fixed on December 4 in the
[4.54.0](/manuals/desktop/release-notes.md#4540) release:
- Fixed [CVE-2025-13743](https://www.cve.org/cverecord?id=CVE-2025-13743) where Docker Desktop diagnostics bundles were found to include expired Hub PATs in log output due to error object serialization.
- Fixed [CVE-2025-13743](https://www.cve.org/cverecord?id=CVE-2025-13743) where
Docker Desktop diagnostics bundles were found to include expired Hub PATs in
log output due to error object serialization.
## Docker Desktop 4.49.0 security update: CVE-2025-9164
A vulnerability in Docker Desktop for Windows was fixed on October 23 in the [4.49.0](/manuals/desktop/release-notes.md#4490) release:
A vulnerability in Docker Desktop for Windows was fixed on October 23 in the
[4.49.0](/manuals/desktop/release-notes.md#4490) release:
- Fixed [CVE-2025-9164](https://www.cve.org/cverecord?id=CVE-2025-9164) where the Docker Desktop for Windows installer was vulnerable to DLL hijacking due to insecure DLL search order. The installer searches for required DLLs in the user's Downloads folder before checking system directories, allowing local privilege escalation through malicious DLL placement.
- Fixed [CVE-2025-9164](https://www.cve.org/cverecord?id=CVE-2025-9164) where
the Docker Desktop for Windows installer was vulnerable to DLL hijacking due
to insecure DLL search order. The installer searches for required DLLs in the
user's Downloads folder before checking system directories, allowing local
privilege escalation through malicious DLL placement.
## Docker Desktop 4.47.0 security update: CVE-2025-10657
A vulnerability in Docker Desktop was fixed on September 25 in the [4.47.0](/manuals/desktop/release-notes.md#4470) release:
A vulnerability in Docker Desktop was fixed on September 25 in the
[4.47.0](/manuals/desktop/release-notes.md#4470) release:
- Fixed [CVE-2025-10657](https://www.cve.org/CVERecord?id=CVE-2025-10657) where the Enhanced Container Isolation [Docker Socket command restrictions](/manuals/desktop/enterprise/hardened-desktop/enhanced-container-isolation/config.md#command-restrictions) feature was not working properly in Docker Desktop 4.46.0 only (the configuration for it was being ignored).
- Fixed [CVE-2025-10657](https://www.cve.org/CVERecord?id=CVE-2025-10657) where
the Enhanced Container Isolation
[Docker Socket command restrictions](/manuals/desktop/enterprise/hardened-desktop/enhanced-container-isolation/config.md#command-restrictions)
feature was not working properly in Docker Desktop 4.46.0 only (the
configuration for it was being ignored).
## Docker Desktop 4.44.3 security update: CVE-2025-9074
_Last updated August 20, 2025_
A vulnerability in Docker Desktop was fixed on August 20 in the [4.44.3](/manuals/desktop/release-notes.md#4443) release:
A vulnerability in Docker Desktop was fixed on August 20 in the
[4.44.3](/manuals/desktop/release-notes.md#4443) release:
- Fixed [CVE-2025-9074](https://www.cve.org/CVERecord?id=CVE-2025-9074) where a malicious container running on Docker Desktop could access the Docker Engine and launch additional containers without requiring the Docker socket to be mounted. This could allow unauthorized access to user files on the host system. Enhanced Container Isolation (ECI) does not mitigate this vulnerability.
- Fixed [CVE-2025-9074](https://www.cve.org/CVERecord?id=CVE-2025-9074) where a
malicious container running on Docker Desktop could access the Docker Engine
and launch additional containers without requiring the Docker socket to be
mounted. This could allow unauthorized access to user files on the host
system. Enhanced Container Isolation (ECI) does not mitigate this
vulnerability.
## Docker Desktop 4.44.0 security update: CVE-2025-23266
_Last updated July 31, 2025_
We are aware of [CVE-2025-23266](https://nvd.nist.gov/vuln/detail/CVE-2025-23266), a critical vulnerability affecting the NVIDIA Container Toolkit in CDI mode up to version 1.17.7. Docker Desktop includes version 1.17.8, which is not impacted. However, older versions of Docker Desktop that bundled earlier toolkit versions may be affected if CDI mode was manually enabled. Upgrade to Docker Desktop 4.44 or later to ensure you're using the patched version.
Docker is aware of
[CVE-2025-23266](https://nvd.nist.gov/vuln/detail/CVE-2025-23266), a critical
vulnerability affecting the NVIDIA Container Toolkit in CDI mode up to version
1.17.7. Docker Desktop includes version 1.17.8, which is not impacted. However,
older versions of Docker Desktop that bundled earlier toolkit versions may be
affected if CDI mode was manually enabled. Upgrade to Docker Desktop 4.44 or
later to ensure you're using the patched version.
## Docker Desktop 4.43.0 security update: CVE-2025-6587
_Last updated July 03, 2025_
_Last updated July 3, 2025_
A vulnerability in Docker Desktop was fixed on July 03 in the [4.43.0](/manuals/desktop/release-notes.md#4430) release:
A vulnerability in Docker Desktop was fixed on July 3 in the
[4.43.0](/manuals/desktop/release-notes.md#4430) release:
- Fixed [CVE-2025-6587](https://www.cve.org/CVERecord?id=CVE-2025-6587) where sensitive system environment variables were included in Docker Desktop diagnostic logs, allowing for potential secret exposure.
- Fixed [CVE-2025-6587](https://www.cve.org/CVERecord?id=CVE-2025-6587) where
sensitive system environment variables were included in Docker Desktop
diagnostic logs, allowing for potential secret exposure.
## Docker Desktop 4.41.0 Security Update: CVE-2025-3224, CVE-2025-4095, and CVE-2025-3911
## Docker Desktop 4.41.0 security update: CVE-2025-3224, CVE-2025-4095, and CVE-2025-3911
_Last updated May 15, 2025_
Three vulnerabilities in Docker Desktop were fixed on April 28 in the [4.41.0](/manuals/desktop/release-notes.md#4410) release.
Three vulnerabilities in Docker Desktop were fixed on April 28 in the
[4.41.0](/manuals/desktop/release-notes.md#4410) release.
- Fixed [CVE-2025-3224](https://www.cve.org/CVERecord?id=CVE-2025-3224) allowing an attacker with access to a user machine to perform an elevation of privilege when Docker Desktop updates.
- Fixed [CVE-2025-4095](https://www.cve.org/CVERecord?id=CVE-2025-4095) where Registry Access Management (RAM) policies were not enforced when using a MacOS configuration profile, allowing users to pull images from unapproved registries.
- Fixed [CVE-2025-3911](https://www.cve.org/CVERecord?id=CVE-2025-3911) allowing an attacker with read access to a user's machine to obtain sensitive information from Docker Desktop log files, including environment variables configured for running containers.
- Fixed [CVE-2025-3224](https://www.cve.org/CVERecord?id=CVE-2025-3224) allowing
an attacker with access to a user machine to perform an elevation of privilege
when Docker Desktop updates.
- Fixed [CVE-2025-4095](https://www.cve.org/CVERecord?id=CVE-2025-4095) where
Registry Access Management (RAM) policies were not enforced when using a MacOS
configuration profile, allowing users to pull images from unapproved
registries.
- Fixed [CVE-2025-3911](https://www.cve.org/CVERecord?id=CVE-2025-3911) allowing
an attacker with read access to a user's machine to obtain sensitive
information from Docker Desktop log files, including environment variables
configured for running containers.
We strongly encourage you to update to Docker Desktop [4.41.0](/manuals/desktop/release-notes.md#4410).
Update to Docker Desktop
[4.41.0](/manuals/desktop/release-notes.md#4410).
## Docker Desktop 4.34.2 Security Update: CVE-2024-8695 and CVE-2024-8696
## Docker Desktop 4.34.2 security update: CVE-2024-8695 and CVE-2024-8696
_Last updated September 13, 2024_
Two remote code execution (RCE) vulnerabilities in Docker Desktop related to Docker Extensions were reported by [Cure53](https://cure53.de/) and were fixed on September 12 in the [4.34.2](/manuals/desktop/release-notes.md#4342) release.
Two remote code execution (RCE) vulnerabilities in Docker Desktop related to
Docker Extensions were reported by [Cure53](https://cure53.de/) and were fixed
on September 12 in the [4.34.2](/manuals/desktop/release-notes.md#4342) release.
- [CVE-2024-8695](https://www.cve.org/cverecord?id=CVE-2024-8695): A remote code execution (RCE) vulnerability via crafted extension description/changelog could be abused by a malicious extension in Docker Desktop before 4.34.2. [Critical]
- [CVE-2024-8696](https://www.cve.org/cverecord?id=CVE-2024-8696): A remote code execution (RCE) vulnerability via crafted extension publisher-url/additional-urls could be abused by a malicious extension in Docker Desktop before 4.34.2. [High]
- [CVE-2024-8695](https://www.cve.org/cverecord?id=CVE-2024-8695): A remote code
execution (RCE) vulnerability via crafted extension description/changelog
could be abused by a malicious extension in Docker Desktop before 4.34.2.
[Critical]
- [CVE-2024-8696](https://www.cve.org/cverecord?id=CVE-2024-8696): A remote code
execution (RCE) vulnerability via crafted extension
publisher-url/additional-urls could be abused by a malicious extension in
Docker Desktop before 4.34.2. [High]
No existing extensions exploiting the vulnerabilities were found in the Extensions Marketplace. The Docker Team will be closely monitoring and diligently reviewing any requests for publishing new extensions.
No existing extensions exploiting the vulnerabilities were found in the
Extensions Marketplace. The Docker Team will be closely monitoring and
diligently reviewing any requests for publishing new extensions.
We strongly encourage you to update to Docker Desktop [4.34.2](/manuals/desktop/release-notes.md#4342). If you are unable to update promptly, you can [disable Docker Extensions](/manuals/extensions/settings-feedback.md#turn-on-or-turn-off-extensions) as a workaround.
Update to Docker Desktop
[4.34.2](/manuals/desktop/release-notes.md#4342). If you are unable to update
promptly, you can
[disable Docker Extensions](/manuals/extensions/settings-feedback.md#turn-on-or-turn-off-extensions)
as a workaround.
## Deprecation of password logins on CLI when SSO enforced
_Last updated July, 2024_
_Last updated July 2024_
When [SSO enforcement](/manuals/security/authentication/single-sign-on/connect.md) was first introduced, Docker provided a grace period to continue to let passwords be used on the Docker CLI when authenticating to Docker Hub. This was allowed so organizations could more easily use SSO enforcement. It is recommended that administrators configuring SSO encourage users using the CLI [to switch over to Personal Access Tokens](/manuals/security/authentication/single-sign-on/_index.md#prerequisites) in anticipation of this grace period ending.
When
[SSO enforcement](/manuals/security/authentication/single-sign-on/connect.md)
was first introduced, Docker provided a grace period to continue to let
passwords be used on the Docker CLI when authenticating to Docker Hub. This was
allowed so organizations could adopt SSO enforcement. It is recommended that
administrators configuring SSO encourage users using the CLI
[to switch over to Personal Access Tokens](/manuals/security/authentication/single-sign-on/_index.md#prerequisites)
in anticipation of this grace period ending.
On September 16, 2024, the grace period ended and passwords can no longer authenticate to Docker Hub via the Docker CLI when SSO is enforced. Affected users are required to switch over to using PATs to continue signing in.
On September 16, 2024, the grace period ended and passwords can no longer
authenticate to Docker Hub via the Docker CLI when SSO is enforced. Affected
users are required to switch over to using PATs to continue signing in.
At Docker, we want the experience to be the most secure for our developers and organizations and this deprecation is an essential step in that direction.
This deprecation is a step toward a secure experience for developers and
organizations.
## SOC 2 Type 2 attestation and ISO 27001 certification
_Last updated June, 2024_
_Last updated June 2024_
Docker is pleased to announce that we have received our SOC 2 Type 2 attestation and ISO 27001 certification with no exceptions or major non-conformities.
Docker received its SOC 2 Type 2 attestation and ISO 27001 certification with
no exceptions or major non-conformities.
Security is a fundamental pillar to Docker's operations, which is embedded into our overall mission and company strategy. Docker's products are core to our user community and our SOC 2 Type 2 attestation and ISO 27001 certification demonstrate Docker's ongoing commitment to security to our user base.
Security is part of Docker's operations, mission, and company strategy.
Docker's products are core to the user community, and the SOC 2 Type 2
attestation and ISO 27001 certification demonstrate Docker's ongoing commitment
to security.
For more information, see the [Blog announcement](https://www.docker.com/blog/docker-announces-soc-2-type-2-attestation-iso-27001-certification/).
For more information, see the
[Blog announcement](https://www.docker.com/blog/docker-announces-soc-2-type-2-attestation-iso-27001-certification/).
## Docker Security Advisory: Multiple Vulnerabilities in runc, BuildKit, and Moby
## Docker security advisory: multiple vulnerabilities in runc, BuildKit, and Moby
_Last updated February 2, 2024_
We at Docker prioritize the security and integrity of our software and the trust of our users. Security researchers at Snyk Labs identified and reported four security vulnerabilities in the container ecosystem. One of the vulnerabilities, [CVE-2024-21626](https://scout.docker.com/v/CVE-2024-21626), concerns the runc container runtime, and the other three affect BuildKit ([CVE-2024-23651](https://scout.docker.com/v/CVE-2024-23651), [CVE-2024-23652](https://scout.docker.com/v/CVE-2024-23652), and [CVE-2024-23653](https://scout.docker.com/v/CVE-2024-23653)). We want to assure our community that our team, in collaboration with the reporters and open source maintainers, has been diligently working on coordinating and implementing necessary remediations.
Docker prioritizes the security and integrity of its software and the trust of
its users. Security researchers at Snyk Labs identified and reported four
security vulnerabilities in the container ecosystem. One of the vulnerabilities,
[CVE-2024-21626](https://scout.docker.com/v/CVE-2024-21626), concerns the runc
container runtime, and the other three affect BuildKit
([CVE-2024-23651](https://scout.docker.com/v/CVE-2024-23651),
[CVE-2024-23652](https://scout.docker.com/v/CVE-2024-23652), and
[CVE-2024-23653](https://scout.docker.com/v/CVE-2024-23653)). Docker, in
collaboration with the reporters and open source maintainers, coordinated and
implemented the remediations.
We are committed to maintaining the highest security standards. We have published patched versions of runc, BuildKit, and Moby on January 31 and released an update for Docker Desktop on February 1 to address these vulnerabilities. Additionally, our latest BuildKit and Moby releases included fixes for [CVE-2024-23650](https://scout.docker.com/v/CVE-2024-23650) and [CVE-2024-24557](https://scout.docker.com/v/CVE-2024-24557), discovered respectively by an independent researcher and through Docker's internal research initiatives.
Docker published patched versions of runc, BuildKit, and Moby on January 31 and
released an update for Docker Desktop on February 1 to address these
vulnerabilities. The latest BuildKit and Moby releases also included fixes for
[CVE-2024-23650](https://scout.docker.com/v/CVE-2024-23650) and
[CVE-2024-24557](https://scout.docker.com/v/CVE-2024-24557), discovered
respectively by an independent researcher and through Docker's internal research
initiatives.
| | Versions Impacted |
| | Versions impacted |
| :--------------------- | :---------------------- |
| `runc` | <= 1.1.11 |
| `BuildKit` | <= 0.12.4 |
@@ -165,60 +277,108 @@ We are committed to maintaining the highest security standards. We have publishe
### What should I do if I'm on an affected version?
If you are using affected versions of runc, BuildKit, Moby, or Docker Desktop, make sure to update to the latest versions, linked in the following table:
If you are using affected versions of runc, BuildKit, Moby, or Docker Desktop,
make sure to update to the latest versions, linked in the following table:
| | Patched Versions |
| | Patched versions |
| :--------------------- | :-------------------------------------------------------------------------------------------------------------------------------- |
| `runc` | >= [1.1.12](https://github.com/opencontainers/runc/releases/tag/v1.1.12) |
| `BuildKit` | >= [0.12.5](https://github.com/moby/buildkit/releases/tag/v0.12.5) |
| `Moby (Docker Engine)` | >= [25.0.2](https://github.com/moby/moby/releases/tag/v25.0.2) and >= [24.0.9](https://github.com/moby/moby/releases/tag/v24.0.9) |
| `Docker Desktop` | >= [4.27.1](/manuals/desktop/release-notes.md#4271) |
If you are unable to update to an unaffected version promptly, follow these best practices to mitigate risk:
If you are unable to update to an unaffected version promptly, follow these best
practices to mitigate risk:
- Only use trusted Docker images (such as [Docker Official Images](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images)).
- Only use trusted Docker images (such as
[Docker Official Images](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images)).
- Don't build Docker images from untrusted sources or untrusted Dockerfiles.
- If you are a Docker Business customer using Docker Desktop and unable to update to v4.27.1, make sure to enable [Hardened Docker Desktop](/manuals/desktop/enterprise/hardened-desktop/_index.md) features such as:
- [Enhanced Container Isolation](/manuals/desktop/enterprise/hardened-desktop/enhanced-container-isolation/_index.md), which mitigates the impact of CVE-2024-21626 in the case of running containers from malicious images.
- [Image Access Management](/manuals/desktop/enterprise/hardened-desktop/image-access-management.md), and [Registry Access Management](/manuals/desktop/enterprise/hardened-desktop/registry-access-management.md), which give organizations control over which images and repositories their users can access.
- For CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, avoid using BuildKit frontend from an untrusted source. A frontend image is usually specified as the #syntax line on your Dockerfile, or with `--frontend` flag when using the `buildctl build` command.
- To mitigate CVE-2024-24557, make sure to either use BuildKit or disable caching when building images. From the CLI this can be done via the `DOCKER_BUILDKIT=1` environment variable (default for Moby >= v23.0 if the Buildx plugin is installed) or the `--no-cache flag`. If you are using the HTTP API directly or through a client, the same can be done by setting `nocache` to `true` or `version` to `2` for the [/build API endpoint](https://docs.docker.com/reference/api/engine/version/v1.44/#tag/Image/operation/ImageBuild).
- If you are a Docker Business customer using Docker Desktop and unable to
update to v4.27.1, make sure to enable
[Hardened Docker Desktop](/manuals/desktop/enterprise/hardened-desktop/_index.md)
features such as:
- [Enhanced Container Isolation](/manuals/desktop/enterprise/hardened-desktop/enhanced-container-isolation/_index.md),
which mitigates the impact of CVE-2024-21626 in the case of running
containers from malicious images.
- [Image Access Management](/manuals/desktop/enterprise/hardened-desktop/image-access-management.md),
and
[Registry Access Management](/manuals/desktop/enterprise/hardened-desktop/registry-access-management.md),
which give organizations control over which images and repositories their
users can access.
- For CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, avoid
using BuildKit frontend from an untrusted source. A frontend image is usually
specified as the #syntax line on your Dockerfile, or with `--frontend` flag
when using the `buildctl build` command.
- To mitigate CVE-2024-24557, make sure to either use BuildKit or disable
caching when building images. From the CLI this can be done via the
`DOCKER_BUILDKIT=1` environment variable (default for Moby >= v23.0 if the
Buildx plugin is installed) or the `--no-cache flag`. If you are using the
HTTP API directly or through a client, the same can be done by setting
`nocache` to `true` or `version` to `2` for the
[/build API endpoint](https://docs.docker.com/reference/api/engine/version/v1.44/#tag/Image/operation/ImageBuild).
### Technical details and impact
#### CVE-2024-21626 (High)
In runc v1.1.11 and earlier, due to certain leaked file descriptors, an attacker can gain access to the host filesystem by causing a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, or by tricking a user to run a malicious image and allow a container process to gain access to the host filesystem through `runc run`. The attacks can also be adapted to overwrite semi-arbitrary host binaries, allowing for complete container escapes. Note that when using higher-level runtimes (such as Docker or Kubernetes), this vulnerability can be exploited by running a malicious container image without additional configuration or by passing specific workdir options when starting a container. The vulnerability can also be exploited from within Dockerfiles in the case of Docker.
In runc v1.1.11 and earlier, due to certain leaked file descriptors, an attacker
can gain access to the host filesystem by causing a newly-spawned container
process (from `runc exec`) to have a working directory in the host filesystem
namespace, or by tricking a user to run a malicious image and allow a container
process to gain access to the host filesystem through `runc run`. The attacks
can also be adapted to overwrite semi-arbitrary host binaries, allowing for
complete container escapes. Note that when using higher-level runtimes (such as
Docker or Kubernetes), this vulnerability can be exploited by running a
malicious container image without additional configuration or by passing
specific workdir options when starting a container. The vulnerability can also
be exploited from within Dockerfiles in the case of Docker.
_The issue has been fixed in runc v1.1.12._
#### CVE-2024-23651 (High)
In BuildKit <= v0.12.4, two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition, leading to files from the host system being accessible to the build container. This will only occur if a user is trying to build a Dockerfile of a malicious project.
In BuildKit <= v0.12.4, two malicious build steps running in parallel sharing
the same cache mounts with subpaths could cause a race condition, leading to
files from the host system being accessible to the build container. This will
only occur if a user is trying to build a Dockerfile of a malicious project.
_The issue has been fixed in BuildKit v0.12.5._
#### CVE-2024-23652 (High)
In BuildKit <= v0.12.4, a malicious BuildKit frontend or Dockerfile using `RUN --mount` could trick the feature that removes empty files created for the mountpoints into removing a file outside the container from the host system. This will only occur if a user is using a malicious Dockerfile.
In BuildKit <= v0.12.4, a malicious BuildKit frontend or Dockerfile using
`RUN --mount` could trick the feature that removes empty files created for the
mountpoints into removing a file outside the container from the host system.
This will only occur if a user is using a malicious Dockerfile.
_The issue has been fixed in BuildKit v0.12.5._
#### CVE-2024-23653 (High)
In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. In BuildKit <= v0.12.4, it is possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request.
In addition to running containers as build steps, BuildKit also provides APIs
for running interactive containers based on built images. In BuildKit <=
v0.12.4, it is possible to use these APIs to ask BuildKit to run a container
with elevated privileges. Normally, running such containers is only allowed if
special `security.insecure` entitlement is enabled both by buildkitd
configuration and allowed by the user initializing the build request.
_The issue has been fixed in BuildKit v0.12.5._
#### CVE-2024-23650 (Medium)
In BuildKit <= v0.12.4, a malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.
In BuildKit <= v0.12.4, a malicious BuildKit client or frontend could craft a
request that could lead to BuildKit daemon crashing with a panic.
_The issue has been fixed in BuildKit v0.12.5._
#### CVE-2024-24557 (Medium)
In Moby <= v25.0.1 and <= v24.0.8, the classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being `HEALTHCHECK` and `ONBUILD`) would not cause a cache miss. An attacker with knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered a valid cache candidate for some build steps.
In Moby <= v25.0.1 and <= v24.0.8, the classic builder cache system is prone to
cache poisoning if the image is built FROM scratch. Also, changes to some
instructions (most important being `HEALTHCHECK` and `ONBUILD`) would not cause
a cache miss. An attacker with knowledge of the Dockerfile someone is using
could poison their cache by making them pull a specially crafted image that
would be considered a valid cache candidate for some build steps.
_The issue has been fixed in Moby >= v25.0.2 and >= v24.0.9._
@@ -226,13 +386,23 @@ _The issue has been fixed in Moby >= v25.0.2 and >= v24.0.9._
#### Docker Desktop
Docker Desktop v4.27.0 and earlier are affected. Docker Desktop v4.27.1 was released on February 1 and includes runc, BuildKit, and dockerd binaries patches. In addition to updating to this new version, we encourage all Docker users to diligently use Docker images and Dockerfiles and ensure you only use trusted content in your builds.
Docker Desktop v4.27.0 and earlier are affected. Docker Desktop v4.27.1 was
released on February 1 and includes runc, BuildKit, and dockerd binaries
patches. In addition to updating to this new version, use only trusted Docker
images and Dockerfiles in your builds.
As always, you should check Docker Desktop system requirements for your operating system ([Windows](/manuals/desktop/setup/install/windows-install.md#system-requirements), [Linux](/manuals/desktop/setup/install/linux/_index.md#general-system-requirements), [Mac](/manuals/desktop/setup/install/mac-install.md#system-requirements)) before updating to ensure full compatibility.
As always, you should check Docker Desktop system requirements for your
operating system
([Windows](/manuals/desktop/setup/install/windows-install.md#system-requirements),
[Linux](/manuals/desktop/setup/install/linux/_index.md#general-system-requirements),
[Mac](/manuals/desktop/setup/install/mac-install.md#system-requirements)) before
updating to ensure full compatibility.
#### Docker Build Cloud
Any new Docker Build Cloud builder instances will be provisioned with the latest Docker Engine and BuildKit versions and will, therefore, be unaffected by these CVEs. Updates have also been rolled out to existing Docker Build Cloud builders.
Any new Docker Build Cloud builder instances will be provisioned with the latest
Docker Engine and BuildKit versions and will, therefore, be unaffected by these
CVEs. Updates have also been rolled out to existing Docker Build Cloud builders.
_No other Docker products are affected by these vulnerabilities._
@@ -252,23 +422,29 @@ _No other Docker products are affected by these vulnerabilities._
_Last updated October 2022_
[CVE-2022-42889](https://nvd.nist.gov/vuln/detail/CVE-2022-42889) has been discovered in the popular Apache Commons Text library. Versions of this library up to but not including 1.10.0 are affected by this vulnerability.
[CVE-2022-42889](https://nvd.nist.gov/vuln/detail/CVE-2022-42889) has been
discovered in the popular Apache Commons Text library. Versions of this library
up to but not including 1.10.0 are affected by this vulnerability.
We strongly encourage you to update to the latest version of [Apache Commons Text](https://commons.apache.org/proper/commons-text/download_text.cgi).
Update to the latest version of
[Apache Commons Text](https://commons.apache.org/proper/commons-text/download_text.cgi).
### Scan images on Docker Hub
Docker Hub security scans triggered after 1200 UTC 21 October 2021 are now
correctly identifying the Text4Shell CVE. Scans before this date do not
currently reflect the status of this vulnerability. Therefore, we recommend that
you trigger scans by pushing new images to Docker Hub to view the status of
the Text4Shell CVE in the vulnerability report. For detailed instructions, see [Scan images on Docker Hub](/manuals/docker-hub/repos/manage/vulnerability-scanning.md).
currently reflect the status of this vulnerability. Trigger scans by pushing
new images to Docker Hub to view the status of the Text4Shell CVE in the
vulnerability report. For detailed instructions, see
[Scan images on Docker Hub](/manuals/docker-hub/repos/manage/vulnerability-scanning.md).
### Docker Official Images impacted by CVE-2022-42889
A number of [Docker Official Images](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images) contain the vulnerable versions of
Apache Commons Text. The following lists Docker Official Images that
may contain the vulnerable versions of Apache Commons Text:
A number of
[Docker Official Images](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images)
contain the vulnerable versions of Apache Commons Text. The following lists
Docker Official Images that may contain the vulnerable versions of Apache
Commons Text:
- [bonita](https://hub.docker.com/_/bonita)
- [Couchbase](https://hub.docker.com/_/couchbase)
@@ -278,50 +454,64 @@ may contain the vulnerable versions of Apache Commons Text:
- [solr](https://hub.docker.com/_/solr)
- [xwiki](https://hub.docker.com/_/xwiki)
We have updated
Apache Commons Text in these images to the latest version. Some of these images may not be
vulnerable for other reasons. We recommend that you also review the guidelines published on the upstream websites.
Docker updated Apache Commons Text in these images to the latest version. Some
of these images may not be vulnerable for other reasons. Also review the
guidelines published on the upstream websites.
## Log4j 2 CVE-2021-44228
_Last updated December 2021_
The [Log4j 2 CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) vulnerability in Log4j 2, a very common Java logging library, allows remote code execution, often from a context that is easily available to an attacker. For example, it was found in Minecraft servers which allowed the commands to be typed into chat logs as these were then sent to the logger. This makes it a very serious vulnerability, as the logging library is used so widely and it may be simple to exploit. Many open source maintainers are working hard with fixes and updates to the software ecosystem.
The [Log4j 2 CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)
vulnerability in Log4j 2, a common Java logging library, allows remote code
execution, often from a context that is available to an attacker. For example,
it was found in Minecraft servers which allowed the commands to be typed into
chat logs as these were then sent to the logger. This makes it a serious
vulnerability, as the logging library is used so widely and it may be simple
to exploit. Many open source maintainers are working hard with fixes and
updates to the software ecosystem.
The vulnerable versions of Log4j 2 are versions 2.0 to version 2.14.1 inclusive. The first fixed version is 2.15.0. We strongly encourage you to update to the [latest version](https://logging.apache.org/log4j/2.x/download.html) if you can. If you are using a version before 2.0, you are also not vulnerable.
The vulnerable versions of Log4j 2 are versions 2.0 to version 2.14.1 inclusive.
The first fixed version is 2.15.0. Update to the
[latest version](https://logging.apache.org/log4j/2.x/download.html) if you can.
If you are using a version before 2.0, you are also not vulnerable.
You may not be vulnerable if you are using these versions, as your configuration
may already mitigate this, or the things you
log may not include any user input. This may be difficult to validate however
without understanding all the code paths that may log in detail, and where they
may get input from. So you probably will want to upgrade all code using
vulnerable versions.
may already mitigate this, or the things you log may not include any user input.
This may be difficult to validate however without understanding all the code
paths that may log in detail, and where they may get input from. So you probably
will want to upgrade all code using vulnerable versions.
> CVE-2021-45046
>
> As an update to
> [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), the fix made in version 2.15.0 was
> incomplete. Additional issues have been identified and are tracked with
> [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), the fix
> made in version 2.15.0 was incomplete. Additional issues have been identified
> and are tracked with
> [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) and
> [CVE-2021-45105](https://nvd.nist.gov/vuln/detail/CVE-2021-45105).
> For a more complete fix to this vulnerability, we recommended that you update to 2.17.0 where possible.
> [CVE-2021-45105](https://nvd.nist.gov/vuln/detail/CVE-2021-45105). For a more
> complete fix to this vulnerability, update to 2.17.0 where possible.
### Scan images on Docker Hub
Docker Hub security scans triggered after 1700 UTC 13 December 2021 are now
correctly identifying the Log4j 2 CVEs. Scans before this date do not
currently reflect the status of this vulnerability. Therefore, we recommend that
you trigger scans by pushing new images to Docker Hub to view the status of
Log4j 2 CVE in the vulnerability report. For detailed instructions, see [Scan images on Docker Hub](/manuals/docker-hub/repos/manage/vulnerability-scanning.md).
correctly identifying the Log4j 2 CVEs. Scans before this date do not currently
reflect the status of this vulnerability. Trigger scans by pushing new images
to Docker Hub to view the status of Log4j 2 CVE in the vulnerability report.
For detailed instructions, see
[Scan images on Docker Hub](/manuals/docker-hub/repos/manage/vulnerability-scanning.md).
## Docker Official Images impacted by Log4j 2 CVE
_Last updated December 2021_
A number of [Docker Official Images](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images) contain the vulnerable versions of
Log4j 2 CVE-2021-44228. The following table lists Docker Official Images that
may contained the vulnerable versions of Log4j 2. We updated Log4j 2 in these images to the latest version. Some of these images may not be
vulnerable for other reasons. We recommend that you also review the guidelines published on the upstream websites.
A number of
[Docker Official Images](/manuals/docker-hub/image-library/trusted-content.md#docker-official-images)
contain the vulnerable versions of Log4j 2 CVE-2021-44228. The following table
lists Docker Official Images that may contain the vulnerable versions of Log4j
2. Docker updated Log4j 2 in these images to the latest version. Some of these
images may not be vulnerable for other reasons. Also review the guidelines
published on the upstream websites.
| Repository | Patched version | Additional documentation |
| :------------------------------------------------------ | :----------------------------- | :---------------------------------------------------------------------------------------------------------------------- |
@@ -338,8 +528,8 @@ vulnerable for other reasons. We recommend that you also review the guidelines p
> [!NOTE]
>
> Although [xwiki](https://hub.docker.com/_/xwiki) images may be detected as vulnerable
> by some scanners, the authors believe the images are not vulnerable by Log4j 2
> CVE as the API jars do not contain the vulnerability.
> The [Nuxeo](https://hub.docker.com/_/nuxeo)
> image is deprecated and will not be updated.
> Although [xwiki](https://hub.docker.com/_/xwiki) images may be detected as
> vulnerable by some scanners, the authors believe the images are not vulnerable
> by Log4j 2 CVE as the API jars do not contain the vulnerability. The
> [Nuxeo](https://hub.docker.com/_/nuxeo) image is deprecated and will not be
> updated.