Add some result scripts and results.
This commit is contained in:
sleepwithoutbz
84
DoS_ai_analysis.py
Normal file
84
DoS_ai_analysis.py
Normal file
@@ -0,0 +1,84 @@
|
||||
# 分析每个CVE源自哪个应用程序、什么原因、什么后果等信息
|
||||
|
||||
from os import truncate
|
||||
import re
|
||||
import json
|
||||
from openai import OpenAI
|
||||
from typing import Dict, List, Any
|
||||
|
||||
|
||||
def process_result(data: Any) -> str:
|
||||
# target_key = "choices.0.message.content"
|
||||
parts = ["choices", "0", "message", "content"]
|
||||
try:
|
||||
for part in parts:
|
||||
if isinstance(data, list):
|
||||
data = data[int(part)]
|
||||
else:
|
||||
data = data.get(part, None)
|
||||
if data is None:
|
||||
break
|
||||
return data
|
||||
except (KeyError, IndexError, TypeError):
|
||||
return "N/A"
|
||||
return "N/A"
|
||||
|
||||
|
||||
def analyze_with_ai(data: str) -> str:
|
||||
prompt = """
|
||||
你是一个计算机容器安全领域的专家，能够根据CVE描述分析出CVE产生于哪个程序、有何影响后果等信息。
|
||||
下面我会发给你一段文本，第一行是CVE的编号与文件位置信息，后续是这个CVE的详细描述。
|
||||
请分析我发送给你的CVE详细描述内容，并进行分析，我有如下要求：
|
||||
1. 分析这个CVE信息，判断这个CVE漏洞描述中是否提及会导致容器消耗更多宿主机的物理资源，例如CPU计算资源、内存资源或是硬盘空间资源，**注意**：不要自行推测，只分析这个描述中是否提及；
|
||||
2. 如果不满足条件1，你只需返回"N/A"即可，无需任何多余信息；
|
||||
3. 如果这个CVE满足条件1，那么你只需要直接返回一个json，这个json样例如下：
|
||||
{"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机CPU资源被大量占用]"，"CVE_Consequence":"[该CVE的后果，以及严重程度]"}
|
||||
请牢记，你必须只返回json内容，除了json不需要任何文本内容，并且尽量使用中文。
|
||||
"""
|
||||
|
||||
client = OpenAI(
|
||||
api_key="sk-5ec7751941974a9cb5855f746fe45a62",
|
||||
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
|
||||
)
|
||||
try:
|
||||
completion = client.chat.completions.create(
|
||||
# 模型列表：https://help.aliyun.com/zh/model-studio/getting-started/models
|
||||
model="qwen-plus",
|
||||
messages=[
|
||||
{"role": "system", "content": prompt},
|
||||
{"role": "user", "content": data},
|
||||
],
|
||||
# Qwen3模型通过enable_thinking参数控制思考过程（开源版默认True，商业版默认False）
|
||||
# 使用Qwen3开源版模型时，若未启用流式输出，请将下行取消注释，否则会报错
|
||||
# extra_body={"enable_thinking": False},
|
||||
)
|
||||
return process_result(json.loads(completion.model_dump_json()))
|
||||
except Exception as e:
|
||||
print(f"调用大模型失败: {str(e)}")
|
||||
return "N/A"
|
||||
return "N/A"
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
pattern = r"\./data/.*x/CVE.*?\.json"
|
||||
regex = re.compile(pattern)
|
||||
|
||||
with open("keyword_filter_11-25.log", "r", encoding="utf-8") as file:
|
||||
text = file.read()
|
||||
matches = list(regex.finditer(text))
|
||||
|
||||
log = open("./DoS_result/pure_from_description_11-25.log", "w", encoding="utf-8")
|
||||
|
||||
# 如果没有找到任何匹配项
|
||||
if not matches:
|
||||
print("No match found.")
|
||||
else:
|
||||
for i in range(len(matches)):
|
||||
start = matches[i].start()
|
||||
# 如果不是最后一个匹配项，则end是下一个匹配项的起始位置；否则为文本末尾
|
||||
end = matches[i + 1].start() if i + 1 < len(matches) else len(text)
|
||||
block = text[start:end].strip()
|
||||
ans = analyze_with_ai(block)
|
||||
if ans == "N/A":
|
||||
continue
|
||||
log.write(f"cve: {block}\n\nanalysis: {ans}\n\n")
|
||||
180
DoS_result/analysis_result_11-20.log
Normal file
180
DoS_result/analysis_result_11-20.log
Normal file
@@ -0,0 +1,180 @@
|
||||
cve: ./data/2011/1xxx/CVE-2011-1022.json
|
||||
The cgre_receive_netlink_msg function in daemon/cgrulesengd.c in cgrulesengd in the Control Group Configuration Library (aka libcgroup or libcg) before 0.37.1 does not verify that netlink messages originated in the kernel, which allows local users to bypass intended resource restrictions via a crafted message.
|
||||
|
||||
analysis: {"Conatiner":"[使用libcgroup或libcg的容器镜像]","CVE_Reason"："[容器内的用户可以通过构造的消息绕过资源限制，导致宿主机CPU、内存等资源被大量占用]","CVE_Consequence":"[该CVE允许本地用户绕过预期的资源限制，可能导致宿主机资源耗尽，严重程度为高]"}
|
||||
|
||||
cve: ./data/2011/2xxx/CVE-2011-2189.json
|
||||
net/core/net_namespace.c in the Linux kernel 2.6.32 and earlier does not properly handle a high rate of creation and cleanup of network namespaces, which makes it easier for remote attackers to cause a denial of service (memory consumption) via requests to a daemon that requires a separate namespace per connection, as demonstrated by vsftpd.
|
||||
|
||||
analysis: {"Container":"[使用Linux内核2.6.32及更早版本的容器镜像]","CVE_Reason":"[容器中的网络命名空间创建和清理速率过高，导致宿主机内存资源被大量消耗]","CVE_Consequence":"[该CVE可能导致宿主机内存耗尽，引发拒绝服务攻击，严重程度较高]"}
|
||||
|
||||
cve: ./data/2012/1xxx/CVE-2012-1146.json
|
||||
The mem_cgroup_usage_unregister_event function in mm/memcontrol.c in the Linux kernel before 3.2.10 does not properly handle multiple events that are attached to the same eventfd, which allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact by registering memory threshold events.
|
||||
|
||||
analysis: {"Conatiner":"[使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的进程可能通过注册内存阈值事件，导致宿主机CPU资源被大量占用以处理无效事件]","CVE_Consequence":"[该CVE可能导致宿主机系统崩溃或服务中断，严重程度为高]"}
|
||||
|
||||
cve: ./data/2012/2xxx/CVE-2012-2127.json
|
||||
fs/proc/root.c in the procfs implementation in the Linux kernel before 3.2 does not properly interact with CLONE_NEWPID clone system calls, which allows remote attackers to cause a denial of service (reference leak and memory consumption) by making many connections to a daemon that uses PID namespaces to isolate clients, as demonstrated by vsftpd.
|
||||
|
||||
analysis: {"Conatiner":"[使用PID命名空间隔离客户端的容器镜像，例如包含vsftpd的服务容器]","CVE_Reason"："[容器内的进程可以通过不当的PID命名空间交互导致宿主机内存资源被大量消耗]"，“CVE_Consequence”：“[该CVE会导致内存泄漏，严重程度较高，可能引发宿主机内存耗尽，进而导致系统不稳定或崩溃]”}
|
||||
|
||||
cve: ./data/2013/4xxx/CVE-2013-4205.json
|
||||
Memory leak in the unshare_userns function in kernel/user_namespace.c in the Linux kernel before 3.10.6 allows local users to cause a denial of service (memory consumption) via an invalid CLONE_NEWUSER unshare call.
|
||||
|
||||
analysis: {"Conatiner":"[使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的进程可以通过无效的CLONE_NEWUSER调用导致宿主机内存资源泄漏被大量占用]"，"CVE_Consequence":"[该CVE会导致宿主机内存耗尽，造成拒绝服务，严重程度为高]"}
|
||||
|
||||
cve: ./data/2014/1xxx/CVE-2014-1425.json
|
||||
cmanager 0.32 does not properly enforce nesting when modifying cgroup properties, which allows local users to set cgroup values for all cgroups via unspecified vectors.
|
||||
|
||||
analysis: {"Conatiner":"cmanager 0.32","CVE_Reason":"容器的运行可能导致宿主机CPU或内存资源被大量占用，因为cgroup属性未正确强制执行嵌套规则，允许本地用户设置所有cgroup的值。","CVE_Consequence":"该CVE可能允许攻击者通过操纵cgroup配置，绕过资源限制，导致宿主机资源耗尽，严重程度较高。"}
|
||||
|
||||
cve: ./data/2014/5xxx/CVE-2014-5207.json
|
||||
fs/namespace.c in the Linux kernel through 3.16.1 does not properly restrict clearing MNT_NODEV, MNT_NOSUID, and MNT_NOEXEC and changing MNT_ATIME_MASK during a remount of a bind mount, which allows local users to gain privileges, interfere with backups and auditing on systems that had atime enabled, or cause a denial of service (excessive filesystem updating) on systems that had atime disabled via a "mount -o remount" command within a user namespace.
|
||||
|
||||
analysis: {"Conatiner":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的用户可以通过特定的挂载操作，导致宿主机文件系统频繁更新，从而消耗大量CPU和硬盘资源]","CVE_Consequence":"[该CVE可能导致宿主机文件系统过度更新，引发性能下降或拒绝服务，严重程度较高]"}
|
||||
|
||||
cve: ./data/2014/7xxx/CVE-2014-7970.json
|
||||
The pivot_root implementation in fs/namespace.c in the Linux kernel through 3.17 does not properly interact with certain locations of a chroot directory, which allows local users to cause a denial of service (mount-tree loop) via . (dot) values in both arguments to the pivot_root system call.
|
||||
|
||||
analysis: {"Conatiner":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的恶意进程可能通过pivot_root系统调用创建挂载循环，导致宿主机CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致宿主机陷入无限递归的挂载操作，最终耗尽CPU资源，造成拒绝服务，严重程度高]"}
|
||||
|
||||
cve: ./data/2014/8xxx/CVE-2014-8171.json
|
||||
The memory resource controller (aka memcg) in the Linux kernel allows local users to cause a denial of service (deadlock) by spawning new processes within a memory-constrained cgroup.
|
||||
|
||||
analysis: {"Conatiner":"[任何使用受影响Linux内核的容器]","CVE_Reason"："[容器内的进程可以在内存受限的cgroup中不断创建新进程，导致宿主机内存资源被大量消耗并最终死锁]","CVE_Consequence":"[该CVE可能导致宿主机内存资源耗尽，引发系统死锁，严重程度高]"}
|
||||
|
||||
cve: ./data/2015/3xxx/CVE-2015-3629.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"Docker Engine（使用Libcontainer 1.6.0）","CVE_Reason":"容器内的用户可通过符号链接攻击逃逸到宿主机，并写入宿主机任意文件，可能间接导致资源消耗增加","CVE_Consequence":"该CVE允许本地用户通过容器逃逸漏洞破坏宿主机文件系统，可能导致严重安全问题，包括宿主机资源耗尽"}
|
||||
|
||||
cve: ./data/2015/3xxx/CVE-2015-3631.json
|
||||
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.
|
||||
|
||||
analysis: {"Conatiner":"Docker Engine","CVE_Reason":"容器内的用户可以通过覆盖 /proc 中的文件设置任意 Linux 安全模块（LSM）和 docker_t 策略，可能导致对宿主机资源的非预期控制或滥用，例如消耗大量 CPU 或内存资源","CVE_Consequence":"此 CVE 可能导致本地用户绕过安全限制，滥用宿主机资源，严重程度较高"}
|
||||
|
||||
cve: ./data/2016/6xxx/CVE-2016-6213.json
|
||||
fs/namespace.c in the Linux kernel before 4.9 does not restrict how many mounts may exist in a mount namespace, which allows local users to cause a denial of service (memory consumption and deadlock) via MS_BIND mount system calls, as demonstrated by a loop that triggers exponential growth in the number of mounts.
|
||||
|
||||
analysis: {"Container":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason":"[容器内的应用程序通过MS_BIND挂载调用，可能导致宿主机内存资源被大量消耗]","CVE_Consequence":"[该CVE会导致内存消耗过快，可能引发系统死锁，严重程度高]"}
|
||||
|
||||
cve: ./data/2016/8xxx/CVE-2016-8579.json
|
||||
docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain.
|
||||
|
||||
analysis: {"Conatiner":"docker2aci","CVE_Reason":"容器的运行会导致宿主机CPU资源被大量占用","CVE_Consequence":"由于存在无限循环，该CVE可能会导致宿主机CPU资源耗尽，严重程度较高"}
|
||||
|
||||
cve: ./data/2016/9xxx/CVE-2016-9191.json
|
||||
The cgroup offline implementation in the Linux kernel through 4.8.11 mishandles certain drain operations, which allows local users to cause a denial of service (system hang) by leveraging access to a container environment for executing a crafted application, as demonstrated by trinity.
|
||||
|
||||
analysis: {"Conatiner":"[任何使用cgroup的容器镜像]","CVE_Reason"："[容器的运行会触发cgroup offline实现中的漏洞，导致宿主机系统挂起，可能消耗大量CPU资源或阻塞核心进程调度]"，"CVE_Consequence":"[该CVE可能导致宿主机完全不可用，严重程度为高]"}
|
||||
|
||||
cve: ./data/2017/1000xxx/CVE-2017-1000111.json
|
||||
Linux kernel: heap out-of-bounds in AF_PACKET sockets. This new issue is analogous to previously disclosed CVE-2016-8655. In both cases, a socket option that changes socket state may race with safety checks in packet_set_ring. Previously with PACKET_VERSION. This time with PACKET_RESERVE. The solution is similar: lock the socket for the update. This issue may be exploitable, we did not investigate further. As this issue affects PF_PACKET sockets, it requires CAP_NET_RAW in the process namespace. But note that with user namespaces enabled, any process can create a namespace in which it has CAP_NET_RAW.
|
||||
|
||||
analysis: {"Conatiner":"[任何使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的进程可能通过触发AF_PACKET sockets的堆越界问题，导致宿主机CPU资源被大量占用以处理错误状态和竞争条件]"，"CVE_Consequence":"[该CVE可能导致宿主机系统崩溃或性能显著下降，严重程度较高]"}
|
||||
|
||||
cve: ./data/2017/11xxx/CVE-2017-11468.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"Docker Registry","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致远程攻击者通过manifest endpoint发送大量数据，造成宿主机内存耗尽，从而引发拒绝服务攻击，严重程度较高"}
|
||||
|
||||
cve: ./data/2017/14xxx/CVE-2017-14179.json
|
||||
Apport before 2.13 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion, possibly gain root privileges, or escape from containers.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason":"[容器的运行会导致宿主机CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致资源耗尽、拒绝服务攻击，严重程度为高]"}
|
||||
|
||||
cve: ./data/2017/14xxx/CVE-2017-14180.json
|
||||
Apport 2.13 through 2.20.7 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion or possibly gain root privileges, a different vulnerability than CVE-2017-14179.
|
||||
|
||||
analysis: {"Container":"[使用Apport 2.13至2.20.7版本的容器镜像]","CVE_Reason":"[容器内的进程可以通过PID命名空间滥用导致宿主机资源耗尽]","CVE_Consequence":"[该CVE可能导致宿主机资源（如CPU或内存）被大量占用，引发拒绝服务攻击，严重程度高]"}
|
||||
|
||||
cve: ./data/2017/14xxx/CVE-2017-14992.json
|
||||
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.
|
||||
|
||||
analysis: {"Conatiner":"Docker-CE (Moby)","CVE_Reason":"容器镜像层的解压过程中会消耗大量宿主机内存资源","CVE_Consequence":"该CVE可能导致宿主机内存资源耗尽，引发拒绝服务攻击，严重程度较高"}
|
||||
|
||||
cve: ./data/2018/10xxx/CVE-2018-10205.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"hyperhq/hyper","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE会导致内存泄漏，随着容器运行时间增加，宿主机可用内存逐渐减少，可能引发宿主机性能下降或系统不稳定，严重程度为高"}
|
||||
|
||||
cve: ./data/2018/14xxx/CVE-2018-14646.json
|
||||
The Linux kernel before 4.15-rc8 was found to be vulnerable to a NULL pointer dereference bug in the __netlink_ns_capable() function in the net/netlink/af_netlink.c file. A local attacker could exploit this when a net namespace with a netnsid is assigned to cause a kernel panic and a denial of service.
|
||||
|
||||
analysis: {"Conatiner":"[使用受影响Linux内核的容器镜像]","CVE_Reason"："[容器内的攻击者可以利用此漏洞触发内核崩溃，导致宿主机完全不可用，可能需要重启宿主机恢复]","CVE_Consequence":"[该CVE会导致宿主机内核崩溃，严重程度为高]"}
|
||||
|
||||
cve: ./data/2018/16xxx/CVE-2018-16884.json
|
||||
A flaw was found in the Linux kernel's NFS41+ subsystem. NFS41+ shares mounted in different network namespaces at the same time can make bc_svc_process() use wrong back-channel IDs and cause a use-after-free vulnerability. Thus a malicious container user can cause a host kernel memory corruption and a system panic. Due to the nature of the flaw, privilege escalation cannot be fully ruled out.
|
||||
|
||||
analysis: {"Container":"[任何使用NFS41+挂载的容器镜像]","CVE_Reason":"[容器内的恶意用户可以触发宿主机内核内存腐蚀，进而导致系统崩溃或潜在的权限提升]","CVE_Consequence":"[该CVE可能导致宿主机内核内存损坏、系统宕机，甚至可能的权限提升，严重程度高]"}
|
||||
|
||||
cve: ./data/2018/1xxx/CVE-2018-1277.json
|
||||
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.
|
||||
|
||||
analysis: {"Conatiner":"Cloud Foundry Garden-runC","CVE_Reason":"容器的运行会导致宿主机硬盘空间资源被大量占用","CVE_Consequence":"恶意Docker镜像会消耗超出配额的磁盘空间，可能导致Diego cell拒绝服务，严重程度较高"}
|
||||
|
||||
cve: ./data/2018/20xxx/CVE-2018-20699.json
|
||||
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.
|
||||
|
||||
analysis: {"Conatiner":"Docker Engine","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能使攻击者通过在 --cpuset-mems 或 --cpuset-cpus 参数中指定大整数值，导致 dockerd 进程内存消耗过大，最终造成拒绝服务。严重程度为高。"}
|
||||
|
||||
cve: ./data/2018/6xxx/CVE-2018-6552.json
|
||||
Apport does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion, possibly gain root privileges, or escape from containers. The is_same_ns() function returns True when /proc/<global pid>/ does not exist in order to indicate that the crash should be handled in the global namespace rather than inside of a container. However, the portion of the data/apport code that decides whether or not to forward a crash to a container does not always replace sys.argv[1] with the value stored in the host_pid variable when /proc/<global pid>/ does not exist which results in the container pid being used in the global namespace. This flaw affects versions 2.20.8-0ubuntu4 through 2.20.9-0ubuntu7, 2.20.7-0ubuntu3.7, 2.20.7-0ubuntu3.8, 2.20.1-0ubuntu2.15 through 2.20.1-0ubuntu2.17, and 2.14.1-0ubuntu3.28.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason":"[容器的运行会导致宿主机CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致资源耗尽，引发拒绝服务攻击，严重程度高]"}
|
||||
|
||||
cve: ./data/2018/7xxx/CVE-2018-7480.json
|
||||
The blkcg_init_queue function in block/blk-cgroup.c in the Linux kernel before 4.11 allows local users to cause a denial of service (double free) or possibly have unspecified other impact by triggering a creation failure.
|
||||
|
||||
analysis: {"Conatiner":"[任何使用受影响Linux内核版本的容器]","CVE_Reason"："[容器内的进程可能触发blkcg_init_queue函数中的双重释放漏洞，导致宿主机内核崩溃或不稳定，进而可能消耗更多CPU资源来处理错误状态或重启服务]","CVE_Consequence":"[该CVE可能导致宿主机拒绝服务，严重程度较高]"}
|
||||
|
||||
cve: ./data/2019/10xxx/CVE-2019-10147.json
|
||||
rkt through version 1.30.0 does not isolate processes in containers that are run with `rkt enter`. Processes run with `rkt enter` are not limited by cgroups during stage 2 (the actual environment in which the applications run). Compromised containers could exploit this flaw to access host resources.
|
||||
|
||||
analysis: {"Container":"rkt","CVE_Reason":"容器中的进程在使用`rkt enter`运行时未受cgroups限制，可能导致宿主机资源被过度消耗，包括CPU和内存资源。","CVE_Consequence":"攻击者可以利用此漏洞访问宿主机资源，可能导致宿主机资源耗尽，影响宿主机及其他容器的稳定性，严重程度较高。"}
|
||||
|
||||
cve: ./data/2019/12xxx/CVE-2019-12675.json
|
||||
Multiple vulnerabilities in the multi-instance feature of Cisco Firepower Threat Defense (FTD) Software could allow an authenticated, local attacker to escape the container for their FTD instance and execute commands with root privileges in the host namespace. These vulnerabilities are due to insufficient protections on the underlying filesystem. An attacker could exploit these vulnerabilities by modifying critical files on the underlying filesystem. A successful exploit could allow the attacker to execute commands with root privileges within the host namespace. This could allow the attacker to impact other running FTD instances.
|
||||
|
||||
analysis: {"Conatiner":"Cisco Firepower Threat Defense (FTD) Software","CVE_Reason":"容器逃逸后，攻击者可以在宿主机命名空间内执行命令，可能导致宿主机资源被滥用，例如占用大量CPU或内存资源","CVE_Consequence":"该CVE允许攻击者影响其他正在运行的FTD实例，可能完全控制宿主机，严重程度高"}
|
||||
|
||||
cve: ./data/2019/16xxx/CVE-2019-16884.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"[使用runc作为运行时的容器镜像]","CVE_Reason":"[容器内的恶意镜像可以绕过AppArmor限制，通过挂载覆盖宿主机的/proc目录，可能导致对宿主机资源的非授权访问和滥用，例如消耗大量CPU或内存资源]","CVE_Consequence":"[该CVE可能允许攻击者滥用宿主机资源，造成拒绝服务或其他安全风险，严重程度为高]"}
|
||||
|
||||
cve: ./data/2019/20xxx/CVE-2019-20794.json
|
||||
An issue was discovered in the Linux kernel 4.18 through 5.6.11 when unprivileged user namespaces are allowed. A user can create their own PID namespace, and mount a FUSE filesystem. Upon interaction with this FUSE filesystem, if the userspace component is terminated via a kill of the PID namespace's pid 1, it will result in a hung task, and resources being permanently locked up until system reboot. This can result in resource exhaustion.
|
||||
|
||||
analysis: {"Conatiner":"[使用Linux内核4.18至5.6.11的容器环境]","CVE_Reason"："[容器内的用户可以通过创建PID命名空间和挂载FUSE文件系统，导致宿主机任务挂起和资源被永久锁定]","CVE_Consequence":"[该CVE可能导致宿主机资源耗尽，严重程度较高]"}
|
||||
|
||||
cve: ./data/2019/3xxx/CVE-2019-3874.json
|
||||
The SCTP socket buffer used by a userspace application is not accounted by the cgroups subsystem. An attacker can use this flaw to cause a denial of service attack. Kernel 3.10.x and 4.18.x branches are believed to be vulnerable.
|
||||
|
||||
analysis: {"Conatiner":"[任何使用SCTP协议的容器镜像]","CVE_Reason"："[容器中的用户空间应用程序可以绕过cgroups限制，导致宿主机内存资源被大量占用]","CVE_Consequence":"[该CVE可能导致攻击者通过SCTP套接字缓冲区消耗大量宿主机内存资源，最终引发拒绝服务（严重）]"}
|
||||
|
||||
cve: ./data/2020/14xxx/CVE-2020-14298.json
|
||||
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.
|
||||
|
||||
analysis: {"Conatiner":"[受影响的容器镜像，例如使用docker 1.13.1-108.git4ef4b30.el7的容器]","CVE_Reason"："[恶意容器可能利用该漏洞逃逸并直接访问宿主机资源，进而导致宿主机CPU、内存或硬盘资源被大量占用]","CVE_Consequence":"[攻击者可以完全控制宿主机系统，影响其上运行的所有容器，严重程度为高危]"}
|
||||
|
||||
cve: ./data/2020/24xxx/CVE-2020-24263.json
|
||||
Portainer 1.24.1 and earlier is affected by an insecure permissions vulnerability that may lead to remote arbitrary code execution. A non-admin user is allowed to spawn new containers with critical capabilities such as SYS_MODULE, which can be used to take over the Docker host.
|
||||
|
||||
analysis: {"Conatiner":"Portainer","CVE_Reason":"非管理员用户可以创建具有关键权限的新容器（如SYS_MODULE），这些权限可能导致宿主机资源被大量消耗，例如CPU和内存资源","CVE_Consequence":"该CVE允许攻击者通过非管理员权限执行任意代码并控制Docker宿主机，严重程度为高"}
|
||||
|
||||
cve: ./data/2020/24xxx/CVE-2020-24264.json
|
||||
Portainer 1.24.1 and earlier is affected by incorrect access control that may lead to remote arbitrary code execution. The restriction checks for bind mounts are applied only on the client-side and not the server-side, which can lead to spawning a container with bind mount. Once such a container is spawned, it can be leveraged to break out of the container leading to complete Docker host machine takeover.
|
||||
|
||||
analysis: {"Container":"Portainer","CVE_Reason":"容器的运行可能导致宿主机的文件系统被绑定挂载，攻击者可利用此漏洞突破容器限制，进而完全控制Docker宿主机，可能消耗大量CPU和内存资源","CVE_Consequence":"该CVE可能导致容器逃逸，从而使攻击者完全控制宿主机，严重程度为高危"}
|
||||
|
||||
cve: ./data/2020/25xxx/CVE-2020-25220.json
|
||||
The Linux kernel 4.9.x before 4.9.233, 4.14.x before 4.14.194, and 4.19.x before 4.19.140 has a use-after-free because skcd->no_refcnt was not considered during a backport of a CVE-2020-14356 patch. This is related to the cgroups feature.
|
||||
|
||||
analysis: {"Conatiner":"[使用受影响Linux内核版本的容器镜像]","CVE_Reason"："[由于use-after-free漏洞，攻击者可能触发异常情况，导致容器过度消耗宿主机CPU资源]","CVE_Consequence":"[该CVE可能导致宿主机系统性能下降甚至拒绝服务，严重程度为高]"}
|
||||
|
||||
cve: ./data/2020/36xxx/CVE-2020-36694.json
|
||||
An issue was discovered in netfilter in the Linux kernel before 5.10. There can be a use-after-free in the packet processing context, because the per-CPU sequence count is mishandled during concurrent iptables rules replacement. This could be exploited with the CAP_NET_ADMIN capability in an unprivileged namespace. NOTE: cc00bca was reverted in 5.12.
|
||||
|
||||
analysis: {"Container":"[使用Linux内核5.10以下版本的容器镜像]","CVE_Reason":"[容器中的进程可能利用此漏洞触发use-after-free问题，进而导致CPU资源被大量占用]","CVE_Consequence":"[该CVE可能导致宿主机的CPU资源耗尽，严重程度为高]"}
|
||||
|
||||
1593
DoS_result/analysis_result_21-25.log
Normal file
1593
DoS_result/analysis_result_21-25.log
Normal file
File diff suppressed because it is too large
Load Diff
75
DoS_result/pure_from_description_11-25.log
Normal file
75
DoS_result/pure_from_description_11-25.log
Normal file
@@ -0,0 +1,75 @@
|
||||
cve: ./data/2011/2xxx/CVE-2011-2189.json
|
||||
net/core/net_namespace.c in the Linux kernel 2.6.32 and earlier does not properly handle a high rate of creation and cleanup of network namespaces, which makes it easier for remote attackers to cause a denial of service (memory consumption) via requests to a daemon that requires a separate namespace per connection, as demonstrated by vsftpd.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用]"，"CVE_Consequence":"[该CVE可能导致拒绝服务攻击，严重程度较高]"}
|
||||
|
||||
cve: ./data/2012/2xxx/CVE-2012-2127.json
|
||||
fs/proc/root.c in the procfs implementation in the Linux kernel before 3.2 does not properly interact with CLONE_NEWPID clone system calls, which allows remote attackers to cause a denial of service (reference leak and memory consumption) by making many connections to a daemon that uses PID namespaces to isolate clients, as demonstrated by vsftpd.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用]"，"CVE_Consequence":"[该CVE可能导致内存消耗过大，进而引发拒绝服务攻击，严重程度较高]"}
|
||||
|
||||
cve: ./data/2013/4xxx/CVE-2013-4205.json
|
||||
Memory leak in the unshare_userns function in kernel/user_namespace.c in the Linux kernel before 3.10.6 allows local users to cause a denial of service (memory consumption) via an invalid CLONE_NEWUSER unshare call.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用]","CVE_Consequence":"[该CVE可能导致内存泄漏，进而造成拒绝服务攻击，严重程度较高]"}
|
||||
|
||||
cve: ./data/2014/5xxx/CVE-2014-5207.json
|
||||
fs/namespace.c in the Linux kernel through 3.16.1 does not properly restrict clearing MNT_NODEV, MNT_NOSUID, and MNT_NOEXEC and changing MNT_ATIME_MASK during a remount of a bind mount, which allows local users to gain privileges, interfere with backups and auditing on systems that had atime enabled, or cause a denial of service (excessive filesystem updating) on systems that had atime disabled via a "mount -o remount" command within a user namespace.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行可能会导致宿主机文件系统更新操作过多，从而消耗大量CPU或硬盘资源]","CVE_Consequence":"[该CVE可能导致本地用户通过特定命令引发拒绝服务攻击，严重程度较高]"}
|
||||
|
||||
cve: ./data/2014/8xxx/CVE-2014-8171.json
|
||||
The memory resource controller (aka memcg) in the Linux kernel allows local users to cause a denial of service (deadlock) by spawning new processes within a memory-constrained cgroup.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致拒绝服务（死锁），严重程度较高"}
|
||||
|
||||
cve: ./data/2016/6xxx/CVE-2016-6213.json
|
||||
fs/namespace.c in the Linux kernel before 4.9 does not restrict how many mounts may exist in a mount namespace, which allows local users to cause a denial of service (memory consumption and deadlock) via MS_BIND mount system calls, as demonstrated by a loop that triggers exponential growth in the number of mounts.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机内存资源被大量占用，并可能引发死锁]"，"CVE_Consequence":"[该CVE可能导致宿主机内存耗尽及系统死锁，严重程度高]"}
|
||||
|
||||
cve: ./data/2016/8xxx/CVE-2016-8579.json
|
||||
docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain.
|
||||
|
||||
analysis: {"Container":"docker2aci","CVE_Reason":"容器的运行会导致宿主机CPU资源被大量占用","CVE_Consequence":"该CVE可能导致系统性能下降，严重程度为高"}
|
||||
|
||||
cve: ./data/2016/9xxx/CVE-2016-9191.json
|
||||
The cgroup offline implementation in the Linux kernel through 4.8.11 mishandles certain drain operations, which allows local users to cause a denial of service (system hang) by leveraging access to a container environment for executing a crafted application, as demonstrated by trinity.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机系统挂起，可能是由于CPU或其它资源被大量占用]","CVE_Consequence":"[该CVE可能导致系统拒绝服务（系统挂起），严重程度较高]"}
|
||||
|
||||
cve: ./data/2017/11xxx/CVE-2017-11468.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"Docker Registry","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致远程攻击者通过manifest endpoint造成拒绝服务，严重程度较高"}
|
||||
|
||||
cve: ./data/2017/14xxx/CVE-2017-14179.json
|
||||
Apport before 2.13 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion, possibly gain root privileges, or escape from containers.
|
||||
|
||||
analysis: {"Container":"[存在CVE的容器镜像]","CVE_Reason"："[容器的运行会导致宿主机资源被大量占用，具体为资源耗尽问题]","CVE_Consequence":"[该CVE可能导致拒绝服务攻击，资源耗尽，甚至获得root权限或逃逸容器，严重程度较高]"}
|
||||
|
||||
cve: ./data/2017/14xxx/CVE-2017-14180.json
|
||||
Apport 2.13 through 2.20.7 does not properly handle crashes originating from a PID namespace allowing local users to create certain files as root which an attacker could leverage to perform a denial of service via resource exhaustion or possibly gain root privileges, a different vulnerability than CVE-2017-14179.
|
||||
|
||||
analysis: {"Container":"Apport","CVE_Reason":"容器的运行会导致宿主机内存资源或CPU资源被大量占用，造成资源耗尽问题","CVE_Consequence":"该CVE可能导致拒绝服务攻击，严重程度较高，还可能带来提权风险"}
|
||||
|
||||
cve: ./data/2017/14xxx/CVE-2017-14992.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"Docker-CE (Moby)","CVE_Reason":"容器的运行会导致宿主机CPU资源和内存资源被大量占用","CVE_Consequence":"该CVE可能导致拒绝服务（DoS），严重程度较高"}
|
||||
|
||||
cve: ./data/2018/10xxx/CVE-2018-10205.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"hyperstart 1.0.0","CVE_Reason":"容器的运行会导致宿主机内存资源被泄漏","CVE_Consequence":"内存泄漏会逐渐消耗宿主机的内存资源，可能导致系统性能下降或崩溃，严重程度较高"}
|
||||
|
||||
cve: ./data/2018/1xxx/CVE-2018-1277.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"Cloud Foundry Garden-runC","CVE_Reason":"容器的运行会导致宿主机硬盘空间资源被大量占用","CVE_Consequence":"恶意Docker镜像会消耗超出配额的磁盘空间，可能导致Diego cell拒绝服务（DoS），严重程度较高"}
|
||||
|
||||
cve: ./data/2018/20xxx/CVE-2018-20699.json
|
||||
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.
|
||||
|
||||
analysis: {"Container":"Docker Engine","CVE_Reason":"容器的运行会导致宿主机内存资源被大量占用","CVE_Consequence":"该CVE可能导致宿主机内存消耗过多，从而引发拒绝服务攻击，严重程度较高"}
|
||||
|
||||
84
Image_ai_analysis.py
Normal file
84
Image_ai_analysis.py
Normal file
@@ -0,0 +1,84 @@
|
||||
# 分析每个CVE源自哪个应用程序、什么原因、什么后果等信息
|
||||
|
||||
from os import truncate
|
||||
import re
|
||||
import json
|
||||
from openai import OpenAI
|
||||
from typing import Dict, List, Any
|
||||
|
||||
|
||||
def process_result(data: Any) -> str:
|
||||
# target_key = "choices.0.message.content"
|
||||
parts = ["choices", "0", "message", "content"]
|
||||
try:
|
||||
for part in parts:
|
||||
if isinstance(data, list):
|
||||
data = data[int(part)]
|
||||
else:
|
||||
data = data.get(part, None)
|
||||
if data is None:
|
||||
break
|
||||
return data
|
||||
except (KeyError, IndexError, TypeError):
|
||||
return "N/A"
|
||||
return "N/A"
|
||||
|
||||
|
||||
def analyze_with_ai(data: str) -> str:
|
||||
prompt = """
|
||||
你是一个计算机容器安全领域的专家，能够根据CVE描述分析出CVE产生于哪个程序、有何影响后果等信息。
|
||||
下面用户会发给你一段文本，第一行是CVE的编号与文件位置信息，后续是这个CVE的详细描述。
|
||||
请分析用户发送给你的CVE详细描述内容，并进行分析，有如下要求：
|
||||
1. 分析这个CVE信息，判断这个CVE漏洞是否是容器镜像而引入的问题，而非Docker实现、Kernel实现中的问题。比如由于容器镜像创建中对文件或环境变量处理不当而引入的CVE就是用户感兴趣的；
|
||||
2. 如果不满足条件1，你只需返回"N/A"即可，无需任何任何多余信息；
|
||||
3. 如果这个CVE满足条件1，那么你只需要直接返回一个json，这个json样例如下：
|
||||
{"Image":"[引入CVE的容器镜像名称]","Reason"："[容器的运行会导致宿主机CPU资源被大量占用]"，"Consequence":"[该CVE的后果，以及严重程度]"}
|
||||
请牢记，不要自行推测，只分析这个描述中是否提及。
|
||||
"""
|
||||
|
||||
client = OpenAI(
|
||||
api_key="sk-5ec7751941974a9cb5855f746fe45a62",
|
||||
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
|
||||
)
|
||||
try:
|
||||
completion = client.chat.completions.create(
|
||||
# 模型列表：https://help.aliyun.com/zh/model-studio/getting-started/models
|
||||
model="qwen-plus",
|
||||
messages=[
|
||||
{"role": "system", "content": prompt},
|
||||
{"role": "user", "content": data},
|
||||
],
|
||||
# Qwen3模型通过enable_thinking参数控制思考过程（开源版默认True，商业版默认False）
|
||||
# 使用Qwen3开源版模型时，若未启用流式输出，请将下行取消注释，否则会报错
|
||||
# extra_body={"enable_thinking": False},
|
||||
)
|
||||
return process_result(json.loads(completion.model_dump_json()))
|
||||
except Exception as e:
|
||||
print(f"调用大模型失败: {str(e)}")
|
||||
return "N/A"
|
||||
return "N/A"
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
pattern = r"\./data/.*x/CVE.*?\.json"
|
||||
regex = re.compile(pattern)
|
||||
|
||||
with open("keyword_filter_11-25.log", "r", encoding="utf-8") as file:
|
||||
text = file.read()
|
||||
matches = list(regex.finditer(text))
|
||||
|
||||
log = open("./Image_result/result_11-25.log", "w", encoding="utf-8")
|
||||
|
||||
# 如果没有找到任何匹配项
|
||||
if not matches:
|
||||
print("No match found.")
|
||||
else:
|
||||
for i in range(len(matches)):
|
||||
start = matches[i].start()
|
||||
# 如果不是最后一个匹配项，则end是下一个匹配项的起始位置；否则为文本末尾
|
||||
end = matches[i + 1].start() if i + 1 < len(matches) else len(text)
|
||||
block = text[start:end].strip()
|
||||
ans = analyze_with_ai(block)
|
||||
if ans == "N/A":
|
||||
continue
|
||||
log.write(f"cve: {block}\n\nanalysis: {ans}\n\n")
|
||||
708
Image_result/result_11-25.log
Normal file
708
Image_result/result_11-25.log
Normal file
@@ -0,0 +1,708 @@
|
||||
cve: ./data/2014/0xxx/CVE-2014-0048.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"docker","Reason":"容器镜像通过HTTP下载并执行程序或脚本的方式存在安全隐患","Consequence":"攻击者可利用中间人攻击篡改下载内容，导致代码执行或安全机制失效，严重程度高"}
|
||||
|
||||
cve: ./data/2014/5xxx/CVE-2014-5282.json
|
||||
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'.
|
||||
|
||||
analysis: {"Image":"Docker","Reason":"CVE is related to Docker's image ID validation issue when loading images","Consequence":"Remote attackers can redirect the loading process to another untrusted image, leading to potential security risks. Severity: Medium to High"}
|
||||
|
||||
cve: ./data/2014/6xxx/CVE-2014-6407.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker","Reason":"漏洞是由于Docker在处理镜像归档文件时对符号链接或硬链接的不安全解压方式导致的","Consequence":"攻击者可以利用该漏洞在宿主机上写入任意文件并执行任意代码，严重影响容器环境的安全性"}
|
||||
|
||||
cve: ./data/2014/8xxx/CVE-2014-8178.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker Engine","Reason":"The vulnerability arises from the image layer storage mechanism in the Docker Engine, which does not use a globally unique identifier, allowing attackers to manipulate the image cache.","Consequence":"Attackers can exploit this vulnerability to poison the image cache during pull or push operations, potentially leading to system compromise or distribution of malicious images. This issue poses a moderate to high risk depending on the environment and usage."}
|
||||
|
||||
cve: ./data/2014/9xxx/CVE-2014-9356.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker image","Reason":"The CVE is introduced through the container image by including a malicious symlink with a full pathname in the Dockerfile or build process.","Consequence":"Remote attackers can exploit this vulnerability to write to arbitrary files on the host system, bypassing container protection mechanisms. This leads to potential system compromise and has a high severity impact."}
|
||||
|
||||
cve: ./data/2014/9xxx/CVE-2014-9357.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker","Reason":"CVE-2014-9357 是由于在 Docker 镜像或 Dockerfile 构建过程中对 LZMA (.xz) 压缩包的解压处理不当导致的问题，属于容器镜像处理环节引入的漏洞","Consequence":"远程攻击者可以通过构造恶意镜像或 Dockerfile 执行任意代码并以 root 权限运行，危害极大，可能导致宿主机被完全控制"}
|
||||
|
||||
cve: ./data/2014/9xxx/CVE-2014-9358.json
|
||||
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."
|
||||
|
||||
analysis: {"Image":"Docker","Reason":"CVE描述指出该漏洞是由于Docker在镜像加载或仓库通信过程中未正确验证镜像ID，从而导致攻击者可以伪造镜像进行路径穿越攻击。这属于容器镜像处理引入的问题","Consequence":"远程攻击者可以通过构造恶意镜像执行路径穿越攻击并伪造仓库，可能导致敏感数据泄露或系统被进一步攻击，严重程度较高"}
|
||||
|
||||
cve: ./data/2015/1xxx/CVE-2015-1318.json
|
||||
The crash reporting feature in Apport 2.13 through 2.17.x before 2.17.1 allows local users to gain privileges via a crafted usr/share/apport/apport file in a namespace (container).
|
||||
|
||||
analysis: {"Image":"Apport","Reason":"The vulnerability is introduced through a container with a crafted usr/share/apport/apport file.","Consequence":"Local users can gain privileges, leading to a high severity security issue."}
|
||||
|
||||
cve: ./data/2015/3xxx/CVE-2015-3627.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker Engine","Reason":"漏洞由于容器镜像创建过程中文件描述符和chroot处理不当导致，攻击者可通过恶意构造的镜像利用符号链接攻击提权","Consequence":"本地用户可获得更高权限，可能导致系统被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2015/3xxx/CVE-2015-3629.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Libcontainer","Reason":"漏洞由于容器镜像中存在可被本地用户利用的符号链接攻击，导致可以逃离容器并写入宿主机任意文件","Consequence":"该CVE允许攻击者突破容器隔离环境，对宿主机系统造成影响，具有较高严重性"}
|
||||
|
||||
cve: ./data/2015/3xxx/CVE-2015-3631.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker Engine","Reason":"The vulnerability is introduced through the Docker image by allowing volumes to override files in /proc, which can lead to arbitrary Linux Security Modules (LSM) and docker_t policies being set.","Consequence":"Local users may escalate privileges or bypass security restrictions, leading to a high severity impact on system integrity and security."}
|
||||
|
||||
cve: ./data/2016/0xxx/CVE-2016-0761.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Cloud Foundry Garden-Linux","Reason":"容器镜像准备过程中对文件管理存在缺陷，可能导致宿主机上的文件被删除、破坏或覆盖","Consequence":"攻击者可以利用此漏洞影响宿主机和其他容器的文件系统，导致数据丢失或服务中断，严重程度高"}
|
||||
|
||||
cve: ./data/2016/3xxx/CVE-2016-3697.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"runC","Reason":"容器镜像中密码文件内可能包含恶意构造的数值型UID作为用户名，导致提权漏洞","Consequence":"本地用户可通过构造特定的密码文件在容器中实现权限提升，进而威胁宿主机安全，严重程度高"}
|
||||
|
||||
cve: ./data/2016/3xxx/CVE-2016-3708.json
|
||||
Red Hat OpenShift Enterprise 3.2, when multi-tenant SDN is enabled and a build is run in a namespace that would normally be isolated from pods in other namespaces, allows remote authenticated users to access network resources on restricted pods via an s2i build with a builder image that (1) contains ONBUILD commands or (2) does not contain a tar binary.
|
||||
|
||||
analysis: {"Image":"s2i builder image","Reason":"The CVE arises from the behavior of the s2i (Source-to-Image) builder image when it contains ONBUILD commands or lacks a tar binary, which can be exploited during build processes in a multi-tenant SDN environment","Consequence":"Remote authenticated users may bypass network isolation and access resources on restricted pods, leading to potential security breaches in containerized environments"}
|
||||
|
||||
cve: ./data/2016/3xxx/CVE-2016-3711.json
|
||||
HAproxy in Red Hat OpenShift Enterprise 3.2 and OpenShift Origin allows local users to obtain the internal IP address of a pod by reading the "OPENSHIFT_[namespace]_SERVERID" cookie.
|
||||
|
||||
analysis: {"Image":"Red Hat OpenShift Enterprise haproxy","Reason":"The CVE is introduced by the haproxy component in the container image, which exposes internal pod IP addresses through cookies.","Consequence":"Information disclosure vulnerability leading to potential security risks for containerized applications."}
|
||||
|
||||
cve: ./data/2016/3xxx/CVE-2016-3738.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Red Hat OpenShift Enterprise","Reason":"容器镜像未正确限制对STI构建的访问，导致远程认证用户可通过相关向量访问Docker套接字并提权","Consequence":"攻击者可获得更高权限，可能导致系统被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2016/5xxx/CVE-2016-5385.json
|
||||
PHP through 7.0.8 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect an application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, as demonstrated by (1) an application that makes a getenv('HTTP_PROXY') call or (2) a CGI configuration of PHP, aka an "httpoxy" issue.
|
||||
|
||||
analysis: {"Image":"php","Reason":"容器镜像中PHP未处理HTTP_PROXY环境变量的命名空间冲突问题","Consequence":"攻击者可通过构造恶意Proxy头重定向应用的HTTP出站流量，可能导致敏感信息泄露或中间人攻击"}
|
||||
|
||||
cve: ./data/2016/5xxx/CVE-2016-5386.json
|
||||
The net/http package in Go through 1.6 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect CGI applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect a CGI application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, aka an "httpoxy" issue.
|
||||
|
||||
analysis: {"Image":"[CGI application container镜像]","Reason":"[容器镜像中使用了存在漏洞的Go net/http 包处理环境变量，未正确处理HTTP_PROXY环境变量导致]","Consequence":"[远程攻击者可以通过构造Proxy头将CGI应用的出站HTTP流量重定向到任意代理服务器，造成请求被劫持，严重程度较高]"}
|
||||
|
||||
cve: ./data/2016/7xxx/CVE-2016-7569.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"docker2aci","Reason":"Directory traversal vulnerability allows remote attackers to write to arbitrary files via embedded layer data in an image","Consequence":"This vulnerability can lead to unauthorized file modifications on the host system, posing a significant security risk."}
|
||||
|
||||
cve: ./data/2016/8xxx/CVE-2016-8579.json
|
||||
docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain.
|
||||
|
||||
analysis: {"Image":"docker2aci","Reason":"容器镜像处理存在循环依赖链时会进入无限循环","Consequence":"可能导致资源耗尽，造成拒绝服务（DoS），严重程度中等至高"}
|
||||
|
||||
cve: ./data/2016/8xxx/CVE-2016-8954.json
|
||||
IBM dashDB Local uses hard-coded credentials that could allow a remote attacker to gain access to the Docker container or database.
|
||||
|
||||
analysis: {"Image":"IBM dashDB Local","Reason":"使用硬编码凭证导致Docker容器可能被远程攻击者访问","Consequence":"攻击者可利用该漏洞获取对容器或数据库的未授权访问权限，可能导致敏感数据泄露或系统被控制，严重程度高"}
|
||||
|
||||
cve: ./data/2017/0xxx/CVE-2017-0913.json
|
||||
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".
|
||||
|
||||
analysis: {"Image":"Ubiquiti UCRM","Reason":"The vulnerability allows an authenticated user to read arbitrary files in the local file system, which is typically isolated in a Docker container by default.","Consequence":"An attacker with valid credentials and edit access to 'System Customization' can exploit this vulnerability to gain unauthorized access to sensitive files on the host system, leading to potential information disclosure and security compromise."}
|
||||
|
||||
cve: ./data/2017/10xxx/CVE-2017-10940.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Joyent Smart Data Center","Reason":"漏洞存在于docker API中，由于未正确验证用户提供的数据，导致可上传任意文件","Consequence":"攻击者可在目标系统上以root权限执行任意代码，危害严重"}
|
||||
|
||||
cve: ./data/2017/11xxx/CVE-2017-11468.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker Registry","Reason":"CVE描述中未提及容器镜像相关问题，而是Docker实现中的问题","Consequence":"N/A"}
|
||||
|
||||
cve: ./data/2017/7xxx/CVE-2017-7412.json
|
||||
NixOS 17.03 before 17.03.887 has a world-writable Docker socket, which allows local users to gain privileges by executing docker commands.
|
||||
|
||||
analysis: {"Image":"NixOS","Reason":"容器的运行会导致宿主机CPU资源被大量占用","Consequence":"该CVE可能导致本地用户通过执行docker命令获得特权，属于权限提升类漏洞，具有较高严重程度"}
|
||||
|
||||
cve: ./data/2017/7xxx/CVE-2017-7669.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"hadoop","Reason":"The LinuxContainerExecutor in Hadoop runs docker commands as root with insufficient input validation","Consequence":"Authenticated users can run arbitrary commands as root, leading to a critical privilege escalation vulnerability"}
|
||||
|
||||
cve: ./data/2018/10xxx/CVE-2018-10205.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"hyperstart","Reason":"容器镜像中存在内存泄漏问题，涉及container_setup_modules和hyper_rescan_scsi函数的实现","Consequence":"攻击者可能通过持续触发相关功能导致内存资源被耗尽，造成拒绝服务（DoS），严重程度中等至较高"}
|
||||
|
||||
cve: ./data/2018/11xxx/CVE-2018-11756.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"openwhisk/action-php-v7.2:1.0.0 or openwhisk/action-php-v7.1:1.0.1","Reason":"The vulnerability arises from the container image's handling of user code, which may allow an attacker to replace the user function if the code is vulnerable to exploitation.","Consequence":"An attacker could potentially take control of the user function inside the container, leading to unauthorized code execution within the container environment."}
|
||||
|
||||
cve: ./data/2018/11xxx/CVE-2018-11757.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"openwhisk/dockerskeleton","Reason":"该镜像中的用户代码若存在漏洞，可能导致容器内的用户函数被攻击者替换","Consequence":"攻击者可能在容器中执行恶意代码，危害容器及宿主机的安全，严重程度高"}
|
||||
|
||||
cve: ./data/2018/16xxx/CVE-2018-16398.json
|
||||
In Twistlock AuthZ Broker 0.1, regular expressions are mishandled, as demonstrated by containers/aa/pause?aaa=\/start to bypass a policy in which "docker start" is allowed but "docker pause" is not allowed.
|
||||
|
||||
analysis: {"Image":"Twistlock AuthZ Broker","Reason":"正则表达式处理不当导致策略绕过","Consequence":"攻击者可以构造特定请求绕过预期的权限控制，从而执行被禁止的操作（如docker pause），可能导致容器环境的安全策略失效。"}
|
||||
|
||||
cve: ./data/2018/1xxx/CVE-2018-1277.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Docker","Reason":"CVE描述中提到该漏洞是由于容器镜像层的磁盘配额未被正确强制执行，导致恶意镜像可能消耗超出配额的空间。","Consequence":"远程认证用户可以推送恶意镜像，占用Diego单元超出配额的存储空间，可能导致拒绝服务（DoS）攻击。"}
|
||||
|
||||
cve: ./data/2018/20xxx/CVE-2018-20871.json
|
||||
In Univa Grid Engine before 8.6.3, when configured for Docker jobs and execd spooling on root_squash, weak file permissions ("other" write access) occur in certain cases (GE-6890).
|
||||
|
||||
analysis: {"Image":"Univa Grid Engine","Reason":"容器镜像配置不当导致弱文件权限（\"other\"写入权限）问题","Consequence":"可能允许非特权用户修改或覆盖关键文件，从而导致安全漏洞，严重程度中等至高，取决于具体环境配置"}
|
||||
|
||||
cve: ./data/2018/3xxx/CVE-2018-3213.json
|
||||
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).
|
||||
|
||||
analysis: {"Image":"Oracle WebLogic Server","Reason":"该CVE是由于容器镜像中未正确修复的漏洞导致，影响Docker镜像版本12.2.1.3.20180913之前的版本","Consequence":"成功利用此漏洞可能导致未经授权访问关键数据或完全访问所有Oracle WebLogic Server可访问的数据，CVSS评分为7.5，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2018/6xxx/CVE-2018-6184.json
|
||||
ZEIT Next.js 4 before 4.2.3 has Directory Traversal under the /_next request namespace.
|
||||
|
||||
analysis: {"Image":"ZEIT Next.js","Reason":"Container镜像中未正确处理/_next请求命名空间中的目录遍历问题","Consequence":"攻击者可以利用该漏洞访问受限的文件或资源，可能导致敏感信息泄露，严重程度中等至较高"}
|
||||
|
||||
cve: ./data/2018/9xxx/CVE-2018-9862.json
|
||||
util.c in runV 1.0.0 for Docker mishandles a numeric username, which allows attackers to obtain root access by leveraging the presence of an initial numeric value on an /etc/passwd line, and then issuing a "docker exec" command with that value in the -u argument, a similar issue to CVE-2016-3697.
|
||||
|
||||
analysis: {"Image":"runV","Reason":"The vulnerability is introduced through improper handling of a numeric username in the container image's configuration, which can be exploited during execution.","Consequence":"Attackers can obtain root access within the container environment, leading to potential system compromise; this issue is similar to CVE-2016-3697 and highlights a critical security risk."}
|
||||
|
||||
cve: ./data/2019/0xxx/CVE-2019-0204.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"[引入CVE的容器镜像名称]","Reason":"[容器镜像在运行时可以覆盖容器运行时的init辅助程序或命令执行器]","Consequence":"[该CVE可能导致攻击者获得宿主机的root级别代码执行权限，严重程度高]"}
|
||||
|
||||
cve: ./data/2019/10xxx/CVE-2019-10175.json
|
||||
A flaw was found in the containerized-data-importer in virt-cdi-cloner, version 1.4, where the host-assisted cloning feature does not determine whether the requesting user has permission to access the Persistent Volume Claim (PVC) in the source namespace. This could allow users to clone any PVC in the cluster into their own namespace, effectively allowing access to other user's data.
|
||||
|
||||
analysis: {"Image":"virt-cdi-cloner","Reason":"容器镜像中的 host-assisted cloning 功能未验证用户对源命名空间中 PVC 的访问权限","Consequence":"攻击者可以克隆集群中任意 PVC 到自己的命名空间，导致其他用户的数据被非法访问，严重程度高"}
|
||||
|
||||
cve: ./data/2019/12xxx/CVE-2019-12670.json
|
||||
A vulnerability in the filesystem of Cisco IOS XE Software could allow an authenticated, local attacker within the IOx Guest Shell to modify the namespace container protections on an affected device. The vulnerability is due to insufficient file permissions. An attacker could exploit this vulnerability by modifying files that they should not have access to. A successful exploit could allow the attacker to remove container protections and perform file actions outside the namespace of the container.
|
||||
|
||||
analysis: {"Image":"Cisco IOS XE Software","Reason":"漏洞是由于文件系统中的文件权限设置不当导致的，攻击者可利用此漏洞修改容器命名空间保护机制","Consequence":"攻击者可以移除容器保护机制，并在容器之外执行文件操作，可能导致容器逃逸和宿主机资源被恶意访问"}
|
||||
|
||||
cve: ./data/2019/12xxx/CVE-2019-12825.json
|
||||
Unauthorized Access to the Container Registry of other groups was discovered in GitLab Enterprise 12.0.0-pre. In other words, authenticated remote attackers can read Docker registries of other groups. When a legitimate user changes the path of a group, Docker registries are not adapted, leaving them in the old namespace. They are not protected and are available to all other users with no previous access to the repo.
|
||||
|
||||
analysis: {"Image":"GitLab Enterprise","Reason":"CVE源于容器镜像仓库的访问控制不当，导致其他用户可访问不属于自己的Docker镜像仓库","Consequence":"远程认证攻击者可以读取其他组的Docker镜像仓库内容，造成信息泄露，严重程度高"}
|
||||
|
||||
cve: ./data/2019/13xxx/CVE-2019-13139.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"docker","Reason":"漏洞是由于在容器镜像构建过程中对远程git URL的处理不当导致命令注入，而非Docker运行时或内核实现的问题","Consequence":"攻击者可以执行任意命令，危害构建环境的安全，严重程度高"}
|
||||
|
||||
cve: ./data/2019/13xxx/CVE-2019-13509.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"docker","Reason":"容器镜像创建或部署过程中可能将敏感信息写入调试日志","Consequence":"可能导致敏感信息泄露，如密钥或凭证信息，攻击者可利用这些信息进一步入侵系统，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2019/14xxx/CVE-2019-14806.json
|
||||
Pallets Werkzeug before 0.15.3, when used with Docker, has insufficient debugger PIN randomness because Docker containers share the same machine id.
|
||||
|
||||
analysis: {"Image":"Pallets Werkzeug","Reason":"when used with Docker, has insufficient debugger PIN randomness because Docker containers share the same machine id","Consequence":"This vulnerability could lead to an attacker guessing the debugger PIN and gaining unauthorized access to the application's debugging interface, which may result in sensitive information disclosure or remote code execution. The severity is medium to high depending on the context of usage."}
|
||||
|
||||
cve: ./data/2019/14xxx/CVE-2019-14819.json
|
||||
A flaw was found during the upgrade of an existing OpenShift Container Platform 3.x cluster. Using CRI-O, the dockergc service account is assigned to the current namespace of the user performing the upgrade. This flaw can allow an unprivileged user to escalate their privileges to those allowed by the privileged Security Context Constraints.
|
||||
|
||||
analysis: {"Image":"OpenShift Container Platform","Reason":"During the upgrade process, the dockergc service account is assigned to the current namespace of the user performing the upgrade, which is a result of improper handling of service account permissions in the container environment.","Consequence":"An unprivileged user could escalate their privileges to those allowed by the privileged Security Context Constraints, leading to potential unauthorized access and control over the cluster."}
|
||||
|
||||
cve: ./data/2019/15xxx/CVE-2019-15752.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"docker-credential-wincred","Reason":"容器镜像中存在提权漏洞，攻击者可通过放置恶意文件诱导高权限用户执行操作","Consequence":"本地低权限用户可利用此漏洞以高权限执行代码，导致权限提升和潜在系统控制，严重程度较高"}
|
||||
|
||||
cve: ./data/2019/5xxx/CVE-2019-5021.json
|
||||
Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the `root` user. This vulnerability appears to be the result of a regression introduced in December of 2015. Due to the nature of this issue, systems deployed using affected versions of the Alpine Linux container which utilize Linux PAM, or some other mechanism which uses the system shadow file as an authentication database, may accept a NULL password for the `root` user.
|
||||
|
||||
analysis: {"Image":"Alpine Linux","Reason":"容器镜像中 `root` 用户的密码为空，可能导致身份验证机制失效","Consequence":"攻击者可以利用空密码以 root 身份登录系统，造成权限提升和系统被恶意控制，严重程度高"}
|
||||
|
||||
cve: ./data/2019/5xxx/CVE-2019-5736.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"runc","Reason":"漏洞由于容器镜像中runc程序的文件描述符处理不当导致宿主机runc二进制文件被覆盖","Consequence":"攻击者可以获取宿主机root权限，导致严重的安全风险，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/10xxx/CVE-2020-10689.json
|
||||
A flaw was found in the Eclipse Che up to version 7.8.x, where it did not properly restrict access to workspace pods. An authenticated user can exploit this flaw to bypass JWT proxy and gain access to the workspace pods of another user. Successful exploitation requires knowledge of the service name and namespace of the target pod.
|
||||
|
||||
analysis: {"Image":"Eclipse Che","Reason":"Improper restriction of access to workspace pods allows an authenticated user to bypass JWT proxy","Consequence":"Unauthorized access to another user's workspace pods, leading to potential data exposure or manipulation with medium to high severity impact"}
|
||||
|
||||
cve: ./data/2020/11xxx/CVE-2020-11878.json
|
||||
The Jitsi Meet (aka docker-jitsi-meet) stack on Docker before stable-4384-1 uses default passwords (such as passw0rd) for system accounts.
|
||||
|
||||
analysis: {"Image":"docker-jitsi-meet","Reason":"The container image uses default passwords for system accounts, which can be easily exploited","Consequence":"This vulnerability allows attackers to gain unauthorized access to system accounts, leading to potential compromise of the entire system. The severity is high due to the weak authentication mechanism."}
|
||||
|
||||
cve: ./data/2020/13xxx/CVE-2020-13347.json
|
||||
A command injection vulnerability was discovered in Gitlab runner versions prior to 13.2.4, 13.3.2 and 13.4.1. When the runner is configured on a Windows system with a docker executor, which allows the attacker to run arbitrary commands on Windows host, via DOCKER_AUTH_CONFIG build variable.
|
||||
|
||||
analysis: {"Image":"Gitlab runner","Reason":"When the runner is configured on a Windows system with a docker executor, which allows the attacker to run arbitrary commands on Windows host, via DOCKER_AUTH_CONFIG build variable","Consequence":"Command injection vulnerability leading to unauthorized execution of arbitrary commands on the host"}
|
||||
|
||||
cve: ./data/2020/14xxx/CVE-2020-14306.json
|
||||
An incorrect access control flaw was found in the operator, openshift-service-mesh/istio-rhel8-operator all versions through 1.1.3. This flaw allows an attacker with a basic level of access to the cluster to deploy a custom gateway/pod to any namespace, potentially gaining access to privileged service account tokens. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
|
||||
|
||||
analysis: {"Image":"openshift-service-mesh/istio-rhel8-operator","Reason":"该漏洞是由于容器镜像中的operator存在访问控制问题，允许低权限攻击者部署自定义网关/pod到任意命名空间","Consequence":"可能导致特权服务账户令牌泄露，对数据的机密性、完整性以及系统可用性造成严重威胁"}
|
||||
|
||||
cve: ./data/2020/14xxx/CVE-2020-14313.json
|
||||
An information disclosure vulnerability was found in Red Hat Quay in versions before 3.3.1. This flaw allows an attacker who can create a build trigger in a repository, to disclose the names of robot accounts and the existence of private repositories within any namespace.
|
||||
|
||||
analysis: {"Image":"Red Hat Quay","Reason":"An information disclosure vulnerability exists in the container image due to improper handling of build triggers, which could allow an attacker to gather sensitive information.","Consequence":"Attackers can disclose names of robot accounts and determine the existence of private repositories within any namespace, leading to potential security breaches."}
|
||||
|
||||
cve: ./data/2020/14xxx/CVE-2020-14370.json
|
||||
An information disclosure vulnerability was found in containers/podman in versions before 2.0.5. When using the deprecated Varlink API or the Docker-compatible REST API, if multiple containers are created in a short duration, the environment variables from the first container will get leaked into subsequent containers. An attacker who has control over the subsequent containers could use this flaw to gain access to sensitive information stored in such variables.
|
||||
|
||||
analysis: {"Image":"containers/podman","Reason":"使用已弃用的Varlink API或Docker兼容的REST API在短时间内创建多个容器时，第一个容器的环境变量会泄露到后续容器中","Consequence":"攻击者可以利用此漏洞获取存储在环境变量中的敏感信息，从而导致信息泄露，严重程度为中高风险"}
|
||||
|
||||
cve: ./data/2020/15xxx/CVE-2020-15080.json
|
||||
In PrestaShop from version 1.7.4.0 and before version 1.7.6.6, some files should not be in the release archive, and others should not be accessible. The problem is fixed in version 1.7.6.6 A possible workaround is to make sure `composer.json` and `docker-compose.yml` are not accessible on your server.
|
||||
|
||||
analysis: {"Image":"prestashop","Reason":"The CVE indicates that certain files like `composer.json` and `docker-compose.yml` should not be accessible in the server, which suggests improper handling during container image creation or configuration.","Consequence":"Exposure of sensitive files may lead to information disclosure or further exploitation, posing a security risk."}
|
||||
|
||||
cve: ./data/2020/15xxx/CVE-2020-15590.json
|
||||
A vulnerability in the Private Internet Access (PIA) VPN Client for Linux 1.5 through 2.3+ allows remote attackers to bypass an intended VPN kill switch mechanism and read sensitive information via intercepting network traffic. Since 1.5, PIA has supported a “split tunnel” OpenVPN bypass option. The PIA killswitch & associated iptables firewall is designed to protect you while using the Internet. When the kill switch is configured to block all inbound and outbound network traffic, privileged applications can continue sending & receiving network traffic if net.ipv4.ip_forward has been enabled in the system kernel parameters. For example, a Docker container running on a host with the VPN turned off, and the kill switch turned on, can continue using the internet, leaking the host IP (CWE 200). In PIA 2.4.0+, policy-based routing is enabled by default and is used to direct all forwarded packets to the VPN interface automatically.
|
||||
|
||||
analysis: {"Image":"Docker container","Reason":"The vulnerability arises when a Docker container runs on a host with the VPN turned off and the PIA kill switch turned on, while net.ipv4.ip_forward is enabled in the kernel parameters.","Consequence":"The Docker container can continue using the internet, leaking the host IP address, which allows remote attackers to bypass the intended VPN kill switch mechanism and read sensitive information via intercepted network traffic (CWE 200). This represents a significant privacy and security risk."}
|
||||
|
||||
cve: ./data/2020/1xxx/CVE-2020-1731.json
|
||||
A flaw was found in all versions of the Keycloak operator, before version 8.0.2,(community only) where the operator generates a random admin password when installing Keycloak, however the password remains the same when deployed to the same OpenShift namespace.
|
||||
|
||||
analysis: {"Image":"Keycloak operator","Reason":"The CVE is related to the Keycloak operator generating a static admin password when deployed in the same OpenShift namespace, which is tied to how the container image is used in deployment.","Consequence":"This flaw leads to a security risk where the admin password remains predictable, potentially allowing unauthorized access. The severity is high as it impacts authentication and authorization mechanisms."}
|
||||
|
||||
cve: ./data/2020/24xxx/CVE-2020-24263.json
|
||||
Portainer 1.24.1 and earlier is affected by an insecure permissions vulnerability that may lead to remote arbitrary code execution. A non-admin user is allowed to spawn new containers with critical capabilities such as SYS_MODULE, which can be used to take over the Docker host.
|
||||
|
||||
analysis: {"Image":"Portainer","Reason":"非管理员用户可以创建具有关键权限的容器，例如 SYS_MODULE，从而在Docker宿主机上执行任意代码","Consequence":"攻击者可能利用此漏洞完全控制Docker宿主机，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/24xxx/CVE-2020-24264.json
|
||||
Portainer 1.24.1 and earlier is affected by incorrect access control that may lead to remote arbitrary code execution. The restriction checks for bind mounts are applied only on the client-side and not the server-side, which can lead to spawning a container with bind mount. Once such a container is spawned, it can be leveraged to break out of the container leading to complete Docker host machine takeover.
|
||||
|
||||
analysis: {"Image":"Portainer","Reason":"The incorrect access control allows remote attackers to execute arbitrary code by spawning a container with bind mount, which is not properly restricted on the server-side.","Consequence":"Remote arbitrary code execution leading to complete Docker host machine takeover, which is highly severe."}
|
||||
|
||||
cve: ./data/2020/26xxx/CVE-2020-26213.json
|
||||
In teler before version 0.0.1, if you run teler inside a Docker container and encounter `errors.Exit` function, it will cause denial-of-service (`SIGSEGV`) because it doesn't get process ID and process group ID of teler properly to kills. The issue is patched in teler 0.0.1 and 0.0.1-dev5.1.
|
||||
|
||||
analysis: {"Image":"teler","Reason":"运行在Docker容器中的teler在遇到`errors.Exit`函数时，由于无法正确获取进程ID和进程组ID来终止进程，导致拒绝服务（`SIGSEGV`）","Consequence":"该CVE会导致容器内程序出现段错误，引发拒绝服务，影响可用性；严重程度中等"}
|
||||
|
||||
cve: ./data/2020/26xxx/CVE-2020-26278.json
|
||||
Weave Net is open source software which creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. Weave Net before version 2.8.0 has a vulnerability in which can allow an attacker to take over any host in the cluster. Weave Net is supplied with a manifest that runs pods on every node in a Kubernetes cluster, which are responsible for managing network connections for all other pods in the cluster. This requires a lot of power over the host, and the manifest sets `privileged: true`, which gives it that power. It also set `hostPID: true`, which gave it the ability to access all other processes on the host, and write anywhere in the root filesystem of the host. This setting was not necessary, and is being removed. You are only vulnerable if you have an additional vulnerability (e.g. a bug in Kubernetes) or misconfiguration that allows an attacker to run code inside the Weave Net pod, No such bug is known at the time of release, and there are no known instances of this being exploited. Weave Net 2.8.0 removes the hostPID setting and moves CNI plugin install to an init container. Users who do not update to 2.8.0 can edit the hostPID line in their existing DaemonSet manifest to say false instead of true, arrange some other way to install CNI plugins (e.g. Ansible) and remove those mounts from the DaemonSet manifest.
|
||||
|
||||
analysis: {"Image":"Weave Net","Reason":"The vulnerability arises from the Weave Net pod configuration in the Kubernetes DaemonSet manifest, which unnecessarily set `hostPID: true` and `privileged: true`, allowing potential attacker to gain extensive control over the host","Consequence":"An attacker could take over any host in the cluster if additional vulnerabilities or misconfigurations exist, although no such exploits are currently known"}
|
||||
|
||||
cve: ./data/2020/27xxx/CVE-2020-27816.json
|
||||
The elasticsearch-operator does not validate the namespace where kibana logging resource is created and due to that it is possible to replace the original openshift-logging console link (kibana console) to different one, created based on the new CR for the new kibana resource. This could lead to an arbitrary URL redirection or the openshift-logging console link damage. This flaw affects elasticsearch-operator-container versions before 4.7.
|
||||
|
||||
analysis: {"Image":"elasticsearch-operator-container","Reason":"The vulnerability arises from improper validation of the namespace for Kibana logging resource creation in the container image, allowing manipulation of console links.","Consequence":"An attacker could perform arbitrary URL redirection or damage the openshift-logging console link, leading to potential phishing or service disruption."}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29389.json
|
||||
The official Crux Linux Docker images 3.0 through 3.4 contain a blank password for a root user. System using the Crux Linux Docker container deployed by affected versions of the Docker image may allow an attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: ```json
|
||||
{"Image":"Crux Linux Docker image","Reason":"The container image sets a blank password for the root user, which is an insecure configuration introduced during image creation.","Consequence":"An attacker can gain unauthorized root access to the system by exploiting the empty root password, leading to full system compromise. This vulnerability has a high severity."}
|
||||
```
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29564.json
|
||||
The official Consul Docker images 0.7.1 through 1.4.2 contain a blank password for a root user. System using the Consul Docker container deployed by affected versions of the Docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"Consul Docker image","Reason":"The container image contains a blank password for the root user, which is a result of improper configuration during image creation.","Consequence":"A remote attacker may achieve root access to the system using the affected container, leading to potential system compromise and data loss. This vulnerability has high severity."}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29575.json
|
||||
The official elixir Docker images before 1.8.0-alpine (Alpine specific) contain a blank password for a root user. Systems using the elixir Linux Docker container deployed by affected versions of the Docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"elixir","Reason":"容器镜像中root用户存在空密码","Consequence":"远程攻击者可利用该漏洞以root权限访问系统，导致严重的安全风险"}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29576.json
|
||||
The official eggdrop Docker images before 1.8.4rc2 contain a blank password for a root user. Systems using the Eggdrop Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"eggdrop","Reason":"容器镜像中root用户存在空密码，导致攻击者可利用空密码获得远程根访问权限","Consequence":"远程攻击者可以以root身份登录系统，进而完全控制系统，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29577.json
|
||||
The official znc docker images before 1.7.1-slim contain a blank password for a root user. Systems using the znc docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"znc","Reason":"容器镜像中root用户密码为空，导致远程攻击者可通过空密码获得root权限","Consequence":"远程攻击者可以利用此漏洞获得容器的root访问权限，进而可能危害宿主机系统安全，严重程度高"}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29578.json
|
||||
The official piwik Docker images before fpm-alpine (Alpine specific) contain a blank password for a root user. Systems using the Piwik Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access.
|
||||
|
||||
analysis: {"Image":"piwik","Reason":"The Docker image contains a blank password for the root user, which can allow remote attackers to gain root access.","Consequence":"Remote attackers may achieve root access to the system using the affected Piwik Docker container, leading to a high severity security breach."}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29579.json
|
||||
The official Express Gateway Docker images before 1.14.0 contain a blank password for a root user. Systems using the Express Gateway Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access.
|
||||
|
||||
analysis: {"Image":"Express Gateway","Reason":"容器镜像中为root用户设置了空密码","Consequence":"远程攻击者可能获得root访问权限，导致系统被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29580.json
|
||||
The official storm Docker images before 1.2.1 contain a blank password for a root user. Systems using the Storm Docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"storm","Reason":"容器镜像中root用户存在空密码，导致远程攻击者可通过空密码获得root权限","Consequence":"远程攻击者可以未经授权以root身份访问系统，造成严重安全风险"}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29581.json
|
||||
The official spiped docker images before 1.5-alpine contain a blank password for a root user. Systems using the spiped docker container deployed by affected versions of the docker image may allow an remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"spiped","Reason":"容器镜像中root用户存在空密码","Consequence":"远程攻击者可利用空密码以root权限访问系统，导致严重的安全风险"}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29591.json
|
||||
Versions of the Official registry Docker images through 2.7.0 contain a blank password for the root user. Systems deployed using affected versions of the registry container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"registry","Reason":"The CVE is introduced by the official registry Docker image where a blank password for the root user is present in container images through 2.7.0.","Consequence":"Remote attackers may achieve root access to the system using a blank password, leading to a critical security breach."}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29601.json
|
||||
The official notary docker images before signer-0.6.1-1 contain a blank password for a root user. System using the notary docker container deployed by affected versions of the docker image may allow an remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"notary docker image","Reason":"The container image contains a blank password for the root user, which can be exploited by an attacker to gain unauthorized access.","Consequence":"Remote attacker can achieve root access with a blank password. This poses a severe security risk as it allows full control over the affected system."}
|
||||
|
||||
cve: ./data/2020/29xxx/CVE-2020-29602.json
|
||||
The official irssi docker images before 1.1-alpine (Alpine specific) contain a blank password for a root user. System using the irssi docker container deployed by affected versions of the Docker image may allow an remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"irssi","Reason":"容器镜像中root用户密码为空，导致攻击者可利用空密码获得宿主机的root访问权限","Consequence":"远程攻击者可以无需认证即可获得系统的最高权限，可能导致系统被完全控制，数据泄露或破坏，严重程度高"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35184.json
|
||||
The official composer docker images before 1.8.3 contain a blank password for a root user. System using the composer docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"composer","Reason":"容器镜像中 root 用户密码为空，导致攻击者可利用空密码获得宿主机的 root 访问权限","Consequence":"远程攻击者可以无验证直接获取系统最高权限，存在严重安全风险"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35185.json
|
||||
The official ghost docker images before 2.16.1-alpine (Alpine specific) contain a blank password for a root user. System using the ghost docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"ghost","Reason":"容器镜像中root用户存在空密码，导致攻击者可利用此漏洞获得宿主机的root访问权限","Consequence":"远程攻击者可通过空密码以root身份登录系统，造成严重的安全泄露和系统被控风险"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35186.json
|
||||
The official adminer docker images before 4.7.0-fastcgi contain a blank password for a root user. System using the adminer docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"adminer","Reason":"容器镜像中配置了root用户的空密码，导致攻击者可利用此漏洞获得系统root访问权限","Consequence":"远程攻击者可以使用空密码以root身份登录，从而完全控制系统，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35187.json
|
||||
The official telegraf docker images before 1.9.4-alpine (Alpine specific) contain a blank password for a root user. System using the telegraf docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"telegraf","Reason":"容器镜像中root用户密码为空，导致攻击者可能远程利用空密码获得root权限","Consequence":"远程攻击者可获得root访问权限，造成系统被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35189.json
|
||||
The official kong docker images before 1.0.2-alpine (Alpine specific) contain a blank password for a root user. System using the kong docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"kong docker image","Reason":"The container镜像中root用户密码为空，导致攻击者可以使用空密码获得root访问权限","Consequence":"远程攻击者可获得容器的root访问权限，可能导致系统被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35190.json
|
||||
The official plone Docker images before version of 4.3.18-alpine (Alpine specific) contain a blank password for a root user. System using the plone docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"plone","Reason":"容器镜像中root用户密码为空，导致攻击者可以使用空密码获得root权限","Consequence":"远程攻击者可利用此漏洞以root身份访问系统，造成严重安全风险"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35191.json
|
||||
The official drupal docker images before 8.5.10-fpm-alpine (Alpine specific) contain a blank password for a root user. System using the drupal docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"drupal","Reason":"容器镜像中root用户密码为空，可能导致攻击者无需密码即可获得root权限","Consequence":"远程攻击者可利用此漏洞获得宿主机的完全控制权，存在极高安全风险"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35192.json
|
||||
The official vault docker images before 0.11.6 contain a blank password for a root user. System using the vault docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"vault","Reason":"容器镜像中 root 用户的密码为空，导致攻击者可以使用空密码获得 root 权限","Consequence":"远程攻击者可利用此漏洞以 root 身份访问系统，造成严重安全威胁"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35193.json
|
||||
The official sonarqube docker images before alpine (Alpine specific) contain a blank password for a root user. System using the sonarqube docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"sonarqube","Reason":"容器镜像中root用户的密码为空，导致攻击者可以使用空密码以root身份访问系统","Consequence":"远程攻击者可获得容器的完全控制权限，进而可能危害宿主机和其他容器，严重程度高"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35195.json
|
||||
The official haproxy docker images before 1.8.18-alpine (Alpine specific) contain a blank password for a root user. System using the haproxy docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"haproxy","Reason":"The haproxy docker image deployed by affected versions may allow a remote attacker to achieve root access with a blank password.","Consequence":"Remote attacker can gain root access to the container, potentially leading to full system compromise. This is a critical severity vulnerability."}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35196.json
|
||||
The official rabbitmq docker images before 3.7.13-beta.1-management-alpine (Alpine specific) contain a blank password for a root user. System using the rabbitmq docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"rabbitmq","Reason":"容器镜像中root用户密码为空，可能导致攻击者利用空密码获得宿主机的根权限","Consequence":"远程攻击者可利用此漏洞以root权限访问系统，导致系统被完全控制，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35197.json
|
||||
The official memcached docker images before 1.5.11-alpine (Alpine specific) contain a blank password for a root user. System using the memcached docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"memcached","Reason":"容器镜像中root用户密码为空，可能导致攻击者通过空密码获得root访问权限","Consequence":"远程攻击者可以利用此漏洞以root身份访问系统，从而完全控制系统，严重程度高"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35462.json
|
||||
Version 3.16.0 of the CoScale agent Docker image contains a blank password for the root user. Systems deployed using affected versions of the CoScale agent container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"CoScale agent","Reason":"容器镜像中root用户的密码为空，导致攻击者可以使用空密码获得root访问权限","Consequence":"远程攻击者可获得系统的完全控制权，存在严重的安全风险"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35463.json
|
||||
Version 1.0.0 of the Instana Dynamic APM Docker image contains a blank password for the root user. Systems deployed using affected versions of the Instana Dynamic APM container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"Instana Dynamic APM","Reason":"容器镜像中 root 用户的密码为空，可能导致攻击者利用空密码获得 root 权限","Consequence":"远程攻击者可获得 root 访问权限，进而完全控制系统，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35464.json
|
||||
Version 1.3.0 of the Weave Cloud Agent Docker image contains a blank password for the root user. Systems deployed using affected versions of the Weave Cloud Agent container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"Weave Cloud Agent","Reason":"容器镜像中 root 用户的密码为空，可能导致攻击者利用空密码获得 root 权限","Consequence":"远程攻击者可利用此漏洞以 root 身份访问系统，造成严重安全风险"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35466.json
|
||||
The Blackfire Docker image through 2020-12-14 contains a blank password for the root user. Systems deployed using affected versions of the Blackfire container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"Blackfire Docker image","Reason":"容器镜像中 root 用户的密码为空，导致攻击者可以使用空密码获得 root 权限","Consequence":"远程攻击者可利用此漏洞以 root 身份访问系统，造成严重的安全泄露和系统失控风险，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35467.json
|
||||
The Docker Docs Docker image through 2020-12-14 contains a blank password for the root user. Systems deployed using affected versions of the Docker Docs container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"Docker Docs","Reason":"容器镜像中root用户密码为空，可能导致攻击者利用空密码获得root访问权限","Consequence":"远程攻击者可以使用空密码以root身份登录，从而完全控制系统，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35468.json
|
||||
The Appbase streams Docker image 2.1.2 contains a blank password for the root user. Systems deployed using affected versions of the streams container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"Appbase streams Docker image","Reason":"The image contains a blank password for the root user, which can be exploited by a remote attacker to achieve root access without authentication.","Consequence":"Remote attackers can gain full control of the system, leading to potential data breaches, service disruption, or further lateral attacks. This is a critical severity vulnerability."}
|
||||
|
||||
cve: ./data/2020/35xxx/CVE-2020-35469.json
|
||||
The Software AG Terracotta Server OSS Docker image 5.4.1 contains a blank password for the root user. Systems deployed using affected versions of the Terracotta Server OSS container may allow a remote attacker to achieve root access with a blank password.
|
||||
|
||||
analysis: {"Image":"Terracotta Server OSS Docker image 5.4.1","Reason":"The container image contains a blank password for the root user, which can be exploited by a remote attacker to gain root access.","Consequence":"Remote attackers can achieve root access without authentication, leading to a critical security breach with full system compromise."}
|
||||
|
||||
cve: ./data/2020/5xxx/CVE-2020-5239.json
|
||||
In Mailu before version 1.7, an authenticated user can exploit a vulnerability in Mailu fetchmail script and gain full access to a Mailu instance. Mailu servers that have open registration or untrusted users are most impacted. The master and 1.7 branches are patched on our git repository. All Docker images published on docker.io/mailu for tags 1.5, 1.6, 1.7 and master are patched. For detailed instructions about patching and securing the server afterwards, see https://github.com/Mailu/Mailu/issues/1354
|
||||
|
||||
analysis: {"Image":"mailu","Reason":"漏洞是由于Mailu容器镜像中的fetchmail脚本存在安全问题，允许经过身份验证的用户利用该漏洞获得对Mailu实例的完全访问权限。","Consequence":"攻击者可以借此获取对Mailu实例的完全控制，影响服务器安全性，严重程度高。"}
|
||||
|
||||
cve: ./data/2020/7xxx/CVE-2020-7606.json
|
||||
docker-compose-remote-api through 0.1.4 allows execution of arbitrary commands. Within 'index.js' of the package, the function 'exec(serviceName, cmd, fnStdout, fnStderr, fnExit)' uses the variable 'serviceName' which can be controlled by users without any sanitization.
|
||||
|
||||
analysis: {"Image":"docker-compose-remote-api","Reason":"The vulnerability arises from unsanitized user input in the 'serviceName' variable within the 'exec' function, which can be exploited to execute arbitrary commands.","Consequence":"This CVE allows attackers to execute arbitrary commands on the host system, leading to potential system compromise and data loss. It is a critical severity vulnerability."}
|
||||
|
||||
cve: ./data/2020/8xxx/CVE-2020-8553.json
|
||||
The Kubernetes ingress-nginx component prior to version 0.28.0 allows a user with the ability to create namespaces and to read and create ingress objects to overwrite the password file of another ingress which uses nginx.ingress.kubernetes.io/auth-type: basic and which has a hyphenated namespace or secret name.
|
||||
|
||||
analysis: {"Image":"ingress-nginx","Reason":"The vulnerability arises from the way the ingress-nginx component handles password files in namespaces with hyphenated names or secret names, which could be manipulated by a user with specific permissions.","Consequence":"An attacker could overwrite the password file of another ingress, leading to potential unauthorized access and compromise of security, with severity being high."}
|
||||
|
||||
cve: ./data/2020/8xxx/CVE-2020-8907.json
|
||||
A vulnerability in Google Cloud Platform's guest-oslogin versions between 20190304 and 20200507 allows a user that is only granted the role "roles/compute.osLogin" to escalate privileges to root. Using their membership to the "docker" group, an attacker with this role is able to run docker and mount the host OS. Within docker, it is possible to modify the host OS filesystem and modify /etc/groups to gain administrative privileges. All images created after 2020-May-07 (20200507) are fixed, and if you cannot update, we recommend you edit /etc/group/security.conf and remove the "docker" user from the OS Login entry.
|
||||
|
||||
analysis: {"Image":"Google Cloud Platform's guest-oslogin","Reason":"该漏洞是由于容器镜像中用户被错误地赋予了docker组权限，导致可以运行docker并挂载宿主机文件系统","Consequence":"攻击者可借此将自身权限提升至root，对宿主机系统进行任意修改，后果严重"}
|
||||
|
||||
cve: ./data/2020/8xxx/CVE-2020-8945.json
|
||||
The proglottis Go wrapper before 0.1.1 for the GPGME library has a use-after-free, as demonstrated by use for container image pulls by Docker or CRI-O. This leads to a crash or potential code execution during GPG signature verification.
|
||||
|
||||
analysis: {"Image":"container image","Reason":"The vulnerability exists in the proglottis Go wrapper used for GPGME library during container image pulls by Docker or CRI-O, which is related to the handling of operations in the container image context.","Consequence":"This leads to a crash or potential code execution during GPG signature verification."}
|
||||
|
||||
cve: ./data/2021/1xxx/CVE-2021-1559.json
|
||||
Multiple vulnerabilities in Cisco DNA Spaces Connector could allow an authenticated, remote attacker to perform a command injection attack on an affected device. These vulnerabilities are due to insufficient input sanitization when executing affected commands. A high-privileged attacker could exploit these vulnerabilities on a Cisco DNA Spaces Connector by injecting crafted input during command execution. A successful exploit could allow the attacker to execute arbitrary commands as root within the Connector docker container.
|
||||
|
||||
analysis: {"Image":"Cisco DNA Spaces Connector","Reason":"漏洞是由于在执行受影响命令时未能正确对输入进行消毒，导致攻击者可以注入精心构造的输入","Consequence":"攻击者可能以root权限在Connector容器内执行任意命令，可能导致容器被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2021/1xxx/CVE-2021-1560.json
|
||||
Multiple vulnerabilities in Cisco DNA Spaces Connector could allow an authenticated, remote attacker to perform a command injection attack on an affected device. These vulnerabilities are due to insufficient input sanitization when executing affected commands. A high-privileged attacker could exploit these vulnerabilities on a Cisco DNA Spaces Connector by injecting crafted input during command execution. A successful exploit could allow the attacker to execute arbitrary commands as root within the Connector docker container.
|
||||
|
||||
analysis: {"Image":"Cisco DNA Spaces Connector","Reason":"The vulnerability is due to insufficient input sanitization when executing commands within the Docker container, allowing an attacker to inject crafted input during command execution.","Consequence":"A successful exploit could allow the attacker to execute arbitrary commands as root within the Connector docker container, leading to a complete compromise of the container environment with high severity."}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20182.json
|
||||
A privilege escalation flaw was found in openshift4/ose-docker-builder. The build container runs with high privileges using a chrooted environment instead of runc. If an attacker can gain access to this build container, they can potentially utilize the raw devices of the underlying node, such as the network and storage devices, to at least escalate their privileges to that of the cluster admin. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
|
||||
|
||||
analysis: {"Image":"openshift4/ose-docker-builder","Reason":"容器镜像在构建时使用chrooted环境而非runc，导致运行权限过高","Consequence":"攻击者可利用此漏洞访问底层节点的原始设备（如网络和存储设备），至少可提升权限至集群管理员级别，对数据机密性、完整性以及系统可用性造成严重威胁"}
|
||||
|
||||
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: {"Image":"IBM Security Access Manager 9.0 and IBM Security Verify Access Docker 10.0.0","Reason":"Stores user credentials in plain clear text","Consequence":"User credentials can be read by unauthorized users, leading to potential security breaches."}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20497.json
|
||||
IBM Security Verify Access Docker 10.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 197969
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"使用了比预期弱的加密算法","Consequence":"可能导致攻击者解密高度敏感信息，存在严重安全风险"}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20498.json
|
||||
IBM Security Verify Access Docker 10.0.0 reveals version information in HTTP requests that could be used in further attacks against the system. IBM X-Force ID: 197972.
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"The vulnerability is introduced in the container image where version information is exposed in HTTP requests, which could be exploited by attackers to gain insights for further attacks.","Consequence":"Exposure of internal version details can lead to targeted exploitation, potentially compromising system security. This issue poses a moderate to high risk depending on the deployment environment."}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20499.json
|
||||
IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 197973
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像配置不当导致详细技术错误信息泄露","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: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中存在安全漏洞可能导致敏感信息泄露","Consequence":"本地特权用户可能获取高度敏感信息，造成信息泄露，严重程度高"}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20510.json
|
||||
IBM Security Verify Access Docker 10.0.0 stores user credentials in plain clear text which can be read by a local user. IBM X-Force ID: 198299
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中以明文形式存储用户凭证，这些信息可被本地用户读取","Consequence":"攻击者可以获取敏感的用户凭证信息，进而可能导致进一步的安全威胁，例如身份冒充和数据泄露。CVSS评分为中高风险。"}
|
||||
|
||||
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: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中对URL请求的'../'序列处理不当，导致攻击者可构造恶意请求访问任意文件","Consequence":"攻击者可以遍历目录并访问系统上的任意文件，可能导致敏感信息泄露，严重程度高"}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20523.json
|
||||
IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 198660
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像在处理错误信息时返回了详细的敏感技术信息","Consequence":"攻击者可利用该信息发起进一步攻击，存在安全风险"}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20524.json
|
||||
IBM Security Verify Access Docker 10.0.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 198661.
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中的Web UI存在跨站脚本漏洞，允许攻击者嵌入恶意JavaScript代码","Consequence":"可能导致在可信会话中泄露用户凭证，存在安全风险"}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20533.json
|
||||
IBM Security Verify Access Docker 10.0.0 could allow a remote authenticated attacker to execute arbitrary commands on the system by sending a specially crafted request. IBM X-Force ID: 198813
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"CVE描述中提到该漏洞存在于IBM Security Verify Access Docker 10.0.0版本中，表明是容器镜像引入的问题","Consequence":"远程认证攻击者可以通过发送特制请求在系统上执行任意命令，这可能导致完全的系统控制权丧失，严重程度高"}
|
||||
|
||||
cve: ./data/2021/20xxx/CVE-2021-20534.json
|
||||
IBM Security Verify Access Docker 10.0.0 could allow a remote attacker to conduct phishing attacks, using an open redirect attack. By persuading a victim to visit a specially crafted Web site, a remote attacker could exploit this vulnerability to spoof the URL displayed to redirect a user to a malicious Web site that would appear to be trusted. This could allow the attacker to obtain highly sensitive information or conduct further attacks against the victim. IBM X-Force ID: 198814
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中存在开放重定向漏洞，可被远程攻击者利用进行网络钓鱼攻击","Consequence":"攻击者可欺骗用户访问恶意网站，导致敏感信息泄露或进一步的攻击，严重程度高"}
|
||||
|
||||
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: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中包含硬编码凭证（如密码或加密密钥），这些凭证用于自身的入站认证、与外部组件的出站通信或内部数据加密","Consequence":"攻击者可能利用这些硬编码凭证获取未授权访问权限，进而导致敏感信息泄露或系统被恶意控制，严重程度高"}
|
||||
|
||||
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
|
||||
{
|
||||
"Image": "bitnami/laravel",
|
||||
"Reason": "容器镜像构建时生成的 /tmp/app/.env 文件中固定了 APP_KEY 的值，未在容器运行时动态生成随机密钥。",
|
||||
"Consequence": "攻击者若获取到固定的 APP_KEY，可以利用该密钥构造恶意 cookie 值，进而通过 PHP 对象序列化/反序列化漏洞执行任意类方法，导致严重的安全风险。此漏洞影响较大，可能造成远程代码执行或会话伪造等后果。"
|
||||
}
|
||||
```
|
||||
|
||||
cve: ./data/2021/23xxx/CVE-2021-23732.json
|
||||
This affects all versions of package docker-cli-js. If the command parameter of the Docker.command method can at least be partially controlled by a user, they will be in a position to execute any arbitrary OS commands on the host system.
|
||||
|
||||
analysis: {"Image":"docker-cli-js","Reason":"The CVE is introduced due to the Docker.command method allowing user-controlled input to execute arbitrary OS commands","Consequence":"Remote code execution on the host system, leading to a critical security risk"}
|
||||
|
||||
cve: ./data/2021/27xxx/CVE-2021-27886.json
|
||||
rakibtg Docker Dashboard before 2021-02-28 allows command injection in backend/utilities/terminal.js via shell metacharacters in the command parameter of an API request. NOTE: this is NOT a Docker, Inc. product.
|
||||
|
||||
analysis: {"Image":"rakibtg Docker Dashboard","Reason":"该CVE是由于容器镜像中包含的程序在处理API请求时未正确过滤特殊字符，导致攻击者可以注入恶意命令。","Consequence":"远程攻击者可以通过构造特定请求以执行任意命令，可能导致系统被控制，严重程度较高。"}
|
||||
|
||||
cve: ./data/2021/29xxx/CVE-2021-29251.json
|
||||
BTCPay Server before 1.0.7.1 mishandles the policy setting in which users can register (in Server Settings > Policies). This affects Docker use cases in which a mail server is configured.
|
||||
|
||||
analysis: {"Image":"BTCPay Server","Reason":"The vulnerability arises from misconfiguration in the container image's policy handling when a mail server is configured in Docker use cases","Consequence":"Unauthenticated users may be able to register, leading to potential unauthorized access and security breaches. This affects the application's integrity and confidentiality."}
|
||||
|
||||
cve: ./data/2021/29xxx/CVE-2021-29475.json
|
||||
HedgeDoc (formerly known as CodiMD) is an open-source collaborative markdown editor. An attacker is able to receive arbitrary files from the file system when exporting a note to PDF. Since the code injection has to take place as note content, there fore this exploit requires the attackers ability to modify a note. This will affect all instances, which have pdf export enabled. This issue has been fixed by https://github.com/hedgedoc/hedgedoc/commit/c1789474020a6d668d616464cb2da5e90e123f65 and is available in version 1.5.0. Starting the CodiMD/HedgeDoc instance with `CMD_ALLOW_PDF_EXPORT=false` or set `"allowPDFExport": false` in config.json can mitigate this issue for those who cannot upgrade. This exploit works because while PhantomJS doesn't actually render the `file:///` references to the PDF file itself, it still uses them internally, and exfiltration is possible, and easy through JavaScript rendering. The impact is pretty bad, as the attacker is able to read the CodiMD/HedgeDoc `config.json` file as well any other files on the filesystem. Even though the suggested Docker deploy option doesn't have many interesting files itself, the `config.json` still often contains sensitive information, database credentials, and maybe OAuth secrets among other things.
|
||||
|
||||
analysis: {"Image":"CodiMD/HedgeDoc","Reason":"The CVE is introduced through the application's functionality to export notes to PDF using PhantomJS, which allows attackers to read arbitrary files from the file system when exploiting this vulnerability.","Consequence":"Attackers can exfiltrate sensitive files such as config.json, which may contain database credentials, OAuth secrets, and other critical information, leading to potential data breaches and unauthorized access."}
|
||||
|
||||
cve: ./data/2021/29xxx/CVE-2021-29641.json
|
||||
Directus 8 before 8.8.2 allows remote authenticated users to execute arbitrary code because file-upload permissions include the ability to upload a .php file to the main upload directory and/or upload a .php file and a .htaccess file to a subdirectory. Exploitation succeeds only for certain installations with the Apache HTTP Server and the local-storage driver (e.g., when the product was obtained from hub.docker.com).
|
||||
|
||||
analysis: {"Image":"directus","Reason":"容器镜像中文件上传权限配置不当，允许上传恶意PHP文件","Consequence":"远程认证用户可上传恶意文件并执行任意代码，导致系统被控制，严重程度高"}
|
||||
|
||||
cve: ./data/2021/29xxx/CVE-2021-29699.json
|
||||
IBM Security Verify Access Docker 10.0.0 could allow a remote priviled user to upload arbitrary files with a dangerous file type that could be excuted by an user. IBM X-Force ID: 200600.
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像允许远程特权用户上传可由用户执行的危险文件类型","Consequence":"该CVE可能导致任意文件上传和执行，从而导致安全漏洞，严重程度高"}
|
||||
|
||||
cve: ./data/2021/29xxx/CVE-2021-29742.json
|
||||
IBM Security Verify Access Docker 10.0.0 could allow a user to impersonate another user on the system. IBM X-Force ID: 201483.
|
||||
|
||||
analysis: {"Image":"IBM Security Verify Access Docker","Reason":"容器镜像中存在用户身份验证缺陷，可能导致用户身份被冒充","Consequence":"攻击者可以利用此漏洞伪装成其他用户，进而进行未授权访问或执行恶意操作，属于高危漏洞"}
|
||||
|
||||
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: {"Image":"Windows Tentacle docker image","Reason":"The vulnerability is introduced due to logging of command-line arguments in plaintext at startup, which includes the Octopus Server API key","Consequence":"Exposure of sensitive API key information in logs, leading to potential unauthorized access; this affects only the Windows Docker image"}
|
||||
|
||||
cve: ./data/2021/33xxx/CVE-2021-33183.json
|
||||
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.
|
||||
|
||||
analysis: {"Image":"Synology Docker","Reason":"Path Traversal漏洞允许本地用户通过未指定的向量读取或写入任意文件","Consequence":"攻击者可以利用此漏洞绕过目录访问限制，可能导致敏感信息泄露或系统文件被篡改，严重程度较高"}
|
||||
|
||||
cve: ./data/2021/34xxx/CVE-2021-34079.json
|
||||
OS Command injection vulnerability in Mintzo Docker-Tester through 1.2.1 allows attackers to execute arbitrary commands via shell metacharacters in the 'ports' entry of a crafted docker-compose.yml file.
|
||||
|
||||
analysis: {"Image":"Mintzo Docker-Tester","Reason":"该CVE是由于在容器镜像中对docker-compose.yml文件的'ports'条目处理不当，导致攻击者可以注入shell元字符执行任意命令","Consequence":"攻击者可以执行任意命令，从而可能导致系统被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2021/35xxx/CVE-2021-35497.json
|
||||
The FTL Server (tibftlserver) and Docker images containing tibftlserver components of TIBCO Software Inc.'s TIBCO ActiveSpaces - Community Edition, TIBCO ActiveSpaces - Developer Edition, TIBCO ActiveSpaces - Enterprise Edition, TIBCO FTL - Community Edition, TIBCO FTL - Developer Edition, TIBCO FTL - Enterprise Edition, TIBCO eFTL - Community Edition, TIBCO eFTL - Developer Edition, and TIBCO eFTL - Enterprise Edition contain a vulnerability that theoretically allows a non-administrative, authenticated FTL user to trick the affected components into creating illegitimate certificates. These maliciously generated certificates can be used to enable man-in-the-middle attacks or to escalate privileges so that the malicious user has administrative privileges. Affected releases are TIBCO Software Inc.'s TIBCO ActiveSpaces - Community Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO ActiveSpaces - Developer Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO ActiveSpaces - Enterprise Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO FTL - Community Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO FTL - Developer Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO FTL - Enterprise Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO eFTL - Community Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO eFTL - Developer Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, and TIBCO eFTL - Enterprise Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0.
|
||||
|
||||
analysis: {"Image":"tibftlserver","Reason":"The vulnerability exists in the FTL Server (tibftlserver) and Docker images containing tibftlserver components, where a non-administrative, authenticated FTL user can trick the affected components into generating illegitimate certificates.","Consequence":"These malicious certificates can enable man-in-the-middle attacks or privilege escalation, allowing the attacker to gain administrative privileges. This is a high-severity security issue."}
|
||||
|
||||
cve: ./data/2021/37xxx/CVE-2021-37353.json
|
||||
Nagios XI Docker Wizard before version 1.1.3 is vulnerable to SSRF due to improper sanitation in table_population.php.
|
||||
|
||||
analysis: {"Image":"Nagios XI Docker Wizard","Reason":"Improper sanitation in table_population.php could lead to Server Side Request Forgery (SSRF)","Consequence":"An attacker could potentially exploit this vulnerability to perform unauthorized requests, leading to data exposure or further attacks. This poses a significant security risk."}
|
||||
|
||||
cve: ./data/2021/39xxx/CVE-2021-39159.json
|
||||
BinderHub is a kubernetes-based cloud service that allows users to share reproducible interactive computing environments from code repositories. In affected versions a remote code execution vulnerability has been identified in BinderHub, where providing BinderHub with maliciously crafted input could execute code in the BinderHub context, with the potential to egress credentials of the BinderHub deployment, including JupyterHub API tokens, kubernetes service accounts, and docker registry credentials. This may provide the ability to manipulate images and other user created pods in the deployment, with the potential to escalate to the host depending on the underlying kubernetes configuration. Users are advised to update to version 0.2.0-n653. If users are unable to update they may disable the git repo provider by specifying the `BinderHub.repo_providers` as a workaround.
|
||||
|
||||
analysis: {"Image":"BinderHub","Reason":"BinderHub的远程代码执行漏洞源于处理恶意输入时在BinderHub上下文中执行代码","Consequence":"攻击者可以窃取BinderHub部署中的凭证（如JupyterHub API令牌、Kubernetes服务账户和Docker注册表凭据），从而操控镜像和其他用户创建的Pod，严重程度高，可能进一步升级到主机"}
|
||||
|
||||
cve: ./data/2021/39xxx/CVE-2021-39939.json
|
||||
An uncontrolled resource consumption vulnerability in GitLab Runner affecting all versions starting from 13.7 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, allows an attacker triggering a job with a specially crafted docker image to exhaust resources on runner manager
|
||||
|
||||
analysis: {"Image":"GitLab Runner","Reason":"触发一个经过特殊构建的docker镜像作业导致资源消耗","Consequence":"攻击者可耗尽runner manager上的系统资源（如CPU或内存），可能导致服务不可用，严重程度高。"}
|
||||
|
||||
cve: ./data/2021/3xxx/CVE-2021-3193.json
|
||||
Improper access and command validation in the Nagios Docker Config Wizard before 1.1.2, as used in Nagios XI through 5.7, allows an unauthenticated attacker to execute remote code as the apache user.
|
||||
|
||||
analysis: {"Image":"Nagios Docker Config Wizard","Reason":"Improper access and command validation during container configuration allows unauthenticated attackers to exploit the vulnerability.","Consequence":"Remote code execution as the apache user, which can lead to full system compromise. This is a critical severity issue."}
|
||||
|
||||
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: {"Image":"Buildah","Reason":"容器构建过程中通过chroot隔离运行时，子进程可以访问父进程和祖父进程的环境变量","Consequence":"可能导致敏感信息（如容器仓库凭证）泄露，严重程度中等至高危，尤其在CI/CD环境中"}
|
||||
|
||||
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: {"Image":"docker-cli","Reason":"The CVE is introduced due to a misconfiguration in the Docker CLI's credential handling process when interacting with private registries, which could be triggered by a flawed configuration in the container image.","Consequence":"Credentials intended for a private registry may be mistakenly sent to `registry-1.docker.io`, leading to potential exposure of sensitive authentication information. This poses a serious security risk, especially in environments where private registry credentials are used frequently."}
|
||||
|
||||
cve: ./data/2021/41xxx/CVE-2021-41130.json
|
||||
Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management capabilities for JSON/REST or gRPC API services. ESPv1 can be configured to authenticate a JWT token. Its verified JWT claim is passed to the application by HTTP header "X-Endpoint-API-UserInfo", the application can use it to do authorization. But if there are two "X-Endpoint-API-UserInfo" headers from the client, ESPv1 only replaces the first one, the 2nd one will be passed to the application. An attacker can send two "X-Endpoint-API-UserInfo" headers, the second one with a fake JWT claim. Application may use the fake JWT claim to do the authorization. This impacts following ESPv1 usages: 1) Users have configured ESPv1 to do JWT authentication with Google ID Token as described in the referenced google endpoint document. 2) Users backend application is using the info in the "X-Endpoint-API-UserInfo" header to do the authorization. It has been fixed by v1.58.0. You need to patch it in the following ways: * If your docker image is using tag ":1", needs to re-start the container to pick up the new version. The tag ":1" will automatically point to the latest version. * If your docker image tag pings to a specific minor version, e.g. ":1.57". You need to update it to ":1.58" and re-start the container. There are no workaround for this issue.
|
||||
|
||||
analysis: {"Image":"Extensible Service Proxy (ESPv1)","Reason":"The vulnerability arises when the ESPv1 proxy is configured in a Docker container and fails to properly handle duplicate 'X-Endpoint-API-UserInfo' headers, allowing a fake JWT claim to be passed to the application.","Consequence":"An attacker can bypass authorization by injecting a malicious 'X-Endpoint-API-UserInfo' header, leading to potential privilege escalation or unauthorized access. This issue affects containers using vulnerable ESPv1 versions and is only mitigated by upgrading to v1.58.0."}
|
||||
|
||||
cve: ./data/2021/41xxx/CVE-2021-41254.json
|
||||
kustomize-controller is a Kubernetes operator, specialized in running continuous delivery pipelines for infrastructure and workloads defined with Kubernetes manifests and assembled with Kustomize. Users that can create Kubernetes Secrets, Service Accounts and Flux Kustomization objects, could execute commands inside the kustomize-controller container by embedding a shell script in a Kubernetes Secret. This can be used to run `kubectl` commands under the Service Account of kustomize-controller, thus allowing an authenticated Kubernetes user to gain cluster admin privileges. In affected versions multitenant environments where non-admin users have permissions to create Flux Kustomization objects are affected by this issue. This vulnerability was fixed in kustomize-controller v0.15.0 (included in flux2 v0.18.0) released on 2021-10-08. Starting with v0.15, the kustomize-controller no longer executes shell commands on the container OS and the `kubectl` binary has been removed from the container image. To prevent the creation of Kubernetes Service Accounts with `secrets` in namespaces owned by tenants, a Kubernetes validation webhook such as Gatekeeper OPA or Kyverno can be used.
|
||||
|
||||
analysis: {"Image":"kustomize-controller","Reason":"The vulnerability arises from the kustomize-controller container allowing execution of shell scripts via embedded Kubernetes Secrets, and executing `kubectl` commands under its Service Account.","Consequence":"An authenticated Kubernetes user could exploit this to gain cluster admin privileges, leading to a critical security breach in multitenant environments."}
|
||||
|
||||
cve: ./data/2021/43xxx/CVE-2021-43842.json
|
||||
Wiki.js is a wiki app built on Node.js. Wiki.js versions 2.5.257 and earlier are vulnerable to stored cross-site scripting through a SVG file upload. By creating a crafted SVG file, a malicious Wiki.js user may stage a stored cross-site scripting attack. This allows the attacker to execute malicious JavaScript when the SVG is viewed directly by other users. Scripts do not execute when loaded inside a page via normal `<img>` tags. Commit 5d3e81496fba1f0fbd64eeb855f30f69a9040718 fixes this vulnerability by adding an optional (enabled by default) SVG sanitization step to all file uploads that match the SVG mime type. As a workaround, disable file upload for all non-trusted users. Wiki.js version 2.5.260 is the first production version to contain a patch. Version 2.5.258 is the first development build to contain a patch and is available only as a Docker image as requarks/wiki:canary-2.5.258.
|
||||
|
||||
analysis: {"Image":"requarks/wiki","Reason":"The vulnerability arises from improper handling of SVG file uploads in the Wiki.js application, which could be exploited through a crafted SVG file uploaded by a malicious user.","Consequence":"Successful exploitation allows an attacker to perform stored cross-site scripting (XSS), leading to execution of malicious JavaScript when the SVG is viewed directly by other users. This can compromise user sessions or perform other malicious actions within the context of the affected application."}
|
||||
|
||||
cve: ./data/2021/45xxx/CVE-2021-45414.json
|
||||
A Remote Code Execution (RCE) vulnerability exists in DataRobot through 2021-10-28 because it allows submission of a Docker environment or Java driver.
|
||||
|
||||
analysis: {"Image":"DataRobot","Reason":"容器镜像允许提交恶意Docker环境或Java驱动程序","Consequence":"攻击者可利用该漏洞执行远程代码，导致系统被控制，严重程度高"}
|
||||
|
||||
cve: ./data/2022/20xxx/CVE-2022-20617.json
|
||||
Jenkins Docker Commons Plugin 1.17 and earlier does not sanitize the name of an image or a tag, resulting in an OS command execution vulnerability exploitable by attackers with Item/Configure permission or able to control the contents of a previously configured job's SCM repository.
|
||||
|
||||
analysis: {"Image":"Jenkins Docker Commons Plugin","Reason":"插件未对镜像或标签名称进行正确清理，可能导致恶意命令执行","Consequence":"攻击者可以执行任意操作系统命令，可能导致系统被完全控制，严重程度高"}
|
||||
|
||||
cve: ./data/2022/22xxx/CVE-2022-22984.json
|
||||
The package snyk before 1.1064.0; the package snyk-mvn-plugin before 2.31.3; the package snyk-gradle-plugin before 3.24.5; the package @snyk/snyk-cocoapods-plugin before 2.5.3; the package snyk-sbt-plugin before 2.16.2; the package snyk-python-plugin before 1.24.2; the package snyk-docker-plugin before 5.6.5; the package @snyk/snyk-hex-plugin before 1.1.6 are vulnerable to Command Injection due to an incomplete fix for [CVE-2022-40764](https://security.snyk.io/vuln/SNYK-JS-SNYK-3037342). A successful exploit allows attackers to run arbitrary commands on the host system where the Snyk CLI is installed by passing in crafted command line flags. In order to exploit this vulnerability, a user would have to execute the snyk test command on untrusted files. In most cases, an attacker positioned to control the command line arguments to the Snyk CLI would already be positioned to execute arbitrary commands. However, this could be abused in specific scenarios, such as continuous integration pipelines, where developers can control the arguments passed to the Snyk CLI to leverage this component as part of a wider attack against an integration/build pipeline. This issue has been addressed in the latest Snyk Docker images available at https://hub.docker.com/r/snyk/snyk as of 2022-11-29. Images downloaded and built prior to that date should be updated. The issue has also been addressed in the Snyk TeamCity CI/CD plugin as of version v20221130.093605.
|
||||
|
||||
analysis: {"Image":"snyk/snyk","Reason":"该CVE是由于Snyk CLI在处理命令行参数时存在命令注入漏洞，而该CLI被包含在容器镜像中。攻击者可通过构造恶意参数执行任意命令","Consequence":"攻击者可以利用此漏洞在运行该容器并执行snyk test命令时，在宿主机上执行任意命令，从而对CI/CD流水线造成严重安全威胁，属于高危漏洞"}
|
||||
|
||||
cve: ./data/2022/23xxx/CVE-2022-23126.json
|
||||
TeslaMate before 1.25.1 (when using the default Docker configuration) allows attackers to open doors of Tesla vehicles, start Keyless Driving, and interfere with vehicle operation en route. This occurs because an attacker can leverage Grafana login access to obtain a token for Tesla API calls.
|
||||
|
||||
analysis: {"Image":"TeslaMate","Reason":"The vulnerability exists in TeslaMate's default Docker configuration, where an attacker can exploit Grafana login access to obtain a token for Tesla API calls","Consequence":"Attackers can open Tesla vehicle doors, start Keyless Driving, and interfere with vehicle operation, leading to serious security and safety risks"}
|
||||
|
||||
cve: ./data/2022/24xxx/CVE-2022-24799.json
|
||||
wire-webapp is the web application interface for the wire messaging service. Insufficient escaping in markdown “code highlighting” in the wire-webapp resulted in the possibility of injecting and executing arbitrary HTML code and thus also JavaScript. If a user receives and views such a malicious message, arbitrary code is injected and executed in the context of the victim. This allows the attacker to fully control the user account. Wire-desktop clients that are connected to a vulnerable wire-webapp version are also vulnerable to this attack. The issue has been fixed in wire-webapp 2022-03-30-production.0 and is already deployed on all Wire managed services. On-premise instances of wire-webapp need to be updated to docker tag 2022-03-30-production.0-v0.29.2-0-d144552 or wire-server 2022-03-30 (chart/4.8.0), so that their applications are no longer affected. There are no known workarounds for this issue. ### Patches * The issue has been fixed in wire-webapp **2022-03-30-production.0** and is already deployed on all Wire managed services. * On-premise instances of wire-webapp need to be updated to docker tag **2022-03-30-production.0-v0.29.2-0-d144552** or wire-server **2022-03-30 (chart/4.8.0)**, so that their applications are no longer affected. ### Workarounds * No workarounds known ### For more information If you have any questions or comments about this advisory feel free to email us at [vulnerability-report@wire.com](mailto:vulnerability-report@wire.com) ### Credits We thank [Posix](https://twitter.com/po6ix) for reporting this vulnerability
|
||||
|
||||
analysis: {"Image":"wire-webapp","Reason":"Insufficient escaping in markdown code highlighting allows injection and execution of arbitrary HTML/JavaScript code","Consequence":"Attackers can fully control the user account by injecting malicious code when a user views a crafted message; affects both web and desktop clients connected to vulnerable versions"}
|
||||
|
||||
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: {"Image":"Docker Desktop","Reason":"容器镜像创建或处理文件时存在安全缺陷，攻击者可利用该缺陷移动任意文件","Consequence":"可能导致宿主机上的文件被非法操作，造成数据泄露或破坏，严重程度高"}
|
||||
|
||||
cve: ./data/2022/25xxx/CVE-2022-25914.json
|
||||
The package com.google.cloud.tools:jib-core before 0.22.0 are vulnerable to Remote Code Execution (RCE) via the isDockerInstalled function, due to attempting to execute input.
|
||||
|
||||
analysis: {"Image":"[com.google.cloud.tools:jib-core]","Reason":"[The vulnerability arises when the container image uses jib-core package before version 0.22.0, which attempts to execute input in the isDockerInstalled function]","Consequence":"[This CVE allows Remote Code Execution (RCE), which can lead to unauthorized code execution within the container or host system. This is a critical severity vulnerability]"}
|
||||
|
||||
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: {"Image":"buildah","Reason":"容器可能被错误地启动了非空的默认权限，导致攻击者可以利用可继承的文件功能提升其能力","Consequence":"可能导致保密性和完整性的损害，存在安全风险"}
|
||||
|
||||
84
build_ai_analysis.py
Normal file
84
build_ai_analysis.py
Normal file
@@ -0,0 +1,84 @@
|
||||
# 分析每个CVE源自哪个应用程序、什么原因、什么后果等信息
|
||||
|
||||
from os import truncate
|
||||
import re
|
||||
import json
|
||||
from openai import OpenAI
|
||||
from typing import Dict, List, Any
|
||||
|
||||
|
||||
def process_result(data: Any) -> str:
|
||||
# target_key = "choices.0.message.content"
|
||||
parts = ["choices", "0", "message", "content"]
|
||||
try:
|
||||
for part in parts:
|
||||
if isinstance(data, list):
|
||||
data = data[int(part)]
|
||||
else:
|
||||
data = data.get(part, None)
|
||||
if data is None:
|
||||
break
|
||||
return data
|
||||
except (KeyError, IndexError, TypeError):
|
||||
return "N/A"
|
||||
return "N/A"
|
||||
|
||||
|
||||
def analyze_with_ai(data: str) -> str:
|
||||
prompt = """
|
||||
你是一个计算机容器安全领域的专家，能够根据CVE描述分析出CVE产生于哪个程序、有何影响后果等信息。
|
||||
下面我会发给你一段文本，第一行是CVE的编号与文件位置信息，后续是这个CVE的详细描述。
|
||||
请分析我发送给你的CVE详细描述内容，并进行分析，我有如下要求：
|
||||
1. 分析这个CVE信息，判断这个CVE漏洞是否是由于在构建容器镜像过程中由Dockerfile或其他脚本引入的；
|
||||
2. 如果不满足条件1，你只需返回"N/A"即可，无需任何多余信息；
|
||||
3. 如果这个CVE满足条件1，那么你只需要直接返回一个json，这个json样例如下：
|
||||
{"Conatiner":"[存在CVE的容器镜像]","CVE_Reason"："[容器泄漏或未妥善保护的文件、密钥等敏感信息类型]"，"CVE_Consequence":"[该CVE的后果，以及严重程度]"}
|
||||
请牢记，你必须只返回json内容，除了json不需要任何文本内容，并且尽量使用中文。
|
||||
"""
|
||||
|
||||
client = OpenAI(
|
||||
api_key="sk-5ec7751941974a9cb5855f746fe45a62",
|
||||
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
|
||||
)
|
||||
try:
|
||||
completion = client.chat.completions.create(
|
||||
# 模型列表：https://help.aliyun.com/zh/model-studio/getting-started/models
|
||||
model="qwen-plus",
|
||||
messages=[
|
||||
{"role": "system", "content": prompt},
|
||||
{"role": "user", "content": data},
|
||||
],
|
||||
# Qwen3模型通过enable_thinking参数控制思考过程（开源版默认True，商业版默认False）
|
||||
# 使用Qwen3开源版模型时，若未启用流式输出，请将下行取消注释，否则会报错
|
||||
# extra_body={"enable_thinking": False},
|
||||
)
|
||||
return process_result(json.loads(completion.model_dump_json()))
|
||||
except Exception as e:
|
||||
print(f"调用大模型失败: {str(e)}")
|
||||
return "N/A"
|
||||
return "N/A"
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
pattern = r"\./data/.*x/CVE.*?\.json"
|
||||
regex = re.compile(pattern)
|
||||
|
||||
with open("keyword_filter_21-25.log", "r", encoding="utf-8") as file:
|
||||
text = file.read()
|
||||
matches = list(regex.finditer(text))
|
||||
|
||||
log = open("./build_result/analysis_result_21-25.log", "w", encoding="utf-8")
|
||||
|
||||
# 如果没有找到任何匹配项
|
||||
if not matches:
|
||||
print("No match found.")
|
||||
else:
|
||||
for i in range(len(matches)):
|
||||
start = matches[i].start()
|
||||
# 如果不是最后一个匹配项，则end是下一个匹配项的起始位置；否则为文本末尾
|
||||
end = matches[i + 1].start() if i + 1 < len(matches) else len(text)
|
||||
block = text[start:end].strip()
|
||||
ans = analyze_with_ai(block)
|
||||
if ans == "N/A":
|
||||
continue
|
||||
log.write(f"cve: {block}\n\nanalysis: {ans}\n\n")
|
||||
305
build_result/analysis_result_21-25.log
Normal file
305
build_result/analysis_result_21-25.log
Normal file
@@ -0,0 +1,305 @@
|
||||
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":"导致原本无权限访问符号链接内容的用户可以通过本地工作区访问这些内容，可能引发敏感信息泄露，严重程度为中高"}
|
||||
|
||||
Reference in New Issue
Block a user