Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication

Age
3 months ago
Information
Summary
A critical set of vulnerabilities, known as IngressNightmare, has been identified in the Ingress NGINX Controller for Kubernetes, potentially affecting over 6,500 clusters by allowing unauthenticated remote code execution. These vulnerabilities, identified as CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974, have been given a CVSS score of 9.8. They exploit the admission controller component's network accessibility without authentication, allowing attackers to inject arbitrary NGINX configurations through malicious ingress objects. This can lead to unauthorized access to all secrets stored across namespaces, potentially resulting in a full cluster takeover. The flaws are particularly concerning as they enable the execution of arbitrary code by exploiting the admission controller's elevated privileges. To mitigate these risks, users are advised to update to the latest versions of the Ingress NGINX Controller and restrict network access to the admission controller.
How Blue Rock Helps
This security issue gives an attacker the ability to achieve unauthenticated remote code execution on Kubernetes Ingress NGINX controllers by exploiting vulnerabilities in the admission controller, potentially leading to full cluster takeover. The following protection guardrails can further prevent the following steps an attacker can take: The attacker first uploads a malicious shared library to the controller's pod and then, by sending a specially crafted request to the unauthenticated admission controller, injects a malicious NGINX configuration that causes this library to be loaded. **Library Load Path Allow** helps prevent this critical step by blocking the loading of the attacker's shared library if it's placed in and attempted to be loaded from a directory not on the pre-defined allowlist, thus stopping the malicious NGINX configuration from successfully executing the payload. If the library loading is somehow attempted from an allowed path, **Container Drift Protection (Binaries & Scripts)** further prevents the actual remote code execution by blocking the execution of this unauthorized shared library, as it constitutes new, untrusted code not present in the original container image. Once an attacker achieves remote code execution, they might attempt to establish a reverse shell for interactive control; **Reverse Shell Protection** detects and blocks such attempts by preventing shell file descriptors from being bound to network sockets, severing this command and control channel. To escalate privileges or move laterally, the attacker might try to run additional tools or scripts from arbitrary locations within the compromised pod; **Process Path Exec Allow** restricts this by ensuring new processes can only be launched from pre-approved filesystem paths, limiting the attacker's ability to execute arbitrary downloaded tools. Furthermore, if the attacker attempts to execute known malicious or reconnaissance tools like `netcat` after gaining RCE, **Process Exec Deny** would block their execution based on policy. The attacker would then likely try to access sensitive information such as API tokens or credentials; **Sensitive File Access** helps prevent the exfiltration of data by detecting and blocking attempts to read Kubernetes secrets mounted as files within the pod or other critical configuration files designated as sensitive. To achieve wider control, the attacker might abuse the compromised pod's Service Account to interact with the Kubernetes API, aiming to access secrets across all namespaces or deploy malicious workloads. **Namespace Execution Guard** steps in here, preventing unauthorized broad API interactions indicative of cluster takeover attempts, such as an attempt by the compromised service account to list or access secrets across all namespaces. If the attacker tries to deploy a new malicious workload designed to run with excessive privileges (e.g., `securityContext: {privileged: true}`), **Container Capability Control** limits this by enforcing a reduced, policy-defined set of Linux capabilities for any container, thereby restricting what even a "privileged" malicious pod can do at the kernel level. Finally, to gain full control over the node or deploy further unmanaged containers, an attacker with RCE might attempt to interact with the node's container runtime socket (e.g., `docker.sock`); **Container Runtime Socket Protection** prevents such unauthorized access to this critical socket from within the compromised pod, thwarting a common container escape and cluster takeover vector.
MITRE ATT&CK Techniques Inferred
  • T1068: Exploitation for Privilege Escalation: The attacker exploited a vulnerability in the Ingress NGINX Controller for Kubernetes, which allows for unauthenticated remote code execution. This vulnerability, named IngressNightmare, affects the admission controller component, allowing an attacker to inject arbitrary NGINX configurations. This is a classic example of Exploitation for Privilege Escalation, where the attacker takes advantage of a flaw to gain elevated privileges within the system.
  • T1021: Remote Services: The attacker uses the vulnerability to execute arbitrary code on the Ingress NGINX Controller's pod. This is done by injecting a malicious NGINX configuration through AdmissionReview requests. This scenario is indicative of Remote System Discovery, where the attacker is attempting to execute code on a remote system to gain control.
  • T1059: Command and Scripting Interpreter: Once the malicious configuration is injected, the attacker can load a shared library to the pod, which effectively leads to remote code execution. This action represents Command and Scripting Interpreter, where the attacker uses scripts or code execution to control the compromised system.
  • T1552: Unsecured Credentials: The attacker is able to access all secrets stored across all namespaces in the Kubernetes cluster by exploiting the elevated privileges and network accessibility of the admission controller. This represents Access to Non-Public Data, where the attacker gains unauthorized access to sensitive information within the system.
  • T1078: Valid Accounts: The attacker can take over the entire Kubernetes cluster by abusing a strong Service Account to read Kubernetes secrets. This is an example of Valid Accounts, where the attacker uses legitimate credentials or access tokens to maintain persistent access to the system.

See Blue Rock In Action