Kubernetes 1.16
Kubernetes 1.16
The Kubernetes 1.16 reached end of service life on Aug 4, 2020 — Kubernetes no longer ships security patches or fixes for it. Our third-party support keeps it safe to run: 24/7 engineers manage issues, remediate vulnerabilities, and help you maintain compliance.
24/7 engineers own your Kubernetes 1.16 incidents end to end.
Mitigation and patch-around guidance when the vendor no longer ships fixes.
Controls evidence and documentation that keep auditors satisfied.
Specifications
- product
- kubernetes
- release
- 1.16
- product Label
- Kubernetes
- release Label
- 1.16
- codename
- lts
- latest Version
- 1.16.15
- release Date
- 2019-09-18
- maintained
- source Url
- https://endoflife.date/kubernetes
Lifecycle Dates
- End of Service Life
- Aug 4, 2020
- Last OEM Support
- Aug 4, 2020
OEM vs. 3rd Party Support
See how third-party support compares to the vendor contract for Kubernetes 1.16 — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.
| Feature | OEM Support | 3rd Party Support |
|---|---|---|
| Post-EOSL Support | ||
| Break/Fix Support | Until EOSL | |
| 24/7 Monitoring | ||
| Vulnerability Scanning & Remediation | ||
| Managed Operations | ||
| Procedure & Configuration Review | ||
| Compliance & Audit Documentation | Limited | |
| Discounted Migration to Other Platforms |
Why Choose 3rd Party Support for Kubernetes 1.16?
Vulnerability Remediation
Scanning, mitigation and patch-around guidance for Kubernetes 1.16 when the vendor no longer ships fixes.
Compliance Maintenance
Procedure review, controls evidence and the documentation auditors ask for — maintained continuously, not scrambled at audit time.
24/7 Expert Support
Engineers who know this release monitor, manage and fix issues around the clock — break/fix to managed operations.
Kubernetes 1.16 Support: Frequently Asked Questions
Is the Kubernetes 1.16 still supported?
Kubernetes ended support for the Kubernetes 1.16 on Aug 4, 2020 — no more patches or fixes from the vendor. Third-party support keeps it covered: our engineers manage issues, remediate vulnerabilities, and help you maintain compliance for as long as you run it.
When is the Kubernetes 1.16 end of service life (EOSL) date?
Kubernetes lists the end of service life for the Kubernetes 1.16 as Aug 4, 2020.
Can I keep using the Kubernetes 1.16 after its EOSL date?
Yes. EOSL means Kubernetes stops issuing patches and support — the software itself keeps running. Third-party support covers it from there: issue management, security vulnerability remediation, and the compliance documentation auditors ask for, for as long as you choose to run it.
How much does third-party support for the Kubernetes 1.16 cost?
Typically 40-70% below the OEM maintenance renewal price. Exact pricing depends on quantity, service level and location — request a quote and we respond within 24 hours.
Known Vulnerabilities Affecting Kubernetes 1.16
30 published CVEs affect the Kubernetes 1.16, including 8 rated critical or high severity. Kubernetes no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.
| CVE | Severity | CVSS | Published | Summary |
|---|---|---|---|---|
| CVE-2016-1906 | CRITICAL | 9.8 | Feb 3, 2016 | Openshift allows remote attackers to gain privileges by updating a build configuration that was created with an allowed type to a type that is not allowed. |
| CVE-2023-3955 | HIGH | 8.8 | Oct 31, 2023 | A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes. |
| CVE-2023-3676 | HIGH | 8.8 | Oct 31, 2023 | A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes. |
| CVE-2021-25741 | HIGH | 8.8 | Sep 20, 2021 | A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem. |
| CVE-2016-1905 | HIGH | 7.7 | Feb 3, 2016 | The API server in Kubernetes does not properly check admission control, which allows remote authenticated users to access additional resources via a crafted patched object. |
| CVE-2019-11253 | HIGH | 7.5 | Oct 17, 2019 | 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 per |
| CVE-2016-7075 | HIGH | 7.5 | Sep 10, 2018 | It was found that Kubernetes as used by Openshift Enterprise 3 did not correctly validate X.509 client intermediate certificate host name fields. An attacker could use this flaw to bypass authentication requirements by using a specially crafted X.509 certificate. |
| CVE-2023-5528 | HIGH | 7.2 | Nov 14, 2023 | A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes. |
| CVE-2022-3294 | MEDIUM | 6.6 | Mar 1, 2023 | Users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them. Kubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. B |
| CVE-2023-2728 | MEDIUM | 6.5 | Jul 3, 2023 | Users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the `kubernetes.io/enforce-mountable-secrets` annotation are used together with ephemeral containers. |
| CVE-2023-2727 | MEDIUM | 6.5 | Jul 3, 2023 | Users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers. |
| CVE-2022-3162 | MEDIUM | 6.5 | Mar 1, 2023 | Users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization. Clusters are impacted by this vulnerability if all of the following are true: 1. There are 2+ CustomResourceDefinitions sharing the same API group 2. Users have cluster-wide list or watch authorization on one of those custom resources. 3. The same users are not authorized to read another custom resource in the same API gr |
| CVE-2021-25735 | MEDIUM | 6.5 | Sep 6, 2021 | A security issue was discovered in kube-apiserver that could allow node updates to bypass a Validating Admission Webhook. Clusters are only affected by this vulnerability if they run a Validating Admission Webhook for Nodes that denies admission based at least partially on the old state of the Node object. Validating Admission Webhook does not observe some previous fields. |
| CVE-2019-11254 | MEDIUM | 6.5 | Apr 1, 2020 | The Kubernetes API Server component in versions 1.1-1.14, and versions prior to 1.15.10, 1.16.7 and 1.17.3 allows an authorized user who sends malicious YAML payloads to cause the kube-apiserver to consume excessive CPU cycles while parsing YAML. |
| CVE-2019-11250 | MEDIUM | 6.5 | Aug 29, 2019 | The Kubernetes client-go library logs request headers at verbosity levels of 7 or higher. This can disclose credentials to unauthorized users via logs or command output. Kubernetes components (such as kube-apiserver) prior to v1.16.0, which make use of basic or bearer token authentication, and run at high verbosity levels, are affected. |
| CVE-2020-8559 | MEDIUM | 6.4 | Jul 22, 2020 | The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.6 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise. |
| CVE-2020-8554 | MEDIUM | 6.3 | Jan 21, 2021 | Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect. |
| CVE-2020-8555 | MEDIUM | 6.3 | Jun 5, 2020 | The Kubernetes kube-controller-manager in versions v1.0-1.14, versions prior to v1.15.12, v1.16.9, v1.17.5, and version v1.18.0 are vulnerable to a Server Side Request Forgery (SSRF) that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master's host network (such as link-local or loopback services). |
| CVE-2019-11252 | MEDIUM | 5.9 | Jul 23, 2020 | The Kubernetes kube-controller-manager in versions v1.0-v1.17 is vulnerable to a credential leakage via error messages in mount failure logs and events for AzureFile and CephFS volumes. |
| CVE-2020-8557 | MEDIUM | 5.5 | Jul 23, 2020 | The Kubernetes kubelet component in versions 1.1-1.16.12, 1.17.0-1.17.8 and 1.18.0-1.18.5 do not account for disk usage by a pod which writes to its own /etc/hosts file. The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail. |
Showing the 20 most severe of 30 known CVEs.
Get Third Party Support