Kata Containers is a rolling-release project: every monthly release replaces the previous one, and only the current release series receives security fixes. There are no long-term-support branches.
-
Keep it private first. Please do not open a public GitHub issue or pull request for security problems.
-
Use GitHub’s security advisory workflow Follow the official GitHub guide: Report a vulnerability privately
We follow the OpenSSF vulnerability-handling guidelines. The table below shows the target timelines we aim for once we receive your report. These are independent objectives, not sequential steps.
| Objective | Target time | Notes |
|---|---|---|
| Initial acknowledgement | ≤ 14 calendar days | Maintainers confirm receipt and start triage. |
| Triage & CVSS-v3.1 scoring | ≤ 30 days | We assign severity and plan remediation. |
| Fix availability | Next scheduled monthly release (or an out-of-band patch for Critical/High issues) |
We may cut a vX.Y.Z patch if waiting a month poses undue risk. |
| CVE assignment | Before public disclosure | GitHub automatically requests a CVE ID when we publish the security advisory. |
| Release | First published | Security-fix window |
|---|---|---|
| Latest monthly release | see git tag --sort=-creatordate | head -1 |
Actively maintained |
| Any prior release | — | Unsupported – please upgrade |
Why no backports? Kata’s architecture evolves quickly; back-porting patches would re-introduce the very maintenance burden we avoid by using a rolling model.
If you maintain a downstream distribution or integration of Kata Containers:
- Embargo process: Please be aware that security vulnerabilities are fixed in private as part of an embargo period. During this period only the Kata Containers Vulnerability Management Team (VMT) and very limited number of trusted contributors have access to the vulnerability report and participate in fixing the issue.
- Early notification: The Kata Containers VMT sends embargo notifications to the private embargo-notice mailing list a few days in advance of public announcements, to allow downstream stakeholders time to test the fix and prepare to move to the new release that contains the public fix.
-
Where applicable, each release includes a Security section in its GitHub Release Notes which contains the list of CVEs we have addressed in that release:
-
We do not publish separate “stable-branch” advisories because unsupported branches receive no fixes.
-
To see the list of published security advisories please visit the security tab in the kata-containers repository.
A: No. Upgrade to the latest monthly release. Only the current monthly release receives security fixes.
A: Open/continue a GitHub issue after the advisory is published, or use the #general channel in the Kata Containers Slack workspace with a link to the official security advisory.
Last updated: 2026-06-12