Blog — Tomasz Sielski

This is a writeup of the hackArcana Q2 2026 Kubernetes security challenge — four exercises that walk through a realistic attack chain against a web application running on Kubernetes. I’m documenting it not just as a CTF record, but because each step maps directly to real misconfigurations I see in production environments.

The scenario: you’re a pentester assessing a company website. Your goal is to find vulnerabilities and escalate permissions as far as possible.

Warmup — I am here (5 pts)

Before the real work starts, hackArcana runs a warmup: decode a Base64 string to prove you know how flags work.

SGV4QXtTcXJ0KEJhc2U2NCk9PUs4cz8/fQ==

Decoded: HexA{Sqrt(Base64)=K8s??}. Simple — but it sets the tone. This is a Kubernetes challenge, and flags are hidden in places you have to dig for.

0: Recon — path traversal to local file read (50 pts)

The target was a simple company website. Looking at the page source, the project links caught my attention immediately:

/project?name=our-first-project.html

A name parameter loading files directly — a classic path traversal candidate. I manipulated the parameter using ../ sequences to traverse the filesystem and read arbitrary files from the server:

/project?name=../../../../run/flag0/
flag0-8faf2e44.txt

It worked. The file contents were returned directly in the response.

Defensive note: Never pass user-controlled input directly to file system operations. Validate against an allowlist of permitted filenames. Sanitising by stripping traversal sequences is bypassable — allowlisting is not.

1: Foothold — service account token extraction (100 pts)

With arbitrary file read confirmed, the next question was: what else is on this filesystem? Knowing the app was running on Kubernetes, I went straight for the service account credentials mounted automatically into every pod:

/var/run/secrets/kubernetes.io/
  serviceaccount/token
/var/run/secrets/kubernetes.io/
  serviceaccount/namespace

Both readable via the same path traversal. I configured kubectl with these credentials and ran:

kubectl auth can-i --list

This revealed the permissions available to the compromised service account — the first real view into what an attacker can do inside the cluster.

Defensive note: Kubernetes mounts service account tokens into pods by default. If your application doesn’t need to talk to the Kubernetes API, set automountServiceAccountToken: false in the pod spec. Most application pods don’t need it.

2: Elevation — cross-account secret creation (100 pts)

Enumerating permissions revealed two service accounts with complementary but individually limited abilities: one could create secrets, the other could read them. Neither was powerful alone.

Using the secret-creation account, I created a new secret accessible to the reader account — bridging the two permission sets to gain read access that was never intended.

Defensive note: The ability to create secrets in Kubernetes is a high-privilege operation even when it doesn’t look like one. An account that can create secrets can often escalate to read secrets it was never intended to access. Treat secrets/create with the same caution as secrets/get.

3: Escalation — final secret read (200 pts)

With the reader account now elevated, I read the final flag directly from Kubernetes secrets. Full chain complete: a vulnerable file parameter in a web app had led to reading credentials from inside a Kubernetes cluster.

Defensive note: Kubernetes secrets are not encrypted at rest by default. Any account that can read secrets in a namespace has access to everything stored there. Restrict secrets/get aggressively, enable encryption at rest, and audit secret access regularly.

What this chain shows

Each individual vulnerability here is well-known. Path traversal is decades old. Service account token exposure is a documented Kubernetes risk. Overly permissive RBAC is the most common finding in Kubernetes security reviews.

What makes this chain effective is the combination — each step feeds the next. A web vulnerability becomes a Kubernetes foothold becomes a privilege escalation becomes full secret access. The blast radius of that initial path traversal was far larger than it looked.