WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Product kubernetes engine✕
Overview 4 matches · 3 in Waratek scope · 1 protected · 1 exploited · 0 CISA KEV · 1 public PoC · 1 EPSS ≥ 0.5
Protected by Waratek 1 25.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 2 50.0% Outside Waratek scope 1 25.0% Not applicable 0 0.0% Withdrawn CVE 0 0.0%
Critical 0 0.0% High 2 50.0% Medium 2 50.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 25.0% partly blocked 0 0.0% not blocked 3 75.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 1 25.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 3 75.0%
split by peak 1 / month
Feb 19Apr 19Jun 19Aug 19Oct 19Dec 19Feb 20
4 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-2121 High 2020-02-12 Protected by Waratek No public exploit Jenkins Google Kubernetes Engine Plugin 0.8.0 and earlier does not configure its YAML parser to prevent the instantiation of arbitrary types, resulting in a remote code execution vulnerability.
CVE-2019-10445 Medium 2019-10-16 No exploit published No public exploit A missing permission check in Jenkins Google Kubernetes Engine Plugin 0.7.0 and earlier allowed attackers with Overall/Read permission to obtain limited information about the scope of a credential with an attacker-specified credentials ID.
CVE-2019-10365 Medium 2019-07-31 No exploit published No public exploit Jenkins Google Kubernetes Engine Plugin 0.6.2 and earlier created a temporary file containing a temporary access token in the project workspace, where it could be accessed by users with Job/Read permission.
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.