306 lines
43 KiB
Plaintext
306 lines
43 KiB
Plaintext
cve: ./data/2021/20xxx/CVE-2021-20439.json
|
||
IBM Security Access Manager 9.0 and IBM Security Verify Access Docker 10.0.0 stores user credentials in plain clear text which can be read by an unauthorized user.
|
||
|
||
analysis: {"Conatiner":"IBM Security Access Manager 9.0, IBM Security Verify Access Docker 10.0.0","CVE_Reason":"存储的用户凭据未加密，以明文形式保存","CVE_Consequence":"未经授权的用户可以读取这些凭据，可能导致账户被入侵或数据泄露，严重程度高"}
|
||
|
||
cve: ./data/2021/20xxx/CVE-2021-20500.json
|
||
IBM Security Verify Access Docker 10.0.0 could reveal highly sensitive information to a local privileged user. IBM X-Force ID: 197980.
|
||
|
||
analysis: {"Conatiner":"IBM Security Verify Access Docker 10.0.0","CVE_Reason":"高度敏感信息未妥善保护，可能被本地特权用户访问","CVE_Consequence":"可能导致敏感信息泄露，严重程度高"}
|
||
|
||
cve: ./data/2021/20xxx/CVE-2021-20511.json
|
||
IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to traverse directories on the system. An attacker could send a specially-crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system. IBM X-Force ID: 198300.
|
||
|
||
analysis: {"Conatiner":"IBM Security Verify Access Docker 10.0.0","CVE_Reason":"目录遍历漏洞，未对用户输入的路径进行严格校验","CVE_Consequence":"攻击者可以通过构造特殊URL访问系统上的任意文件，严重程度：高"}
|
||
|
||
cve: ./data/2021/20xxx/CVE-2021-20537.json
|
||
IBM Security Verify Access Docker 10.0.0 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. IBM X-Force ID:198918
|
||
|
||
analysis: {"Conatiner":"IBM Security Verify Access Docker 10.0.0","CVE_Reason":"硬编码的凭据，如密码或加密密钥","CVE_Consequence":"攻击者可能利用硬编码的凭据绕过安全机制，获取敏感信息或未经授权访问系统资源，严重程度高"}
|
||
|
||
cve: ./data/2021/21xxx/CVE-2021-21284.json
|
||
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/<remapping>" that cause writing files with extended privileges. Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user.
|
||
|
||
analysis: {"Conatiner":"Docker","CVE_Reason":"未正确处理--userns-remap选项导致容器内的root用户可以访问并修改宿主机文件系统下的敏感文件","CVE_Consequence":"攻击者可以通过此漏洞从容器内提升至宿主机的root权限，严重程度：高"}
|
||
|
||
cve: ./data/2021/21xxx/CVE-2021-21979.json
|
||
In Bitnami Containers, all Laravel container versions prior to: 6.20.0-debian-10-r107 for Laravel 6, 7.30.1-debian-10-r108 for Laravel 7 and 8.5.11-debian-10-r0 for Laravel 8, the file /tmp/app/.env is generated at the time that the docker image bitnami/laravel was built, and the value of APP_KEY is fixed under certain conditions. This value is crucial for the security of the application and must be randomly generated per Laravel installation. If your application's encryption key is in the hands of a malicious party, that party could craft cookie values using the encryption key and exploit vulnerabilities inherent to PHP object serialization / unserialization, such as calling arbitrary class methods within your application.
|
||
|
||
analysis: ```json
|
||
{"Conatiner":"bitnami/laravel","CVE_Reason":"容器构建过程中生成的/tmp/app/.env文件中，APP_KEY值在特定条件下固定，未随机生成","CVE_Consequence":"攻击者可能利用该密钥伪造cookie值，并通过PHP对象序列化/反序列化漏洞调用应用程序内的任意类方法，导致严重安全风险"}
|
||
```
|
||
|
||
cve: ./data/2021/31xxx/CVE-2021-31821.json
|
||
When the Windows Tentacle docker image starts up it logs all the commands that it runs along with the arguments, which writes the Octopus Server API key in plaintext. This does not affect the Linux Docker image
|
||
|
||
analysis: {"Conatiner":"Windows Tentacle docker image","CVE_Reason":"容器启动时记录了所有运行的命令及其参数，导致Octopus Server API密钥以明文形式泄露","CVE_Consequence":"可能导致API密钥被未授权访问，严重程度：高"}
|
||
|
||
cve: ./data/2021/37xxx/CVE-2021-37841.json
|
||
Docker Desktop before 3.6.0 suffers from incorrect access control. If a low-privileged account is able to access the server running the Windows containers, it can lead to a full container compromise in both process isolation and Hyper-V isolation modes. This security issue leads an attacker with low privilege to read, write and possibly even execute code inside the containers.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop Windows容器镜像","CVE_Reason":"错误的访问控制配置，导致低权限账户可访问容器服务器","CVE_Consequence":"可能导致容器完全被攻破，包括进程隔离和Hyper-V隔离模式，攻击者可读取、写入甚至执行容器内部代码，严重程度高"}
|
||
|
||
cve: ./data/2021/3xxx/CVE-2021-3602.json
|
||
An information disclosure flaw was found in Buildah, when building containers using chroot isolation. Running processes in container builds (e.g. Dockerfile RUN commands) can access environment variables from parent and grandparent processes. When run in a container in a CI/CD environment, environment variables may include sensitive information that was shared with the container in order to be used only by Buildah itself (e.g. container registry credentials).
|
||
|
||
analysis: {"Container":"Buildah","CVE_Reason":"容器构建过程中未妥善保护的环境变量","CVE_Consequence":"可能导致敏感信息（如容器镜像仓库凭据）泄露，严重程度较高"}
|
||
|
||
cve: ./data/2021/41xxx/CVE-2021-41092.json
|
||
Docker CLI is the command line interface for the docker container runtime. A bug was found in the Docker CLI where running `docker login my-private-registry.example.com` with a misconfigured configuration file (typically `~/.docker/config.json`) listing a `credsStore` or `credHelpers` that could not be executed would result in any provided credentials being sent to `registry-1.docker.io` rather than the intended private registry. This bug has been fixed in Docker CLI 20.10.9. Users should update to this version as soon as possible. For users unable to update ensure that any configured credsStore or credHelpers entries in the configuration file reference an installed credential helper that is executable and on the PATH.
|
||
|
||
analysis: {"Conatiner":"Docker CLI","CVE_Reason":"容器镜像构建过程中，由于Dockerfile或脚本未正确配置~/.docker/config.json文件，导致凭证存储或助手工具不可执行。","CVE_Consequence":"提供的凭据可能被错误发送到非目标的公共 registry（如 registry-1.docker.io），可能导致敏感信息泄露，严重程度为高。"}
|
||
|
||
cve: ./data/2021/45xxx/CVE-2021-45449.json
|
||
Docker Desktop version 4.3.0 and 4.3.1 has a bug that may log sensitive information (access token or password) on the user's machine during login. This only affects users if they are on Docker Desktop 4.3.0, 4.3.1 and the user has logged in while on 4.3.0, 4.3.1. Gaining access to this data would require having access to the user’s local files.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"登录过程中未妥善保护的访问令牌或密码","CVE_Consequence":"可能导致用户敏感信息泄露，严重程度为中等"}
|
||
|
||
cve: ./data/2022/23xxx/CVE-2022-23774.json
|
||
Docker Desktop before 4.4.4 on Windows allows attackers to move arbitrary files.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未对文件移动操作进行妥善限制","CVE_Consequence":"攻击者可以在Windows系统上任意移动文件，可能导致敏感信息泄露或系统破坏，严重程度高"}
|
||
|
||
cve: ./data/2022/25xxx/CVE-2022-25365.json
|
||
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.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未妥善修复的文件移动漏洞，允许攻击者移动任意文件","CVE_Consequence":"可能导致敏感文件泄露或系统文件被篡改，严重程度较高"}
|
||
|
||
cve: ./data/2022/26xxx/CVE-2022-26659.json
|
||
Docker Desktop installer on Windows in versions before 4.6.0 allows an attacker to overwrite any administrator writable files by creating a symlink in place of where the installer writes its log file. Starting from version 4.6.0, the Docker Desktop installer, when run elevated, will write its log files to a location not writable by non-administrator users.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop Windows 容器环境","CVE_Reason":"未正确处理日志文件写入路径，导致符号链接攻击漏洞","CVE_Consequence":"允许攻击者覆盖任何管理员可写的文件，可能导致系统文件破坏或恶意代码植入，严重程度高"}
|
||
|
||
cve: ./data/2022/27xxx/CVE-2022-27651.json
|
||
A flaw was found in buildah where containers were incorrectly started with non-empty default permissions. A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, enabling an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs. This has the potential to impact confidentiality and integrity.
|
||
|
||
analysis: {"Conatiner":"[Moby (Docker Engine)、Buildah构建的容器镜像]","CVE_Reason"："[容器启动时未正确设置默认权限及继承的Linux进程能力]","CVE_Consequence":"[可能导致攻击者提升权限，影响系统机密性和完整性，严重程度较高]"}
|
||
|
||
cve: ./data/2022/29xxx/CVE-2022-29186.json
|
||
Rundeck is an open source automation service with a web console, command line tools and a WebAPI. Rundeck community and rundeck-enterprise docker images contained a pre-generated SSH keypair. If the id_rsa.pub public key of the keypair was copied to authorized_keys files on remote host, those hosts would allow access to anyone with the exposed private credentials. This misconfiguration only impacts Rundeck Docker instances of PagerDuty® Process Automation On Prem (formerly Rundeck) version 4.0 and earlier, not Debian, RPM or .WAR. Additionally, the id_rsa.pub file would have to be copied from the Docker image filesystem contents without overwriting it and used to configure SSH access on a host. A patch on Rundeck's `main` branch has removed the pre-generated SSH key pair, but it does not remove exposed keys that have been configured. To patch, users must run a script on hosts in their environment to search for exposed keys and rotate them. Two workarounds are available: Do not use any pre-existing public key file from the rundeck docker images to allow SSH access by adding it to authorized_keys files and, if you have copied the public key file included in the docker image, remove it from any authorized_keys files.
|
||
|
||
analysis: {"Conatiner":"Rundeck社区版和Rundeck-Enterprise Docker镜像","CVE_Reason":"预生成的SSH密钥对未妥善保护","CVE_Consequence":"可能导致远程主机被未经授权的访问，严重程度为高"}
|
||
|
||
cve: ./data/2022/31xxx/CVE-2022-31647.json
|
||
Docker Desktop before 4.6.0 on Windows allows attackers to delete any file through the hyperv/destroy dockerBackendV2 API via a symlink in the DataFolder parameter, a different vulnerability than CVE-2022-26659.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未对DataFolder参数中的符号链接进行妥善处理，导致任意文件删除漏洞","CVE_Consequence":"攻击者可以通过该漏洞删除宿主系统上的任意文件，严重程度高"}
|
||
|
||
cve: ./data/2022/34xxx/CVE-2022-34292.json
|
||
Docker Desktop for Windows before 4.6.0 allows attackers to overwrite any file through a symlink attack on the hyperv/create dockerBackendV2 API by controlling the DataFolder parameter for DockerDesktop.vhdx, a similar issue to CVE-2022-31647.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop for Windows","CVE_Reason":"未妥善保护的符号链接文件","CVE_Consequence":"攻击者可以利用此漏洞覆盖任意文件，可能导致数据丢失或系统被入侵，严重程度较高"}
|
||
|
||
cve: ./data/2022/37xxx/CVE-2022-37326.json
|
||
Docker Desktop for Windows before 4.6.0 allows attackers to delete (or create) any file through the dockerBackendV2 windowscontainers/start API by controlling the pidfile field inside the DaemonJSON field in the WindowsContainerStartRequest class. This can indirectly lead to privilege escalation.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop for Windows","CVE_Reason":"未妥善验证API参数导致的任意文件删除或创建漏洞","CVE_Consequence":"可能导致特权提升，严重程度：高"}
|
||
|
||
cve: ./data/2022/38xxx/CVE-2022-38730.json
|
||
Docker Desktop for Windows before 4.6 allows attackers to overwrite any file through the windowscontainers/start dockerBackendV2 API by controlling the data-root field inside the DaemonJSON field in the WindowsContainerStartRequest class. This allows exploiting a symlink vulnerability in ..\dataRoot\network\files\local-kv.db because of a TOCTOU race condition.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop for Windows","CVE_Reason":"未妥善保护的文件、目录或API参数（data-root字段）","CVE_Consequence":"攻击者可以利用此漏洞覆盖任意文件，导致系统文件被篡改，严重程度高"}
|
||
|
||
cve: ./data/2022/39xxx/CVE-2022-39206.json
|
||
Onedev is an open source, self-hosted Git Server with CI/CD and Kanban. When using Docker-based job executors, the Docker socket (e.g. /var/run/docker.sock on Linux) is mounted into each Docker step. Users that can define and trigger CI/CD jobs on a project could use this to control the Docker daemon on the host machine. This is a known dangerous pattern, as it can be used to break out of Docker containers and, in most cases, gain root privileges on the host system. This issue allows regular (non-admin) users to potentially take over the build infrastructure of a OneDev instance. Attackers need to have an account (or be able to register one) and need permission to create a project. Since code.onedev.io has the right preconditions for this to be exploited by remote attackers, it could have been used to hijack builds of OneDev itself, e.g. by injecting malware into the docker images that are built and pushed to Docker Hub. The impact is increased by this as described before. Users are advised to upgrade to 7.3.0 or higher. There are no known workarounds for this issue.
|
||
|
||
analysis: {"Conatiner":"OneDev使用的Docker容器","CVE_Reason":"未妥善保护的Docker.sock文件","CVE_Consequence":"允许普通用户控制主机Docker守护进程，可能导致容器逃逸并获取主机root权限，严重程度高"}
|
||
|
||
cve: ./data/2022/43xxx/CVE-2022-43679.json
|
||
The Docker image of ownCloud Server through 10.11 contains a misconfiguration that renders the trusted_domains config useless. This could be abused to spoof the URL in password-reset e-mail messages.
|
||
|
||
analysis: {"Conatiner":"ownCloud Server 10.11及以下版本的Docker镜像","CVE_Reason":"容器中存在配置错误，导致trusted_domains配置失效","CVE_Consequence":"攻击者可利用此漏洞伪造密码重置邮件中的URL，可能导致用户账户被接管，严重程度为高"}
|
||
|
||
cve: ./data/2023/0xxx/CVE-2023-0633.json
|
||
In Docker Desktop on Windows before 4.12.0 an argument injection to installer may result in local privilege escalation (LPE).This issue affects Docker Desktop: before 4.12.0.
|
||
|
||
analysis: {"Container":"Docker Desktop","CVE_Reason":"安装程序参数注入漏洞","CVE_Consequence":"可能导致本地权限提升（LPE），严重程度：高"}
|
||
|
||
cve: ./data/2023/22xxx/CVE-2023-22495.json
|
||
Izanami is a shared configuration service well-suited for micro-service architecture implementation. Attackers can bypass the authentication in this application when deployed using the official Docker image. Because a hard coded secret is used to sign the authentication token (JWT), an attacker could compromise another instance of Izanami. This issue has been patched in version 1.11.0.
|
||
|
||
analysis: {"Conatiner":"Izanami官方Docker镜像","CVE_Reason":"硬编码的JWT签名密钥未妥善保护","CVE_Consequence":"攻击者可以绕过认证机制，获取未授权访问权限，严重程度高"}
|
||
|
||
cve: ./data/2023/22xxx/CVE-2023-22746.json
|
||
CKAN is an open-source DMS (data management system) for powering data hubs and data portals. When creating a new container based on one of the Docker images listed below, the same secret key was being used by default. If the users didn't set a custom value via environment variables in the `.env` file, that key was shared across different CKAN instances, making it easy to forge authentication requests. Users overriding the default secret key in their own `.env` file are not affected by this issue. Note that the legacy images (ckan/ckan) located in the main CKAN repo are not affected by this issue. The affected images are ckan/ckan-docker, (ckan/ckan-base images), okfn/docker-ckan (openknowledge/ckan-base and openknowledge/ckan-dev images)
|
||
keitaroinc/docker-ckan (keitaro/ckan images).
|
||
|
||
analysis: ```json
|
||
{"Conatiner":"ckan/ckan-docker, ckan/ckan-base, okfn/docker-ckan, openknowledge/ckan-base, openknowledge/ckan-dev, keitaroinc/docker-ckan, keitaro/ckan","CVE_Reason":"默认共享的密钥未被妥善替换","CVE_Consequence":"可能导致伪造认证请求，中等严重程度"}
|
||
```
|
||
|
||
cve: ./data/2023/27xxx/CVE-2023-27290.json
|
||
Docker based datastores for IBM Instana (IBM Observability with Instana 239-0 through 239-2, 241-0 through 241-2, and 243-0) do not currently require authentication. Due to this, an attacker within the network could access the datastores with read/write access. IBM X-Force ID: 248737.
|
||
|
||
analysis: {"Conatiner":"IBM Instana 数据存储容器镜像","CVE_Reason":"未设置身份验证的敏感数据存储","CVE_Consequence":"攻击者可获得数据存储的读写访问权限，可能导致数据泄露或篡改，严重程度高"}
|
||
|
||
cve: ./data/2023/31xxx/CVE-2023-31001.json
|
||
IBM Security Access Manager Container (IBM Security Verify Access Appliance 10.0.0.0 through 10.0.6.1 and IBM Security Verify Access Docker 10.0.6.1) temporarily stores sensitive information in files that could be accessed by a local user. IBM X-Force ID: 254653.
|
||
|
||
analysis: {"Conatiner":"IBM Security Access Manager Container","CVE_Reason":"临时存储在文件中的敏感信息","CVE_Consequence":"本地用户可能访问敏感信息，中等严重程度"}
|
||
|
||
cve: ./data/2023/32xxx/CVE-2023-32191.json
|
||
When RKE provisions a cluster, it stores the cluster state in a configmap called `full-cluster-state` inside the `kube-system` namespace of the cluster itself. The information available in there allows non-admin users to escalate to admin.
|
||
|
||
analysis: {"Conatiner":"RKE创建的Kubernetes集群镜像","CVE_Reason":"未妥善保护的配置信息（full-cluster-state configmap）","CVE_Consequence":"非管理员用户可利用该信息提升权限至管理员，高严重程度"}
|
||
|
||
cve: ./data/2023/32xxx/CVE-2023-32696.json
|
||
CKAN is an open-source data management system for powering data hubs and data portals. Prior to versions 2.9.9 and 2.10.1, the `ckan` user (equivalent to www-data) owned code and configuration files in the docker container and the `ckan` user had the permissions to use sudo. These issues allowed for code execution or privilege escalation if an arbitrary file write bug was available. Versions 2.9.9, 2.9.9-dev, 2.10.1, and 2.10.1-dev contain a patch.
|
||
|
||
analysis: {"Conatiner":"CKAN Docker容器镜像","CVE_Reason":"容器内的ckan用户对代码和配置文件拥有过高权限，并可使用sudo","CVE_Consequence":"可能导致代码执行或权限提升，严重程度：高"}
|
||
|
||
cve: ./data/2023/33xxx/CVE-2023-33979.json
|
||
gpt_academic provides a graphical interface for ChatGPT/GLM. A vulnerability was found in gpt_academic 3.37 and prior. This issue affects some unknown processing of the component Configuration File Handler. The manipulation of the argument file leads to information disclosure. Since no sensitive files are configured to be off-limits, sensitive information files in some working directories can be read through the `/file` route, leading to sensitive information leakage. This affects users that uses file configurations via `config.py`, `config_private.py`, `Dockerfile`. A patch is available at commit 1dcc2873d2168ad2d3d70afcb453ac1695fbdf02. As a workaround, one may use environment variables instead of `config*.py` files to configure this project, or use docker-compose installation to configure this project.
|
||
|
||
analysis: {"Conatiner":"gpt_academic","CVE_Reason":"未妥善保护的配置文件，允许通过`/file`路由访问敏感信息文件","CVE_Consequence":"可能导致敏感信息泄漏，严重程度为中到高"}
|
||
|
||
cve: ./data/2023/34xxx/CVE-2023-34844.json
|
||
Play With Docker < 0.0.2 has an insecure CAP_SYS_ADMIN privileged mode causing the docker container to escape.
|
||
|
||
analysis: {"Conatiner":"Play With Docker","CVE_Reason":"容器以CAP_SYS_ADMIN权限运行，可能导致容器逃逸","CVE_Consequence":"攻击者可能利用该漏洞完全控制宿主系统，严重程度：高"}
|
||
|
||
cve: ./data/2023/37xxx/CVE-2023-37273.json
|
||
Auto-GPT is an experimental open-source application showcasing the capabilities of the GPT-4 language model. Running Auto-GPT version prior to 0.4.3 by cloning the git repo and executing `docker compose run auto-gpt` in the repo root uses a different docker-compose.yml file from the one suggested in the official docker set up instructions. The docker-compose.yml file located in the repo root mounts itself into the docker container without write protection. This means that if malicious custom python code is executed via the `execute_python_file` and `execute_python_code` commands, it can overwrite the docker-compose.yml file and abuse it to gain control of the host system the next time Auto-GPT is started. The issue has been patched in version 0.4.3.
|
||
|
||
analysis: {"Conatiner":"Auto-GPT使用的Docker容器","CVE_Reason":"未受保护的docker-compose.yml文件被挂载进容器","CVE_Consequence":"恶意Python代码可覆盖docker-compose.yml，导致主机系统被控制，严重程度高"}
|
||
|
||
cve: ./data/2023/38xxx/CVE-2023-38369.json
|
||
IBM Security Access Manager Container 10.0.0.0 through 10.0.6.1 does not require that docker images should have strong passwords by default, which makes it easier for attackers to compromise user accounts. IBM X-Force ID: 261196.
|
||
|
||
analysis: {"Conatiner":"IBM Security Access Manager Container","CVE_Reason":"容器镜像默认未要求使用强密码","CVE_Consequence":"攻击者更容易入侵用户账户，严重程度较高"}
|
||
|
||
cve: ./data/2023/49xxx/CVE-2023-49103.json
|
||
An issue was discovered in ownCloud owncloud/graphapi 0.2.x before 0.2.1 and 0.3.x before 0.3.1. The graphapi app relies on a third-party GetPhpInfo.php library that provides a URL. When this URL is accessed, it reveals the configuration details of the PHP environment (phpinfo). This information includes all the environment variables of the webserver. In containerized deployments, these environment variables may include sensitive data such as the ownCloud admin password, mail server credentials, and license key. Simply disabling the graphapi app does not eliminate the vulnerability. Additionally, phpinfo exposes various other potentially sensitive configuration details that could be exploited by an attacker to gather information about the system. Therefore, even if ownCloud is not running in a containerized environment, this vulnerability should still be a cause for concern. Note that Docker containers from before February 2023 are not vulnerable to the credential disclosure.
|
||
|
||
analysis: {"Conatiner":"ownCloud相关的容器镜像","CVE_Reason":"未妥善保护的PHP环境配置信息（phpinfo）泄露，包含敏感数据如管理员密码、邮件服务器凭据和许可证密钥等环境变量","CVE_Consequence":"可能导致攻击者获取系统敏感信息，严重程度较高"}
|
||
|
||
cve: ./data/2023/5xxx/CVE-2023-5166.json
|
||
Docker Desktop before 4.23.0 allows Access Token theft via a crafted extension icon URL.
|
||
|
||
This issue affects Docker Desktop: before 4.23.0.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未妥善保护的访问令牌","CVE_Consequence":"攻击者可以通过构造的扩展图标URL窃取访问令牌，可能导致未经授权的访问和数据泄露，严重程度较高"}
|
||
|
||
cve: ./data/2024/21xxx/CVE-2024-21653.json
|
||
The vantage6 technology enables to manage and deploy privacy enhancing technologies like Federated Learning (FL) and Multi-Party Computation (MPC). Nodes and servers get a ssh config by default that permits root login with password authentication. In a proper deployment, the SSH service is not exposed so there is no risk, but not all deployments are ideal. The default should therefore be less permissive. The vulnerability can be mitigated by removing the ssh part from the docker file and rebuilding the docker image. Version 4.2.0 patches the vulnerability.
|
||
|
||
analysis: {"Conatiner":"vantage6","CVE_Reason":"容器镜像中的Dockerfile默认配置了允许root用户通过密码进行SSH登录的不安全配置","CVE_Consequence":"可能导致攻击者通过SSH服务非法获取容器控制权，严重程度较高"}
|
||
|
||
cve: ./data/2024/23xxx/CVE-2024-23651.json
|
||
BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. The issue has been fixed in v0.12.5. Workarounds include, avoiding using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.
|
||
|
||
analysis: {"Conatiner":"BuildKit构建的容器镜像","CVE_Reason":"共享缓存挂载的竞争条件导致主机文件被访问","CVE_Consequence":"可能导致容器内访问到主机系统的敏感文件，严重程度较高"}
|
||
|
||
cve: ./data/2024/23xxx/CVE-2024-23652.json
|
||
BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. 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. The issue has been fixed in v0.12.5. Workarounds include avoiding using BuildKit frontends from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature.
|
||
|
||
analysis: {"Conatiner":"BuildKit构建的容器镜像","CVE_Reason":"恶意Dockerfile使用RUN --mount导致主机系统上的文件被删除","CVE_Consequence":"可能导致主机文件系统受损，严重程度高"}
|
||
|
||
cve: ./data/2024/24xxx/CVE-2024-24557.json
|
||
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.
|
||
|
||
analysis: {"Conatiner":"[任何使用classic builder构建的容器镜像]","CVE_Reason"："[由于FROM scratch构建时缓存中毒，导致敏感信息或恶意内容被引入镜像中]"，"CVE_Consequence":"[攻击者可能通过缓存中毒篡改构建过程，引入恶意代码或配置，严重程度：高]"}
|
||
|
||
cve: ./data/2024/24xxx/CVE-2024-24756.json
|
||
Crafatar serves Minecraft avatars based on the skin for use in external applications. Files outside of the `lib/public/` directory can be requested from the server. Instances running behind Cloudflare (including crafatar.com) are not affected. Instances using the Docker container as shown in the README are affected, but only files within the container can be read. By default, all of the files within the container can also be found in this repository and are not confidential. This vulnerability is patched in 2.1.5.
|
||
|
||
analysis: {"Conatiner":"Crafatar Docker容器镜像","CVE_Reason":"未妥善保护的文件，允许访问容器内非`lib/public/`目录的文件","CVE_Consequence":"可能导致容器内文件泄露，虽然默认文件非机密，但若用户添加了敏感文件，则可能造成严重信息泄露"}
|
||
|
||
cve: ./data/2024/29xxx/CVE-2024-29967.json
|
||
In Brocade SANnav before Brocade SANnav v2.31 and v2.3.0a, it was observed that Docker instances inside the appliance have insecure mount points, allowing reading and writing access to sensitive files. The vulnerability could allow a sudo privileged user on the host OS to read and write access to these files.
|
||
|
||
analysis: {"Conatiner":"Brocade SANnav","CVE_Reason":"未妥善保护的文件","CVE_Consequence":"允许具有sudo权限的主机操作系统用户读取和写入敏感文件，中等严重程度"}
|
||
|
||
cve: ./data/2024/35xxx/CVE-2024-35137.json
|
||
IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could allow a local user to possibly elevate their privileges due to sensitive configuration information being exposed. IBM X-Force ID: 292413.
|
||
|
||
analysis: {"Conatiner":"IBM Security Access Manager Docker","CVE_Reason":"敏感配置信息暴露","CVE_Consequence":"可能允许本地用户提升权限，严重程度：高"}
|
||
|
||
cve: ./data/2024/35xxx/CVE-2024-35139.json
|
||
IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could allow a local user to obtain sensitive information from the container due to incorrect default permissions. IBM X-Force ID: 292415.
|
||
|
||
analysis: {"Conatiner":"IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1","CVE_Reason":"未妥善保护的敏感信息文件，由于默认权限设置错误导致泄漏","CVE_Consequence":"本地用户可能获取容器内敏感信息，中等严重程度"}
|
||
|
||
cve: ./data/2024/45xxx/CVE-2024-45497.json
|
||
A flaw was found in the OpenShift build process, where the docker-build container is configured with a hostPath volume mount that maps the node's /var/lib/kubelet/config.json file into the build pod. This file contains sensitive credentials necessary for pulling images from private repositories. The mount is not read-only, which allows the attacker to overwrite it. By modifying the config.json file, the attacker can cause a denial of service by preventing the node from pulling new images and potentially exfiltrating sensitive secrets. This flaw impacts the availability of services dependent on image pulls and exposes sensitive information to unauthorized parties.
|
||
|
||
analysis: {"Conatiner":"docker-build","CVE_Reason":"未妥善保护的文件，敏感的config.json文件被映射到容器中且非只读","CVE_Consequence":"可能导致服务不可用，严重程度高；同时敏感信息可能被泄露，严重程度高"}
|
||
|
||
cve: ./data/2024/47xxx/CVE-2024-47179.json
|
||
RSSHub is an RSS network. Prior to commit 64e00e7, RSSHub's `docker-test-cont.yml` workflow is vulnerable to Artifact Poisoning, which could have lead to a full repository takeover. Downstream users of RSSHub are not vulnerable to this issue, and commit 64e00e7 fixed the underlying issue and made the repository no longer vulnerable. The `docker-test-cont.yml` workflow gets triggered when the `PR - Docker build test` workflow completes successfully. It then collects some information about the Pull Request that triggered the triggering workflow and set some labels depending on the PR body and sender. If the PR also contains a `routes` markdown block, it will set the `TEST_CONTINUE` environment variable to `true`. The workflow then downloads and extracts an artifact uploaded by the triggering workflow which is expected to contain a single `rsshub.tar.zst` file. However, prior to commit 64e00e7, it did not validate and the contents were extracted in the root of the workspace overriding any existing files. Since the contents of the artifact were not validated, it is possible for a malicious actor to send a Pull Request which uploads, not just the `rsshub.tar.zst` compressed docker image, but also a malicious `package.json` file with a script to run arbitrary code in the context of the privileged workflow. As of commit 64e00e7, this scenario has been addressed and the RSSHub repository is no longer vulnerable.
|
||
|
||
analysis: {"Conatiner":"RSSHub的docker-test-cont.yml工作流容器","CVE_Reason":"未验证并提取压缩文件内容，导致恶意文件覆盖或注入","CVE_Consequence":"可能导致代码执行、仓库接管等严重后果，高危"}
|
||
|
||
cve: ./data/2024/55xxx/CVE-2024-55964.json
|
||
An issue was discovered in Appsmith before 1.52. An incorrectly configured PostgreSQL instance in the Appsmith image leads to remote command execution inside the Appsmith Docker container. The attacker must be able to access Appsmith, login to it, create a datasource, create a query against that datasource, and execute that query.
|
||
|
||
analysis: {"Conatiner":"Appsmith","CVE_Reason":"未正确配置的PostgreSQL实例","CVE_Consequence":"可能导致远程命令执行，严重程度：高"}
|
||
|
||
cve: ./data/2024/6xxx/CVE-2024-6222.json
|
||
In Docker Desktop before v4.29.0, an attacker who has gained access to the Docker Desktop VM through a container breakout can further escape to the host by passing extensions and dashboard related IPC messages.
|
||
|
||
Docker Desktop v4.29.0 https://docs.docker.com/desktop/release-notes/#4290 fixes the issue on MacOS, Linux and Windows with Hyper-V backend.
|
||
|
||
As exploitation requires "Allow only extensions distributed through the Docker Marketplace" to be disabled, Docker Desktop v4.31.0 https://docs.docker.com/desktop/release-notes/#4310 additionally changes the default configuration to enable this setting by default.
|
||
|
||
analysis: {"Conatiner":"Docker Desktop","CVE_Reason":"未妥善保护的IPC消息接口，允许容器逃逸至主机","CVE_Consequence":"攻击者可通过IPC消息逃逸到宿主机器，严重程度高"}
|
||
|
||
cve: ./data/2024/7xxx/CVE-2024-7387.json
|
||
A flaw was found in openshift/builder. This vulnerability allows command injection via path traversal, where a malicious user can execute arbitrary commands on the OpenShift node running the builder container. When using the “Docker” strategy, executable files inside the privileged build container can be overridden using the `spec.source.secrets.secret.destinationDir` attribute of the `BuildConfig` definition. An attacker running code in a privileged container could escalate their permissions on the node running the container.
|
||
|
||
analysis: {"Conatiner":"openshift/builder","CVE_Reason":"未对`spec.source.secrets.secret.destinationDir`属性的路径穿越进行妥善验证，导致可覆盖容器内可执行文件","CVE_Consequence":"攻击者可在特权容器中执行任意命令，进而提权至运行容器的OpenShift节点，严重程度高"}
|
||
|
||
cve: ./data/2024/7xxx/CVE-2024-7771.json
|
||
A vulnerability in the Dockerized version of mintplex-labs/anything-llm (latest, digest 1d9452da2b92) allows for a denial of service. Uploading an audio file with a very low sample rate causes the functionality responsible for transcribing it to crash the entire site instance. The issue arises from the localWhisper implementation, where resampling the audio file from 1 Hz to 16000 Hz quickly exceeds available memory, leading to the Docker instance being killed by the instance manager.
|
||
|
||
analysis: {"Conatiner":"mintplex-labs/anything-llm","CVE_Reason":"上传低采样率音频文件导致内存耗尽","CVE_Consequence":"可能导致容器实例被杀掉，造成拒绝服务（严重）"}
|
||
|
||
cve: ./data/2024/9xxx/CVE-2024-9407.json
|
||
A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files.
|
||
|
||
analysis: {"Conatiner":"[使用Dockerfile构建的容器镜像]","CVE_Reason"："[未正确验证bind-propagation选项的输入，导致任意参数传递至mount指令]","CVE_Consequence":"[攻击者可在构建过程中将主机敏感目录挂载至容器，并可能修改挂载文件内容，甚至绕过SELinux保护机制，严重程度：高]"}
|
||
|
||
cve: ./data/2025/27xxx/CVE-2025-27519.json
|
||
Cognita is a RAG (Retrieval Augmented Generation) Framework for building modular, open source applications for production by TrueFoundry. A path traversal issue exists at /v1/internal/upload-to-local-directory which is enabled when the Local env variable is set to true, such as when Cognita is setup using Docker. Because the docker environment sets up the backend uvicorn server with auto reload enabled, when an attacker overwrites the /app/backend/__init__.py file, the file will automatically be reloaded and executed. This allows an attacker to get remote code execution in the context of the Docker container. This vulnerability is fixed in commit a78bd065e05a1b30a53a3386cc02e08c317d2243.
|
||
|
||
analysis: {"Conatiner":"Cognita Docker镜像","CVE_Reason":"未对上传路径进行严格限制，导致路径遍历漏洞，允许攻击者覆盖关键文件","CVE_Consequence":"攻击者可利用此漏洞实现远程代码执行，严重程度：高"}
|
||
|
||
cve: ./data/2025/27xxx/CVE-2025-27615.json
|
||
umatiGateway is software for connecting OPC Unified Architecture servers with an MQTT broker utilizing JSON messages. The user interface may possibly be publicly accessible with umatiGateway's provided docker-compose file. With this access, the configuration can be viewed and altered. Commit 5d81a3412bc0051754a3095d89a06d6d743f2b16 uses `127.0.0.1:8080:8080` to limit access to the local network. For those who are unable to use this proposed patch, a firewall on Port 8080 may block remote access, but the workaround may not be perfect because Docker may also bypass a firewall by its iptable based rules for port forwarding.
|
||
|
||
analysis: {"Conatiner":"umatiGateway","CVE_Reason":"用户界面由于docker-compose文件配置不当而可能被公开访问，导致配置可被查看和修改","CVE_Consequence":"攻击者可能通过公开的用户界面访问并更改配置，可能导致敏感信息泄露或系统被篡改，严重程度较高"}
|
||
|
||
cve: ./data/2025/27xxx/CVE-2025-27650.json
|
||
Vasion Print (formerly PrinterLogic) before Virtual Appliance Host 22.0.862 Application 20.0.2014 allows Private Keys in Docker Overlay V-2023-013.
|
||
|
||
analysis: {"Conatiner":"Vasion Print Virtual Appliance Host","CVE_Reason":"未妥善保护的私钥文件","CVE_Consequence":"可能导致私钥泄露，严重程度高"}
|
||
|
||
cve: ./data/2025/32xxx/CVE-2025-32111.json
|
||
The Docker image from acme.sh before 40b6db6 is based on a .github/workflows/dockerhub.yml file that lacks "persist-credentials: false" for actions/checkout.
|
||
|
||
analysis: {"Conatiner":"acme.sh","CVE_Reason":"未设置persist-credentials: false，导致GitHub Actions中的actions/checkout可能泄露克隆仓库的凭据信息","CVE_Consequence":"可能导致容器构建过程中泄露仓库凭据，严重程度：高"}
|
||
|
||
cve: ./data/2025/32xxx/CVE-2025-32754.json
|
||
In jenkins/ssh-agent Docker images 6.11.1 and earlier, SSH host keys are generated on image creation for images based on Debian, causing all containers based on images of the same version use the same SSH host keys, allowing attackers able to insert themselves into the network path between the SSH client (typically the Jenkins controller) and SSH build agent to impersonate the latter.
|
||
|
||
analysis: {"Conatiner":"jenkins/ssh-agent","CVE_Reason":"容器镜像构建过程中生成的SSH主机密钥被多个容器共享","CVE_Consequence":"攻击者可以通过网络路径冒充SSH构建代理，严重程度：高"}
|
||
|
||
cve: ./data/2025/32xxx/CVE-2025-32755.json
|
||
In jenkins/ssh-slave Docker images based on Debian, SSH host keys are generated on image creation for images based on Debian, causing all containers based on images of the same version use the same SSH host keys, allowing attackers able to insert themselves into the network path between the SSH client (typically the Jenkins controller) and SSH build agent to impersonate the latter.
|
||
|
||
analysis: {"Conatiner":"jenkins/ssh-slave","CVE_Reason":"容器镜像构建过程中生成的SSH主机密钥被共享给所有基于同一镜像版本的容器","CVE_Consequence":"攻击者可以利用相同的SSH主机密钥进行中间人攻击，冒充SSH构建代理，严重程度为高"}
|
||
|
||
cve: ./data/2025/3xxx/CVE-2025-3047.json
|
||
When running the AWS Serverless Application Model Command Line Interface (SAM CLI) build process with Docker and symlinks are included in the build files, the container environment allows a user to access privileged files on the host by leveraging the elevated permissions granted to the tool. A user could leverage the elevated permissions to access restricted files via symlinks and copy them to a more permissive location on the container.
|
||
|
||
Users should upgrade to v1.133.0 or newer and ensure any forked or derivative code is patched to incorporate the new fixes.
|
||
|
||
analysis: {"Conatiner":"AWS SAM CLI构建的容器镜像","CVE_Reason":"通过符号链接访问主机上的特权文件","CVE_Consequence":"攻击者可以利用此漏洞访问受限文件，可能导致敏感信息泄露，严重程度为高"}
|
||
|
||
cve: ./data/2025/3xxx/CVE-2025-3048.json
|
||
After completing a build with AWS Serverless Application Model Command Line Interface (SAM CLI) which include symlinks, the content of those symlinks are copied to the cache of the local workspace as regular files or directories. As a result, a user who does not have access to those symlinks outside of the Docker container would now have access via the local workspace.
|
||
|
||
Users should upgrade to version 1.134.0 and ensure any forked or derivative code is patched to incorporate the new fixes. After upgrading, users must re-build their applications using the sam build --use-container to update the symlinks.
|
||
|
||
analysis: {"Conatiner":"AWS SAM CLI构建的容器镜像","CVE_Reason"："未妥善保护的符号链接内容","CVE_Consequence":"导致原本无权限访问符号链接内容的用户可以通过本地工作区访问这些内容，可能引发敏感信息泄露，严重程度为中高"}
|
||
|