Escalate from Prototype Pollution to EKS Takeover

What this lab covers

You start on the outside with nothing but the URL of an exposed Node.js application. You review its dependencies and source for a prototype pollution flaw and turn that flaw into code execution inside a Kubernetes pod.

From the pod you enumerate what the workload identity is permitted to do, move across a namespace boundary through an over-permissive role binding, and follow the trail into the AWS account that backs the cluster. The route from application bug to cloud data is the part worth understanding.

It assumes basic Node.js and Kubernetes familiarity and intro-level AWS IAM, and it suits application developers and cluster operators as much as anyone testing a cluster.

How prototype pollution is abused

In JavaScript every plain object inherits from a shared prototype. When code merges untrusted input into an object without guarding special keys such as __proto__ or constructor, an attacker can write onto that shared prototype, and every object created afterward inherits the injected value.

The impact depends on what later reads the polluted property. A template engine, a configuration lookup or an option parsed at runtime can be steered into executing attacker-controlled code, which is how a quiet data bug becomes remote code execution in the pod.

Once code runs inside the pod, the workload's mounted service account token and the Kubernetes API become the next surface. A namespace-scoped foothold is rarely the end of the story, because ordinary cluster permissions and cloud integrations lead outward from there.

How to detect this in your own environment

Run dependency and source scanners over your Node.js services and treat prototype pollution sinks and template engines pinned to versions with known option-injection issues as real findings, not noise.

Alert on pod creation with elevated permissions, secret reads and exec into containers by workload identities that do not normally perform them, and on cross-namespace access that falls outside an application's expected scope.

Enable Kubernetes audit logging and ship it somewhere you can query during an incident. Without it, the control-plane activity that follows a pod compromise is effectively invisible.

How to prevent it

Merge untrusted data with libraries that reject dangerous keys, freeze prototypes where it is practical, and pin template engines to versions that validate their options rather than compiling them verbatim.

Scope service accounts and RBAC to the least a workload needs, and treat pod creation, secret read and exec as privileged verbs when you write roles.

Narrow the cloud identity reachable from the cluster and restrict pod access to the cloud metadata service, since that is what converts a cluster foothold into a cloud-account compromise.

Real-world context

Kubernetes incidents are dominated by configuration rather than zero-days. Red Hat's research into Kubernetes adoption and security reports that nearly 60 percent of respondents experienced a misconfiguration incident in the preceding 12 months, the most commonly cited category. This lab mirrors that shape: an application flaw opens the door, and accumulated cluster and cloud misconfigurations carry the compromise the rest of the way.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application, T1613 Container and Resource Discovery, T1552 Unsecured Credentials and T1078 Valid Accounts.

Applying this at work

• Scan your Node.js services for prototype pollution sinks and unsafe recursive merges, and replace hand-rolled merges with hardened libraries.
• Pin template engines and other runtime-option consumers to versions that validate their inputs.
• Enumerate which identities in your clusters can create pods, read secrets or exec into containers, and reduce each list.
• Enable Kubernetes audit logging and confirm it reaches a system you can query during an incident.
• Block pod access to the cloud metadata endpoint and review the cloud permissions attached to your node and workload roles.

Frequently asked questions

What is prototype pollution?

It is a class of JavaScript bug where untrusted input is written onto an object's shared prototype. Because other objects inherit from that prototype, the injected value can change behavior elsewhere in the program, and in the right conditions it leads to remote code execution.

Can a web application bug really lead to cloud account access?

Yes, when the application runs on a cluster wired into the cloud. Code execution in a pod exposes the Kubernetes API and the identities the cluster trusts, and permissive RBAC or a broadly scoped cloud role turns that foothold into access to cloud resources.

Is a Kubernetes cluster a security boundary?

Not in the way many teams assume. Several ordinary permissions lead to code execution or to credentials for more privileged identities, so a namespace boundary should not be relied on to contain a compromise on its own.

Do I need my own cluster to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Kubernetes Attack and Defense Bootcamp, Professional Edition (KRTP) covers Kubernetes attack paths end to end, including application-to-pod compromise, RBAC abuse, and the route from a cluster into the cloud account behind it.