CVE Hub

A specifically crafted Docker image running under the root user can overwrite the init helper binary of the container runtime and/or the command executor in Apache Mesos versions pre-1.4.x, 1.4.0 to 1.4.2, 1.5.0 to 1.5.2, 1.6.0 to 1.6.1, and 1.7.0 to 1.7.1. A malicious actor can therefore gain root-level code execution on the host.

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.

Docker Engine before 18.09 allows attackers to cause a denial of service (dockerd memory consumption) via a large integer in a --cpuset-mems or --cpuset-cpus value, related to daemon/daemon_unix.go, pkg/parsers/parsers.go, and pkg/sysinfo/sysinfo.go.

ajenticp (aka Ajenti Docker control panel) for Ajenti through v1.2.23.13 has XSS via a filename that is mishandled in File Manager.

Vulnerability in the Oracle WebLogic Server component of Oracle Fusion Middleware (subcomponent: Docker Images). The supported version that is affected is prior to Docker 12.2.1.3.20180913. Easily exploitable vulnerability allows unauthenticated attacker with network access via T3 to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle WebLogic Server accessible data. CVSS 3.0 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).

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.

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.

In Docker Skeleton Runtime for Apache OpenWhisk, a Docker action inheriting the Docker tag openwhisk/dockerskeleton:1.3.0 (or earlier) may allow an attacker to replace the user function inside the container if the user code is vulnerable to code exploitation.

In PHP Runtime for Apache OpenWhisk, a Docker action inheriting one of the Docker tags openwhisk/action-php-v7.2:1.0.0 or openwhisk/action-php-v7.1:1.0.1 (or earlier) may allow an attacker to replace the user function inside the container if the user code is vulnerable to code exploitation.

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.

Ubiquiti UCRM versions 2.3.0 to 2.7.7 allow an authenticated user to read arbitrary files in the local file system. Note that by default, the local file system is isolated in a docker container. Successful exploitation requires valid credentials to an account with "Edit" access to "System Customization".

Cloud Foundry Garden-runC, versions prior to 1.13.0, does not correctly enforce disc quotas for Docker image layers. A remote authenticated user may push an app with a malicious Docker image that will consume more space on a Diego cell than allocated in their quota, potentially causing a DoS against the cell.

hyperstart 1.0.0 in HyperHQ Hyper has memory leaks in the container_setup_modules and hyper_rescan_scsi functions in container.c, related to runV 1.0.0 for Docker.

In Docker Notary before 0.1, the checkRoot function in gotuf/client/client.go does not check expiry of root.json files, despite a comment stating that it does. Even if a user creates a new root.json file after a key compromise, an attacker can produce update files referring to an old root.json file.

In Docker Notary before 0.1, gotuf/signed/verify.go has a Signature Algorithm Not Matched to Key vulnerability. Because an attacker controls the field specifying the signature algorithm, they might (for example) be able to forge a signature by forcing a misinterpretation of an RSA-PSS key as Ed25519 elliptic-curve data.

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'.

boot2docker 1.2 and earlier allows attackers to conduct cross-site request forgery (CSRF) attacks by leveraging Docker daemons enabling TCP connections without TLS authentication.

The Docker daemon managed by boot2docker 1.2 and earlier improperly enables unauthenticated TCP connections by default, which makes it easier for remote attackers to gain privileges or execute arbitrary code from children containers.

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.

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.

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Joyent Smart Data Center prior to agentsshar@1.0.0-release-20160901-20160901T051624Z-g3fd5adf (e469cf49-4de3-4658-8419-ab42837916ad). An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the docker API. The process does not properly validate user-supplied data which can allow for the upload of arbitrary files. An attacker can leverage this vulnerability to execute arbitrary code under the context of root. Was ZDI-CAN-3853.

Docker before 1.5 allows local users to have unspecified impact via vectors involving unsafe /tmp usage.

Docker Commons Plugin provides a list of applicable credential IDs to allow users configuring a job to select the one they'd like to use to authenticate with a Docker Registry. This functionality did not check permissions, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those could be used as part of an attack to capture the credentials using another vulnerability.

Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint.

In Apache Hadoop 2.8.0, 3.0.0-alpha1, and 3.0.0-alpha2, the LinuxContainerExecutor runs docker commands as root with insufficient input validation. When the docker feature is enabled, authenticated users can run commands as root.

Cloud Foundry Garden-Linux versions prior to v0.333.0 and Elastic Runtime 1.6.x version prior to 1.6.17 contain a flaw in managing container files during Docker image preparation that could be used to delete, corrupt or overwrite host files and directories, including other container filesystems on the host.

mailcow 0.14, as used in "mailcow: dockerized" and other products, has CSRF.

NixOS 17.03 before 17.03.887 has a world-writable Docker socket, which allows local users to gain privileges by executing docker commands.

An issue was discovered in AppArmor before 2.12. Incorrect handling of unknown AppArmor profiles in AppArmor init scripts, upstart jobs, and/or systemd unit files allows an attacker to possibly have increased attack surfaces of processes that were intended to be confined by AppArmor. This is due to the common logic to handle 'restart' operations removing AppArmor profiles that aren't found in the typical filesystem locations, such as /etc/apparmor.d/. Userspace projects that manage their own AppArmor profiles in atypical directories, such as what's done by LXD and Docker, are affected by this flaw in the AppArmor init script logic.

IBM dashDB Local uses hard-coded credentials that could allow a remote attacker to gain access to the Docker container or database.

Directory traversal vulnerability in docker2aci before 0.13.0 allows remote attackers to write to arbitrary files via a .. (dot dot) in the embedded layer data in an image.

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.

A vulnerability in the Docker Engine configuration of Cisco CloudCenter Orchestrator (CCO; formerly CliQr) could allow an unauthenticated, remote attacker to install Docker containers with high privileges on the affected system. Affected Products: This vulnerability affect all releases of Cisco CloudCenter Orchestrator (CCO) deployments where the Docker Engine TCP port 2375 is open on the system and bound to local address 0.0.0.0 (any interface).

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.

docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain.

Red Hat OpenShift Enterprise 3.2 does not properly restrict access to STI builds, which allows remote authenticated users to access the Docker socket and gain privileges via vectors related to build-pod.

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.

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.

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.

Libcontainer 1.6.0, as used in Docker Engine, allows local users to escape containerization ("mount namespace breakout") and write to arbitrary file on the host system via a symlink attack in an image when respawning a container.

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.

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.

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."

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.

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.

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.

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.

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.