WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Vendor kubernetes✕
Overview 3 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 2 EPSS ≥ 0.5
3matches 0in Waratek scope0.0% 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 2EPSS ≥ 0.566.7%
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 0 0.0% Not applicable 3 100.0% Withdrawn CVE 0 0.0%
Critical 1 33.3% High 2 66.7% 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 3 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 3 100.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 0 0.0%
split by peak 1 / month
Dec 18Jan 19Feb 19Mar 19Apr 19May 19Jun 19Jul 19Aug 19Sep 19Oct 19
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-2019-11253 High 2019-10-17 Not applicable Working exploit published Improper input validation in the Kubernetes API server in versions v1.0-1.12 and versions prior to v1.13.12, v1.14.8, v1.15.5, and v1.16.2 allows authorized users to send malicious YAML or JSON payloads, causing the API server to consume excessive CPU or memory, potentially crashing and becoming unavailable. Prior to v1.14.0, default RBAC policy authorized anonymous users to submit requests that could trigger this vulnerability. Clusters upgraded from a version prior to v1.14.0 keep the more permissive policy by default for backwards compatibility.
CVE-2018-18264 High 2019-01-03 Not applicable Working exploit published Kubernetes Dashboard before 1.10.1 allows attackers to bypass authentication and use Dashboard's Service Account for reading secrets within the cluster.
CVE-2018-1002105 Critical 2018-12-05 Not applicable Working exploit published In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.