Whats the best process to get fixes for a particular CVE

Support and Help
1

When a specific ubuntu-eks/1.33/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-* AMI is flagged by a CVE such as https://ubuntu.com/security/CVE-xxx

How do folks go about fixing it themselves or tracking that its actually been fixed in the ubuntu-eks upstream images. We are flagged by one of these today but the CVE page just says Needs Evaluation. What are other folks doing? Are they trying to patch the image themselves? Are they monitoring somewhere specific? I don’t think this project has true release notes, so it makes it hard to know whats fixes go into the releases. I would hate to invest in patching it myself when the actual fix is days away on your end. Just looking for insight into what the rest of the community is doing

1 Like
2

Not sure I understand the question, for I don’t understand that sentence, but maybe the USN site is what you’re looking for:
https://ubuntu.com/security/notices

You can search for CVE’s and you can also subscribe to one of the update channels.

1 Like
3

Theres a specific CVE we are impacted by. I don’t want to share the specific CVE. Its listed on the site as Needs Eval.. I think my real problem is these ubuntu cloud images don’t have release notes. There was a new images built on 20260429, but what was fixed in it, was this CVE fixed? ALso whats the next round of images being built? Is my CVE fix coming?

4

You can search that specific CVE on the USN site and see if it has been fixed, which I doubt, given the “Needs eval…”. See this for an example:
https://ubuntu.com/security/CVE-2023-52168

It lists which package is affected and which version fixed the issue. From there it’s just a simple lookup, which version you have installed.

5

Yeah so im wondering more if it says its fixed, how do I know which ubuntu-eks cloud image its fixed in. The lack of release notes make it hard to know which new AMI to pull. I was just wondering what folks are doing here. Also if it says needs eval.. how do I know its days away vs months away

6

How did you get “flagged” to be affected by said CVE?

7

We have a third party tool that monitors our environment and flags us for critical CVEs we could be exposed to.

8

How does it do that? It sounds like the same approach can be used to find out if the issue has been fixed.

9

A few things that might help:

“Needs Evaluation” usually just means the security team hasn’t triaged it yet, not that Ubuntu is unfixed. A lot of these resolve as Not-affected or already-patched once someone looks at them.

There’s also a decent chance your scanner is false-positiving. Ubuntu backports security patches rather than bumping upstream versions, and most third-party scanners do naive version-string matching against NVD data. So a package like 1.2.3-4ubuntu0.5 will look vulnerable to them even when the patch is already in there. The USN page (when available) is the authoritative source for which version of Ubuntu actually fixes a given CVE.

To check what’s actually in the AMI, no need to download anything — spin up a t3.micro from it, run dpkg-query -W -f='${Package} ${Version}\n', terminate. Pennies. Compare against the USN.

You could also install the open-source grype tool (snap (I maintain)) (upstream) and scan the filesystem. See if it confirms finding you vulnerable to the same CVE. Grype incorporates security data directly from the Ubuntu security feed.

Worth knowing: kubelet-eks, kubectl-eks and ecr-credential-provider ship as snaps in the EKS images (docs), so they auto-refresh on running nodes independent of the AMI serial. If your CVE lives in one of those, you may already be patched without needing a new image.

You can also run grype against those snaps:

grype kubelet-eks
 ✔ Downloaded snap kubelet-eks@stable (amd64)
 ✔ Indexed file system dL56CBK3fYbbPOgCC36pSXFC6yiX01JC_2.snap
 ✔ Cataloged contents ab3bc5ba747eec218f7a245f8ad3a4037dc1060deeff3c00cb6f548352871524
   ├── ✔ Packages                        [0 packages]
   └── ✔ Executables                     [1 executables]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored
No vulnerabilities found

For tracking new builds, the ubuntu-cloud-announce mailing list and the Ubuntu on AWS Announcements page are the channels. EKS images typically rebuild within a couple of weeks of a significant USN landing.

If you’re willing to share the CVE number, the answer’s probably five minutes away rather than guesswork.

2 Likes
10

Thanks these links are really helpful, I am not on that mailing list and will join it. In our case its a version of containerd, we are waiting on the containerd 2.3.0 which was updated 5 days ago, that has the fix in it. All your other data is really good though – esp about the snaps.

11

yes – it will tell us when its fixed, but we have to build a new AMI and rotate it in, just waiting on the fix to be available in an AMI

12

This is the actual CVE https://ubuntu.com/security/CVE-2026-33186

1 Like