This is the multi-page printable view of this section. Click here to print.
Kubernetes Issues and Security
1 - Kubernetes Issue Tracker
To report a security issue, please follow the Kubernetes security disclosure process.
Work on Kubernetes code and public issues are tracked using GitHub Issues.
- Official list of known CVEs (security vulnerabilities) that have been announced by the Security Response Committee
- CVE-related GitHub issues
Security-related announcements are sent to the kubernetes-security-announce@googlegroups.com mailing list.
2 - Kubernetes Security and Disclosure Information
This page describes Kubernetes security and disclosure information.
Security Announcements
Join the kubernetes-security-announce group for emails about security and major API announcements.
Report a Vulnerability
We're extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.
To make a report, submit your vulnerability to the Kubernetes bug bounty program. This allows triage and handling of the vulnerability with standardized response times.
You can also email the private security@kubernetes.io list with the security details and the details expected for all Kubernetes bug reports.
You may encrypt your email to this list using the GPG keys of the Security Response Committee members. Encryption using GPG is NOT required to make a disclosure.
When Should I Report a Vulnerability?
- You think you discovered a potential security vulnerability in Kubernetes
- You are unsure how a vulnerability affects Kubernetes
- You think you discovered a vulnerability in another project that Kubernetes depends on
- For projects with their own vulnerability reporting and disclosure process, please report it directly there
When Should I NOT Report a Vulnerability?
- You need help tuning Kubernetes components for security
- You need help applying security related updates
- Your issue is not security related
Security Vulnerability Response
Each report is acknowledged and analyzed by Security Response Committee members within 3 working days. This will set off the Security Release Process.
Any vulnerability information shared with Security Response Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated.
Public Disclosure Timing
A public disclosure date is negotiated by the Kubernetes Security Response Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Security Response Committee holds the final say when setting a disclosure date.
3 - Official CVE Feed
Kubernetes v1.25 [alpha]
This is a community maintained list of official CVEs announced by the Kubernetes Security Response Committee. See Kubernetes Security and Disclosure Information for more details.
The Kubernetes project publishes a programmatically accessible JSON Feed of published security issues. You can access it by executing the following command:
curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json
| CVE ID | Issue Summary | CVE GitHub Issue URL |
|---|---|---|
| CVE-2022-3294 | Node address isn't always verified when proxying | #113757 |
| CVE-2022-3162 | Unauthorized read of Custom Resources | #113756 |
| CVE-2022-3172 | Aggregated API server can cause clients to be redirected (SSRF) | #112513 |
| CVE-2021-25749 | `runAsNonRoot` logic bypass for Windows containers | #112192 |
| CVE-2021-25741 | Symlink Exchange Can Allow Host Filesystem Access | #104980 |
| CVE-2021-25737 | Holes in EndpointSlice Validation Enable Host Network Hijack | #102106 |
| CVE-2021-3121 | Processes may panic upon receipt of malicious protobuf messages | #101435 |
| CVE-2021-25735 | Validating Admission Webhook does not observe some previous fields | #100096 |
| CVE-2020-8554 | Man in the middle using LoadBalancer or ExternalIPs | #97076 |
| CVE-2020-8566 | Ceph RBD adminSecrets exposed in logs when loglevel >= 4 | #95624 |
| CVE-2020-8565 | Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 | #95623 |
| CVE-2020-8564 | Docker config secrets leaked when file is malformed and log level >= 4 | #95622 |
| CVE-2020-8563 | Secret leaks in kube-controller-manager when using vSphere provider | #95621 |
| CVE-2020-8557 | Node disk DOS by writing to container /etc/hosts | #93032 |
| CVE-2020-8559 | Privilege escalation from compromised node to cluster | #92914 |
| CVE-2020-8558 | Node setting allows for neighboring hosts to bypass localhost boundary | #92315 |
| CVE-2020-8555 | Half-Blind SSRF in kube-controller-manager | #91542 |
| CVE-2020-10749 | IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements | #91507 |
| CVE-2019-11254 | kube-apiserver Denial of Service vulnerability from malicious YAML payloads | #89535 |
| CVE-2020-8552 | apiserver DoS (oom) | #89378 |
| CVE-2020-8551 | Kubelet DoS via API | #89377 |
| CVE-2019-11251 | kubectl cp symlink vulnerability | #87773 |
| CVE-2018-1002102 | Unvalidated redirect | #85867 |
| CVE-2019-11255 | CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation | #85233 |
| CVE-2019-11253 | Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack | #83253 |
| CVE-2019-11250 | Bearer tokens are revealed in logs | #81114 |
| CVE-2019-11248 | /debug/pprof exposed on kubelet's healthz port | #81023 |
| CVE-2019-11249 | Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal | #80984 |
| CVE-2019-11247 | API server allows access to custom resources via wrong scope | #80983 |
| CVE-2019-11245 | container uid changes to root after first restart or if image is already pulled to the node | #78308 |
| CVE-2019-11243 | rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() | #76797 |
| CVE-2019-11244 | `kubectl:-http-cache=<world-accessible dir>` creates world-writeable cached schema files | #76676 |
| CVE-2019-1002100 | json-patch requests can exhaust apiserver resources | #74534 |
| CVE-2018-1002105 | proxy request handling in kube-apiserver can leave vulnerable TCP connections | #71411 |
| CVE-2018-1002101 | smb mount security issue | #65750 |
| CVE-2018-1002100 | Kubectl copy doesn't check for paths outside of it's destination directory. | #61297 |
| CVE-2017-1002102 | atomic writer volume handling allows arbitrary file deletion in host filesystem | #60814 |
| CVE-2017-1002101 | subpath volume mount handling allows arbitrary file access in host filesystem | #60813 |
| CVE-2017-1002100 | Azure PV should be Private scope not Container scope | #47611 |
| CVE-2017-1000056 | PodSecurityPolicy admission plugin authorizes incorrectly | #43459 |
This feed is auto-refreshing with a noticeable but small lag (minutes to hours) from the time a CVE is announced to the time it is accessible in this feed.
The source of truth of this feed is a set of GitHub Issues, filtered by a controlled and
restricted label official-cve-feed. The raw data is stored in a Google Cloud
Bucket which is writable only by a small number of trusted members of the
Community.