WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Product docker✕
Overview 2 matches · 0 in Waratek scope · 0 protected · 1 CISA KEV · 1 EPSS ≥ 0.5
2matches 0in Waratek scope0.0% 0protected0.0% 1CISA KEV50.0% 1EPSS ≥ 0.550.0%
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 50.0% Not applicable 1 50.0% Withdrawn CVE 0 0.0%
Critical 0 0.0% High 2 100.0% Medium 0 0.0% 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 2 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 2 100.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 0 0.0%
split by peak 1 / month
Not applicable: 1Outside Waratek scope: 1 High: 2 not blocked: 2 Exploited: 2
Feb 191 Outside Waratek scope1 High1 not blocked1 Exploited1 Mar 190 Apr 190 May 190 Jun 190 Jul 190 Aug 191 Not applicable1 High1 not blocked1 Exploited1
Feb 19Mar 19Apr 19May 19Jun 19Jul 19Aug 19
2 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-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.