WaratekVRT Sign in
Reset
More filters (2)
Columns
Including CVEs outside Waratek scope✕Vendor docker✕Has a public PoC✕
Overview 3 matches · 0 in Waratek scope · 0 protected · 2 exploited · 1 CISA KEV · 1 EPSS ≥ 0.5
3matches 0in Waratek scope0.0% 0protected0.0% 2exploited66.7% 1CISA KEV33.3% 1EPSS ≥ 0.533.3%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0% Outside Waratek scope 1 33.3% Not applicable 2 66.7% Withdrawn CVE 0 0.0%
Critical 0 0.0% High 2 66.7% Medium 1 33.3% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 3 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 2 66.7% Working exploit published 0 0.0% Proof of concept only 1 33.3% Forecast only 0 0.0% No public exploit 0 0.0%
split by peak 1 / month
Mar 19May 19Jul 19Sep 19Nov 19Jan 20Mar 20
3 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2020-10665 Medium 2020-03-18 Not applicable Proof of concept only Docker Desktop allows local privilege escalation to NT AUTHORITY\SYSTEM because it mishandles the collection of diagnostics with Administrator privileges, leading to arbitrary DACL permissions overwrites and arbitrary file writes. This affects Docker Desktop Enterprise before 2.1.0.9, Docker Desktop for Windows Stable before 2.2.0.4, and Docker Desktop for Windows Edge before 2.2.2.0.
CVE-2019-15752 High 2019-08-28 Not applicable Exploited 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.
CVE-2019-5736 High 2019-02-11 Outside Waratek scope Exploited 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.