{ "version": "1", "package": [ { "name": "docker-moby", "layer": "meta-virtualization", "version": "25.0.3+gitf417435e5f6216828dec57958c490c4f8bae4f98", "products": [ { "product": "docker", "cvesInRecord": "Yes" }, { "product": "moby", "cvesInRecord": "Yes" } ], "issue": [ { "id": "CVE-2014-0047", "summary": "Docker before 1.5 allows local users to have unspecified impact via vectors involving unsafe /tmp usage.", "scorev2": "4.6", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-0047" }, { "id": "CVE-2014-0048", "summary": "An issue was found in Docker before 1.6.0. Some programs and scripts in Docker are downloaded via HTTP and then executed or used in unsafe ways.", "scorev2": "7.5", "scorev3": "9.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-0048" }, { "id": "CVE-2014-3499", "summary": "Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.", "scorev2": "7.2", "scorev3": "0.0", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-3499" }, { "id": "CVE-2014-5277", "summary": "Docker before 1.3.1 and docker-py before 0.5.3 fall back to HTTP when the HTTPS connection to the registry fails, which allows man-in-the-middle attackers to conduct downgrade attacks and obtain authentication and image data by leveraging a network position between the client and the registry to block HTTPS traffic.", "scorev2": "5.0", "scorev3": "0.0", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-5277" }, { "id": "CVE-2014-5278", "summary": "A vulnerability exists in Docker before 1.2 via container names, which may collide with and override container IDs.", "scorev2": "4.3", "scorev3": "5.3", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-5278" }, { "id": "CVE-2014-5282", "summary": "Docker before 1.3 does not properly validate image IDs, which allows remote attackers to redirect to another image through the loading of untrusted images via 'docker load'.", "scorev2": "5.5", "scorev3": "8.1", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-5282" }, { "id": "CVE-2014-6407", "summary": "Docker before 1.3.2 allows remote attackers to write to arbitrary files and execute arbitrary code via a (1) symlink or (2) hard link attack in an image archive in a (a) pull or (b) load operation.", "scorev2": "7.5", "scorev3": "0.0", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-6407" }, { "id": "CVE-2014-6408", "summary": "Docker 1.3.0 through 1.3.1 allows remote attackers to modify the default run profile of image containers and possibly bypass the container by applying unspecified security options to an image.", "scorev2": "5.0", "scorev3": "0.0", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-6408" }, { "id": "CVE-2014-8178", "summary": "Docker Engine before 1.8.3 and CS Docker Engine before 1.6.2-CS7 do not use a globally unique identifier to store image layers, which makes it easier for attackers to poison the image cache via a crafted image in pull or push commands.", "scorev2": "1.9", "scorev3": "5.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-8178" }, { "id": "CVE-2014-8179", "summary": "Docker Engine before 1.8.3 and CS Docker Engine before 1.6.2-CS7 does not properly validate and extract the manifest object from its JSON representation during a pull, which allows attackers to inject new attributes in a JSON object and bypass pull-by-digest validation.", "scorev2": "5.0", "scorev3": "7.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-8179" }, { "id": "CVE-2014-9356", "summary": "Path traversal vulnerability in Docker before 1.3.3 allows remote attackers to write to arbitrary files and bypass a container protection mechanism via a full pathname in a symlink in an (1) image or (2) build in a Dockerfile.", "scorev2": "8.5", "scorev3": "8.6", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:N/I:C/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-9356" }, { "id": "CVE-2014-9357", "summary": "Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build in a Dockerfile in an LZMA (.xz) archive, related to the chroot for archive extraction.", "scorev2": "10.0", "scorev3": "0.0", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-9357" }, { "id": "CVE-2014-9358", "summary": "Docker before 1.3.3 does not properly validate image IDs, which allows remote attackers to conduct path traversal attacks and spoof repositories via a crafted image in a (1) \"docker load\" operation or (2) \"registry communications.\"", "scorev2": "6.4", "scorev3": "0.0", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2014-9358" }, { "id": "CVE-2015-1843", "summary": "The Red Hat docker package before 1.5.0-28, when using the --add-registry option, falls back to HTTP when the HTTPS connection to the registry fails, which allows man-in-the-middle attackers to conduct downgrade attacks and obtain authentication and image data by leveraging a network position between the client and the registry to block HTTPS traffic. NOTE: this vulnerability exists because of a CVE-2014-5277 regression.", "scorev2": "4.3", "scorev3": "0.0", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2015-1843" }, { "id": "CVE-2015-3627", "summary": "Libcontainer and Docker Engine before 1.6.1 opens the file-descriptor passed to the pid-1 process before performing the chroot, which allows local users to gain privileges via a symlink attack in an image.", "scorev2": "7.2", "scorev3": "0.0", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2015-3627" }, { "id": "CVE-2015-3630", "summary": "Docker Engine before 1.6.1 uses weak permissions for (1) /proc/asound, (2) /proc/timer_stats, (3) /proc/latency_stats, and (4) /proc/fs, which allows local users to modify the host, obtain sensitive information, and perform protocol downgrade attacks via a crafted image.", "scorev2": "7.2", "scorev3": "0.0", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2015-3630" }, { "id": "CVE-2015-3631", "summary": "Docker Engine before 1.6.1 allows local users to set arbitrary Linux Security Modules (LSM) and docker_t policies via an image that allows volumes to override files in /proc.", "scorev2": "3.6", "scorev3": "0.0", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:N/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2015-3631" }, { "id": "CVE-2016-3697", "summary": "libcontainer/user/user.go in runC before 0.1.0, as used in Docker before 1.11.2, improperly treats a numeric UID as a potential username, which allows local users to gain privileges via a numeric username in the password file in a container.", "scorev2": "2.1", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-3697" }, { "id": "CVE-2016-6595", "summary": "The SwarmKit toolkit 1.12.0 for Docker allows remote authenticated users to cause a denial of service (prevention of cluster joins) via a long sequence of join and quit actions. NOTE: the vendor disputes this issue, stating that this sequence is not \"removing the state that is left by old nodes. At some point the manager obviously stops being able to accept new nodes, since it runs out of memory. Given that both for Docker swarm and for Docker Swarmkit nodes are *required* to provide a secret token (it's actually the only mode of operation), this means that no adversary can simply join nodes and exhaust manager resources. We can't do anything about a manager running out of memory and not being able to add new legitimate nodes to the system. This is merely a resource provisioning issue, and definitely not a CVE worthy vulnerability.", "scorev2": "4.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:S/C:N/I:N/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-6595" }, { "id": "CVE-2016-8867", "summary": "Docker Engine 1.12.2 enabled ambient capabilities with misconfigured capability policies. This allowed malicious images to bypass user permissions to access files within the container filesystem or mounted volumes.", "scorev2": "5.0", "scorev3": "7.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-8867" }, { "id": "CVE-2016-9962", "summary": "RunC allowed additional container processes via 'runc exec' to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during the initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container.", "scorev2": "4.4", "scorev3": "6.4", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-9962" }, { "id": "CVE-2017-14992", "summary": "Lack of content verification in Docker-CE (Also known as Moby) versions 1.12.6-0, 1.10.3, 17.03.0, 17.03.1, 17.03.2, 17.06.0, 17.06.1, 17.06.2, 17.09.0, and earlier allows a remote attacker to cause a Denial of Service via a crafted image layer payload, aka gzip bombing.", "scorev2": "4.3", "scorev3": "6.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2017-14992" }, { "id": "CVE-2017-16539", "summary": "The DefaultLinuxSpec function in oci/defaults.go in Docker Moby through 17.03.2-ce does not block /proc/scsi pathnames, which allows attackers to trigger data loss (when certain older Linux kernels are used) by leveraging Docker container access to write a \"scsi remove-single-device\" line to /proc/scsi/scsi, aka SCSI MICDROP.", "scorev2": "4.3", "scorev3": "5.9", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2017-16539" }, { "id": "CVE-2018-10892", "summary": "The default OCI linux spec in oci/defaults{_linux}.go in Docker/Moby from 1.11 to current does not block /proc/acpi pathnames. The flaw allows an attacker to modify host's hardware like enabling/disabling bluetooth or turning up/down keyboard brightness.", "scorev2": "5.0", "scorev3": "6.3", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2018-10892" }, { "id": "CVE-2018-12608", "summary": "An issue was discovered in Docker Moby before 17.06.0. The Docker engine validated a client TLS certificate using both the configured client CA root certificate and all system roots on non-Windows systems. This allowed a client with any domain validated certificate signed by a system-trusted root CA (as opposed to one signed by the configured CA root certificate) to authenticate.", "scorev2": "5.0", "scorev3": "7.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2018-12608" }, { "id": "CVE-2018-15514", "summary": "HandleRequestAsync in Docker for Windows before 18.06.0-ce-rc3-win68 (edge) and before 18.06.0-ce-win72 (stable) deserialized requests over the \\\\.\\pipe\\dockerBackend named pipe without verifying the validity of the deserialized .NET objects. This would allow a malicious user in the \"docker-users\" group (who may not otherwise have administrator access) to escalate to administrator privileges.", "scorev2": "6.5", "scorev3": "8.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2018-15514" }, { "id": "CVE-2018-15664", "summary": "In Docker through 18.06.1-ce-rc2, the API endpoints behind the 'docker cp' command are vulnerable to a symlink-exchange attack with Directory Traversal, giving attackers arbitrary read-write access to the host filesystem with root privileges, because daemon/archive.go does not do archive operations on a frozen filesystem (or from within a chroot).", "scorev2": "6.2", "scorev3": "7.5", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:H/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2018-15664" }, { "id": "CVE-2019-10340", "summary": "A cross-site request forgery vulnerability in Jenkins Docker Plugin 1.1.6 and earlier in DockerAPI.DescriptorImpl#doTestConnection allowed users with Overall/Read access to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.", "scorev2": "6.8", "scorev3": "8.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-10340" }, { "id": "CVE-2019-10341", "summary": "A missing permission check in Jenkins Docker Plugin 1.1.6 and earlier in DockerAPI.DescriptorImpl#doTestConnection allowed users with Overall/Read access to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.", "scorev2": "4.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:S/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-10341" }, { "id": "CVE-2019-10342", "summary": "A missing permission check in Jenkins Docker Plugin 1.1.6 and earlier in various 'fillCredentialsIdItems' methods allowed users with Overall/Read access to enumerate credentials ID of credentials stored in Jenkins.", "scorev2": "4.0", "scorev3": "4.3", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:S/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-10342" }, { "id": "CVE-2019-13139", "summary": "In Docker before 18.09.4, an attacker who is capable of supplying or manipulating the build path for the \"docker build\" command would be able to gain command execution. An issue exists in the way \"docker build\" processes remote git URLs, and results in command injection into the underlying \"git clone\" command, leading to code execution in the context of the user executing the \"docker build\" command. This occurs because git ref can be misinterpreted as a flag.", "scorev2": "4.6", "scorev3": "8.4", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-13139" }, { "id": "CVE-2019-13509", "summary": "In Docker CE and EE before 18.09.8 (as well as Docker EE before 17.06.2-ee-23 and 18.x before 18.03.1-ee-10), Docker Engine in debug mode may sometimes add secrets to the debug log. This applies to a scenario where docker stack deploy is run to redeploy a stack that includes (non external) secrets. It potentially applies to other API users of the stack API if they resend the secret.", "scorev2": "5.0", "scorev3": "7.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-13509" }, { "id": "CVE-2019-14271", "summary": "In Docker 19.03.x before 19.03.1 linked against the GNU C Library (aka glibc), code injection can occur when the nsswitch facility dynamically loads a library inside a chroot that contains the contents of the container.", "scorev2": "7.5", "scorev3": "9.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-14271" }, { "id": "CVE-2019-15752", "summary": "Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-credential-wincred.exe file in %PROGRAMDATA%\\DockerDesktop\\version-bin\\ as a low-privilege user, and then waiting for an admin or service user to authenticate with Docker, restart Docker, or run 'docker login' to force the command.", "scorev2": "9.3", "scorev3": "7.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-15752" }, { "id": "CVE-2019-16884", "summary": "runc through 1.0.0-rc8, as used in Docker through 19.03.2-ce and other products, allows AppArmor restriction bypass because libcontainer/rootfs_linux.go incorrectly checks mount targets, and thus a malicious Docker image can mount over a /proc directory.", "scorev2": "5.0", "scorev3": "7.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-16884" }, { "id": "CVE-2019-5736", "summary": "runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.", "scorev2": "9.3", "scorev3": "8.6", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-5736" }, { "id": "CVE-2020-14298", "summary": "The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the fix for CVE-2019-5736, which was previously fixed via RHSA-2019:0304. This issue could allow a malicious or compromised container to compromise the container host and other containers running on the same host. This issue only affects docker version 1.13.1-108.git4ef4b30.el7, shipped in Red Hat Enterprise Linux 7 Extras. Both earlier and later versions are not affected.", "scorev2": "4.6", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2020-14298" }, { "id": "CVE-2020-14300", "summary": "The docker packages version docker-1.13.1-108.git4ef4b30.el7 as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 (https://access.redhat.com/errata/RHBA-2020:0053) included an incorrect version of runc that was missing multiple bug and security fixes. One of the fixes regressed in that update was the fix for CVE-2016-9962, that was previously corrected in the docker packages in Red Hat Enterprise Linux 7 Extras via RHSA-2017:0116 (https://access.redhat.com/errata/RHSA-2017:0116). The CVE-2020-14300 was assigned to this security regression and it is specific to the docker packages produced by Red Hat. The original issue - CVE-2016-9962 - could possibly allow a process inside container to compromise a process entering container namespace and execute arbitrary code outside of the container. This could lead to compromise of the container host or other containers running on the same container host. This issue only affects a single version of Docker, 1.13.1-108.git4ef4b30, shipped in Red Hat Enterprise Linux 7. Both earlier and later versions are not affected.", "scorev2": "4.6", "scorev3": "8.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2020-14300" }, { "id": "CVE-2020-27534", "summary": "util/binfmt_misc/check.go in Builder in Docker Engine before 19.03.9 calls os.OpenFile with a potentially unsafe qemu-check temporary pathname, constructed with an empty first argument in an ioutil.TempDir call.", "scorev2": "5.0", "scorev3": "5.3", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2020-27534" }, { "id": "CVE-2021-21284", "summary": "In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in which access to remapped root allows privilege escalation to real root. When using \"--userns-remap\", if the root user in the remapped namespace has access to the host filesystem they can modify files under \"/var/lib/docker/\" that cause writing files with extended privileges. Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user.", "scorev2": "2.7", "scorev3": "6.8", "scorev4": "0.0", "vector": "ADJACENT_NETWORK", "vectorString": "AV:A/AC:L/Au:S/C:N/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-21284" }, { "id": "CVE-2021-21285", "summary": "In Docker before versions 9.03.15, 20.10.3 there is a vulnerability in which pulling an intentionally malformed Docker image manifest crashes the dockerd daemon. Versions 20.10.3 and 19.03.15 contain patches that prevent the daemon from crashing.", "scorev2": "4.3", "scorev3": "6.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-21285" }, { "id": "CVE-2021-3162", "summary": "Docker Desktop Community before 2.5.0.0 on macOS mishandles certificate checking, leading to local privilege escalation.", "scorev2": "4.6", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-3162" }, { "id": "CVE-2021-33183", "summary": "Improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability container volume management component in Synology Docker before 18.09.0-0515 allows local users to read or write arbitrary files via unspecified vectors.", "scorev2": "3.6", "scorev3": "7.9", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-33183" }, { "id": "CVE-2021-41089", "summary": "Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where attempting to copy files using `docker cp` into a specially-crafted container can result in Unix file permission changes for existing files in the host\u2019s filesystem, widening access to others. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers do not need to be restarted.", "scorev2": "4.4", "scorev3": "2.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:M/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-41089" }, { "id": "CVE-2021-41091", "summary": "Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where the data directory (typically `/var/lib/docker`) contained subdirectories with insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as `setuid`), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade limit access to the host to trusted users. Limit access to host volumes to trusted containers.", "scorev2": "4.6", "scorev3": "6.3", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2021-41091" }, { "id": "CVE-2022-24769", "summary": "Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted. This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop inheritable capabilities prior to the primary process starting.", "scorev2": "4.6", "scorev3": "5.9", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-24769" }, { "id": "CVE-2022-25365", "summary": "Docker Desktop before 4.5.1 on Windows allows attackers to move arbitrary files. NOTE: this issue exists because of an incomplete fix for CVE-2022-23774.", "scorev2": "4.6", "scorev3": "7.8", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-25365" }, { "id": "CVE-2022-27652", "summary": "A flaw was found in cri-o, where containers were incorrectly started with non-empty default permissions. A vulnerability was found in Moby (Docker Engine) where containers started incorrectly with non-empty inheritable Linux process capabilities. This flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs.", "scorev2": "4.6", "scorev3": "5.3", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-27652" }, { "id": "CVE-2022-36109", "summary": "Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where supplementary groups are not set up properly. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. This bug is fixed in Moby (Docker Engine) 20.10.18. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade, this problem can be worked around by not using the `\"USER $USERNAME\"` Dockerfile instruction. Instead by calling `ENTRYPOINT [\"su\", \"-\", \"user\"]` the supplementary groups will be set up properly.", "scorev2": "0.0", "scorev3": "5.3", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2022-36109" }, { "id": "CVE-2023-28840", "summary": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby, is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.\n\nThe overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nTwo iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.\n\nThe injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container\u2019s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.\n\nPatches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\nSome workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.", "scorev2": "0.0", "scorev3": "7.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:L", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-28840" }, { "id": "CVE-2023-28841", "summary": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.\n\nThe `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nAn iptables rule designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation.\n\nEncrypted overlay networks on affected platforms silently transmit unencrypted data. As a result, `overlay` networks may appear to be functional, passing traffic as expected, but without any of the expected confidentiality or data integrity guarantees.\n\nIt is possible for an attacker sitting in a trusted position on the network to read all of the application traffic that is moving across the overlay network, resulting in unexpected secrets or user data disclosure. Thus, because many database protocols, internal APIs, etc. are not protected by a second layer of encryption, a user may use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed.\n\nPatches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\nSome workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.", "scorev2": "0.0", "scorev3": "6.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-28841" }, { "id": "CVE-2023-28842", "summary": "Moby) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.\n\nThe `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nThe `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.\n\nEncrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration.\n\nPatches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\nSome workarounds are available. In multi-node clusters, deploy a global \u2018pause\u2019 container for each encrypted overlay network, on every node. For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec.", "scorev2": "0.0", "scorev3": "6.8", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-28842" }, { "id": "CVE-2024-24557", "summary": "Moby is an open-source project created by Docker to enable software containerization. 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 the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. 23.0+ users are only affected if they explicitly opted out of Buildkit (DOCKER_BUILDKIT=0 environment variable) or are using the /build API endpoint. All users on versions older than 23.0 could be impacted. Image build API endpoint (/build) and ImageBuild function from github.com/docker/docker/client is also affected as it the uses classic builder by default. Patches are included in 24.0.9 and 25.0.2 releases.", "scorev2": "0.0", "scorev3": "6.9", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:L/I:H/A:L", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2024-24557" }, { "id": "CVE-2024-29018", "summary": "Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.\n\nWhen containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.\n\nContainers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.\n\nIn addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver.\n\nWhen a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.\n\nAs a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.\n\nMany systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected.\n\nBecause `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers.\n\nDocker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.\n\nMoby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace.", "scorev2": "0.0", "scorev3": "5.9", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N", "status": "Unpatched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2024-29018" }, { "id": "CVE-2024-32473", "summary": "Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. In 26.0.0, IPv6 is not disabled on network interfaces, including those belonging to networks where `--ipv6=false`. An container with an `ipvlan` or `macvlan` interface will normally be configured to share an external network link with the host machine. Because of this direct access, (1) Containers may be able to communicate with other hosts on the local network over link-local IPv6 addresses, (2) if router advertisements are being broadcast over the local network, containers may get SLAAC-assigned addresses, and (3) the interface will be a member of IPv6 multicast groups. This means interfaces in IPv4-only networks present an unexpectedly and unnecessarily increased attack surface. The issue is patched in 26.0.2. To completely disable IPv6 in a container, use `--sysctl=net.ipv6.conf.all.disable_ipv6=1` in the `docker create` or `docker run` command. Or, in the service configuration of a `compose` file.", "scorev2": "0.0", "scorev3": "4.7", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2024-32473" }, { "id": "CVE-2024-36620", "summary": "moby v25.0.0 - v26.0.2 is vulnerable to NULL Pointer Dereference via daemon/images/image_history.go.", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2024-36620" }, { "id": "CVE-2024-36621", "summary": "moby v25.0.5 is affected by a Race Condition in builder/builder-next/adapters/snapshot/layer.go. The vulnerability could be used to trigger concurrent builds that call the EnsureLayer function resulting in resource leaks/exhaustion.", "scorev2": "0.0", "scorev3": "6.5", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2024-36621" }, { "id": "CVE-2024-36623", "summary": "moby through v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to trigger multiple concurrent write operations resulting in data corruption or application crashes.", "scorev2": "0.0", "scorev3": "8.1", "scorev4": "0.0", "vector": "NETWORK", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H", "status": "Unpatched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2024-36623" }, { "id": "CVE-2025-54388", "summary": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. In versions 28.2.0 through 28.3.2, when the firewalld service is reloaded it removes all iptables rules including those created by Docker. While Docker should automatically recreate these rules, versions before 28.3.3 fail to recreate the specific rules that block external access to containers. This means that after a firewalld reload, containers with ports published to localhost (like 127.0.0.1:8080) become accessible from remote machines that have network routing to the Docker bridge, even though they should only be accessible from the host itself. The vulnerability only affects explicitly published ports - unpublished ports remain protected. This issue is fixed in version 28.3.3.", "scorev2": "0.0", "scorev3": "4.6", "scorev4": "5.1", "vector": "ADJACENT_NETWORK", "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N", "status": "Patched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2025-54388" }, { "id": "CVE-2025-54410", "summary": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. A firewalld vulnerability affects Moby releases before 28.0.0. When firewalld reloads, Docker fails to re-create iptables rules that isolate bridge networks, allowing any container to access all ports on any other container across different bridge networks on the same host. This breaks network segmentation between containers that should be isolated, creating significant risk in multi-tenant environments. Only containers in --internal networks remain protected.\nWorkarounds include reloading firewalld and either restarting the docker daemon, re-creating bridge networks, or using rootless mode. Maintainers anticipate a fix for this issue in version 25.0.13.", "scorev2": "0.0", "scorev3": "3.3", "scorev4": "0.0", "vector": "LOCAL", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N", "status": "Unpatched", "link": "https://nvd.nist.gov/vuln/detail/CVE-2025-54410" } ] } ] }