Multiple vulnerabilities in ingress-Nginx (Score 9.8) | Hacker News Reader

Multiple vulnerabilities in ingress-Nginx (Score 9.8)

groups.google.com

76 pointsnumbsafari21 comments

OK it requires access to the pod network. Bad, but not that. Here’s the 9.8: https://github.com/kubernetes/kubernetes/issues/131009

I am a little confused about the comment section about this being overblown, it really isn't. Ignore all the comments in this post and fix this ASAP.

Here's a simple test:

`kubectl exec -it` a pod:

curl -k --fail https://ingress-nginx-controller-admission.ingress-nginx.svc...

If you see 400 Bad Request, that means this pod has access to the admission controller.

How easy would it be to find an avenue to make a request to the admission controller for anything running on your k8s cluster? (maybe your service takes any kind of URL and makes a request on your server...there's infinite possibilities of exploiting this.)

I am rethinking my choice in using ingress-nginx entirely, perhaps it's time to find a simpler solution that has more secure defaults.

These seems overblown since because configuring your ingress controllers and annotating your pods is like "I copy and pasted bash | sudo" but controllers in k8s are a totally insane pattern so I guess any of them could steal/do a lot of evil, really.

It's "overblown" because of these dumb CVSS scores that get attached to vulnerabilities as if they had any meaning at all (they do not). By itself, it's just a marginally interesting semi-remote vuln, effectively a privesc within a K8s deployment.

Score 9.8 ought to mean, "this is almost the worst conceivable vulnerability".

I certainly stopped what I was doing to go check. This is a badly overblown emergency which degrades everyone’s ability to properly respond to actual emergencies.

Yeah, and there have been a lot of these lately. The more nothing-burger 9.8+ severity vulnerabilities there are, the less space there is for communicating "this is actually a severe vulnerability and you need to pay attention".

Heartbleed was a 7.5. The entire security community is constantly shouting "RED ALERT, THIS IS A MUCH MUCH WORSE VULNERABILITY THAN HEARTBLEED" and they're all just non-issues.

That's a CVSS issue. Heartbleed only affected Confidentiality, and CVSS rates scores on a triad of Confidentiality, Integrity, and Availability. RCE affects all three.

That's exactly what I'm complaining about, yes. Nothing burgers get 9.8, while earth shattering vulnerabilities get 7.5 using the scoring system that the security community uses to describe "severity".

Heartbleed was a much more significant issue than this ingress-nginx thing.

I agree with you, which is why I'm redirecting the blame to the CVSS standard, which does not agree with you.

This is literally true, it is the worst conceivable vulnerability, total access to your k8s cluster by hitting a URL, how about a 10 instead of 9.8, these comments are wild.

Resolved in ingress-nginx v1.11.5/v1.12.1 neither of which seem to have been released yet.

Looks like the container images for both versions are now available:

  registry.k8s.io/ingress-nginx/controller:v1.12.1  
  registry.k8s.io/ingress-nginx/controller:v1.11.5

The Helm chart has not been updated yet, but it looks like you can use the new container images by manually specifying the updated image tag in the values file:

  controller:  
    image:  
      tag: "v1.12.1"

No evidence, but the fact that the "IngressNightmare" PR piece was announced before there were even PRs created to fix this smells like the team at Wiz leaked this before it was really ready.

Whether the scores are legit or not, the fact that this was such a botched disclosure process is not a good look for the Kubernetes project, of which this is a part.

Edit: According to [1], the team at Wiz show a responsible disclosure timeline. Seems like the Kubernetes project's process didn't work so well. If Wiz is accurately reporting what happened in their blog, these fixes (or the plan for them) was available a month ago, despite seemingly not having working PRs until today, after the security announcement?

Again, I really appreciate the work of the team to ship this, but this isn't a good look for the Kubernetes project itself.

[1] https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...

For the sake of completeness I will also mention that the updated Helm chart is now also available:

  ingress-nginx: 4.12.1

That's quite a terrifying CVE.

> Multiple issues have been discovered in ingress-nginx that can result in arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

Beyond that, it could likely be used to sniff out client secrets from other connections as well if the attacker is sophisticated enough.

> January 9, 2025 – Kubernetes proposed a fix for CVE-2025-1097.

> January 10, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1097.

> January 12, 2025 – Kubernetes proposed a fix for CVE-2025-1974.

> January 16, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1974.

> January 20, 2025 – Kubernetes proposed a fix for CVE-2025-24513.

> January 21, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-24513.

Lol, lmao even. [1]

[1]: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...

The CVE numbering is interesting.

4x “stuff dumped into a configuration file verbatim”

1x “just run the code, CJ”

“unauthenticated attacker with access to the pod network” /yawn

Reply on news.ycombinator.com