https://bumsrake.de/ - This is an amusing way to do vuln. disclosure
| Personal Site | https://www.mccune.org.uk/ |
| Blog | https://raesene.github.io/ |
| Container Security Site | https://www.container-security.site |
| GitHub | https://github.com/raesene/ |
Rory McCune
- 1,038 Followers
- 342 Following
- 799 Posts
Containers, Security, Kubernetes, Hillwalking
Chris ShortMonitor LLM routing with the Kubernetes Inference Extension | Datadog #devopsish https://www.datadoghq.com/blog/llm-routing-kubernetes-inference-extension/
@shodan nice, thanks for that!
@shodan oh cool! not sure if I'm querying wrong but that doesn't seem to work for me at the moment.
Most kubernetes API servers put a SAN of "kubernetes.default.svc.cluster.local" in their API server cert (you can see an example https://beta.shodan.io/host/136.116.232.158),
but if I search for that as a hostname https://www.shodan.io/search?query=hostname%3A%22kubernetes.default.svc.cluster.local%22
I'm getting 0 results?
@shodan any plans to allow searching by the Subject Alternative Name field in X.509 certificates? On certain systems (e.g. Kubernetes) there's quite a lot of internal information leakage via that field, and it'd be interesting to be able to run an analysis on it.
mudge“Bundler 4.0.13 introduces cooldown, a time-based filter that refuses to resolve to a version until it has been public for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window.” — https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
It's always been known that containers don't fully contain, but the ease with which attackers can execute container breakout attacks now, using LLM backed tooling, should prompt people to re-evaluate where they can rely on container isolation.
Some more thoughts and a concrete example here https://raesene.github.io/blog/2026/06/03/do-containers-still-contain/
If you're seeing some new "old" vulnerabilities show up in vulnerability scans of Kubernetes clusters, it's based on some work done by the project to correct some CVE records for issues that have no patch available.
There's a blog on the topic https://kubernetes.io/blog/2026/05/26/reconciling-unfixed-kubernetes-cves/ which explains why and provides some of the historical context.
If you're interested in the technical details of these vulnerabilities and some ideas on whether they're relevant for your clusters, and what to do if they are, there's a series of technical deep-dives here https://securitylabs.datadoghq.com/articles/?s=unpatchable
Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs
The Kubernetes project relies on transparency to empower cluster administrators and security researchers. One important way we do that is by publishing CVE records into the Common Vulnerabilities and Exposures database. As part of our ongoing effort to mature the official Kubernetes CVE Feed, we have identified some discrepancies. CVE records for a few older, unfixed issues incorrectly include a fixed version field. The Kubernetes Security Response Committee (SRC) will correct the affected CVE records on June 1, 2026. This may result in vulnerability scanners identifying these vulnerabilities in places where they were previously not detected.
@wiggitywhitney so it's not a test of who's old enough to recognize the screengrab? :P
Here's the last one in our series of blogs on the unpatchable vulnerabilities of #Kubernetes, with CVE-2021-25740
https://securitylabs.datadoghq.com/articles/unpatchable-kubernetes-vulnerabilities-cve-2021-25740/
