I Built a Kubernetes CVE Bot. Its First Alert Was About Eclipse Che.
I wanted exactly one thing: a message on my phone when a new CVE hits a version I actually run. So I built a Telegram bot. It pulls the official Kubernetes CVE feed, GitHub advisories, NVD and CISA's "known exploited" l
I wanted exactly one thing: a message on my phone when a new CVE hits a version I actually run.
So I built a Telegram bot. It pulls the official Kubernetes CVE feed, GitHub advisories, NVD and CISA's "known exploited" list, merges them and posts to a channel. Simple, clean, exactly one job.
Then I opened the channel to admire my work. The very first post was a CVE in Eclipse Che. Eclipse Che is a browser IDE. A browser IDE is not what I asked for.
Β
Β
Eclipse Che runs on Kubernetes. It is not Kubernetes.
Eclipse Che is a perfectly nice browser IDE. It runs on Kubernetes. So do a lot of things. My bot did not appreciate the difference.
NVD's keyword search for "kubernetes" happily returns anything that mentions the word somewhere, in a reference link, a product list, a footnote. My bot, raised on exact string matching, took every one of those as a yes. Out of its first six posts, three went to Eclipse Che, the HyperShift operator and Apache Camel Karavan.
You know the two lumberjacks. One yells "we're cutting down the wrong forest!" and the other yells back "who cares, look at the progress!". My channel was making excellent progress.
The fix was boring. Components I watch by name get through from medium severity up; everything else from the wider ecosystem needs CVSS 7+ and has to talk about Kubernetes in its own first sentence. Posts that stop qualifying get deleted. (The channel shrank by half. Very professional.)
Β
Β
A CVE feed tells you everything. That's the problem.
Even with clean data, a feed has a structural problem. It tells you what was published. You want to know what hits you.
Remember IngressNightmare? Four CVEs in ingress-nginx (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974), unauthenticated remote code execution. Wiz found over 6,500 clusters with the vulnerable admission controller exposed and estimated that about 43% of cloud environments were vulnerable.
And what did most of us do that week? Not read the advisory. We opened the Hacker News comments to find out whether it was bad, then went to check which ingress-nginx version we had, then went looking for the chart value to bump. The advisory was open in another tab the whole time, unread, like a gym membership.
Three questions, every time: am I on an affected version, what do I upgrade to, and what's the exact command. A feed answers none of them. It wasn't built to.
Β
Β
Fine. The bot asks kubectl instead.
The new feature is a cluster snapshot. You send the bot /cluster, it gives you one command to copy:
kubectl version -o json
kubectl get nodes -o jsonpath='{range .items[*]}{.status.nodeInfo.kubeletVersion} {.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' | sort -u
That prints versions and image names. No secrets, no env vars, no manifests. You paste the output into the chat (or send it as a .txt, Telegram cuts long messages), and the bot works out what you run from the images: the control plane, kubelet, containerd, ingress-nginx, CoreDNS, Cilium, Istio, Argo CD, cert-manager and friends.
It keeps only component and version pairs. Your private registry and your payments-api image are read once and forgotten. /forget deletes the rest. I don't want your cluster. I have enough trouble with mine.
Β
Β
A boring EKS cluster: 9 components, 0 of them fine
To test it I wrote a snapshot shaped like a very ordinary EKS cluster: Kubernetes 1.29, containerd 1.7, Argo CD 2.10, cert-manager 1.13, the community ingress-nginx, Flux, and Traefik on latest because someone was in a hurry. A made-up cluster, not anyone's real one. Just the kind we all have somewhere.
Here's a trimmed version of what the bot replied, run against its live data:
π° Cluster snapshot Β· Amazon EKS Β· 9 components
π΄ affected: 7 Β· β³ support: 5 Β· β
fine: 0 Β· β unknown: 2
Argo CD v2.10.4: 14 CVE
π΄ CVE-2025-55190: Argo CD's Project API Token Exposes Repository Credentials
β upgrade to v3.2.12
helm upgrade argo/argo-cd -n --reuse-values --version
ingress-nginx v1.10.1: 12 CVE
π΄ CVE-2025-1974: ingress-nginx admission controller RCE escalation
β upgrade to v1.13.8
β³ Support
β’ Kubernetes 1.29 (EKS): support ended 2026-03-23, no more security fixes.
β’ ingress-nginx: retired in March 2026, no more releases or security fixes.
β Version unknown
β’ Traefik: the image tag has no version (latest or digest), check it by hand
Seven of nine components affected, five out of support, and zero "you're fine". The two it couldn't read, it says so instead of guessing. I'd rather get "I don't know" than a green tick that lies.
That ingress-nginx line is the one I'd frame. Kubernetes retired Ingress NGINX in March 2026. One of the most widely used ingress controllers now has open CVEs and no future patches. If your cluster still runs it, the report says so in plain words, which is more than the cluster will ever do.
Β
Β
A CVE list doesn't get an upgrade scheduled. $365 a month does.
Then I tried snapshots on EKS 1.31, 1.32 and 1.33, and every one came back with this:
β’ Kubernetes 1.32 (EKS): standard support ended 2026-03-23, now in extended support
until 2027-03-23. That's +$365/month per cluster (+$0.50/h at AWS prices).
That's straight from AWS pricing: $0.10 per cluster-hour in standard support, $0.60 in extended. Fifty cents an hour doesn't sound like anything until you multiply it by 730 hours and by the number of clusters nobody upgraded.
Security people get a CVE list. Whoever pays the AWS bill gets a number. Turns out the number is what gets an upgrade on the calendar. (I'd love to say the CVEs did it. Nobody has ever rescheduled a sprint over a CVSS score.)
Β
Β
It's not Trivy (and it once flagged a 2023 bug on Kubernetes 1.34)
It's not Trivy. Trivy and trivy-operator scan every package inside your images; this bot looks at the versions of the platform components you run. Different question: "which of my cluster's building blocks are affected" rather than "which library inside my app image". If you run Trivy, keep running it.
It also can't see what kubectl can't: runc, for example, so it tells you to run runc --version on a node. Honest beats clever.
And version ranges are harder than they look. During development my checker announced that Kubernetes v1.34 was vulnerable to CVE-2023-5528, a 2023 Windows bug, because one source described the affected range as ">= v1.8.0" with no upper end. A 2023 bug flagged on a 2025 release. (It was me. It's always the regex.) Now the fixed versions override open-ended ranges, and the bot has stopped time-travelling.
For context, the biggest free option in Telegram is @cveNotify with about 19.5k subscribers. It posts every CVE in the world, unfiltered. That's a different tool for a different person, probably one with more patience than me.
Β
Β
Try it on your cluster
The bot is @cveAlertive_bot. Snapshot reports are free and unlimited, you can save one cluster for free, and you get a weekly digest that says either what hit you or "nothing touched your versions this week" (the second message is the one you actually want).
The paid part is the channel, 199 Telegram Stars a month: personal alerts within about half an hour when a new CVE hits a saved cluster's versions, a π₯ follow-up when it lands in CISA's exploited list, and up to five clusters.
If you liked counting money you didn't know you were spending, the previous post was about the same thing for node sizes:
Kalislav Smirnov
Your Kubernetes node is smaller than you think: 3 reservation traps in EKS, GKE and AKS
Β
Β
Your turn
How do you find out today that a new CVE hits a version you actually run, and how long does it take you to be sure? A scanner in CI, a Slack channel nobody reads, the cloud provider's bulletin, or the Hacker News thread? If your honest answer is "Trivy already does this", say so, I want to hear that case too. And tell me what a report like this should say that mine doesn't.
AI-assisted: written with Claude; the numbers come from the bot's live output and the linked sources.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.