A simple trial signup handed us the keys to a major Platform-as-a-Service provider’s demo environment. Within hours, we had full control of the same Kubernetes sandbox they use to sell that platform to potential customers. It’s exactly the kind of kubernetes security gap that trial environments rarely get checked for.
Sometimes the front door is the easiest way in. No privileged access request. No social engineering pretext. Just a signup form.
The setup
Our target was a major Platform-as-a-Service provider that sells containerised environments to businesses worldwide. Their trial account gave us a dedicated sandbox, built for potential customers to test the platform before buying. It ran on the same infrastructure as production, but without production’s kubernetes security controls. Nobody had scoped it that way.
The infiltration
With that established, we built a specially designed Docker container configured to connect back to our command centre. We uploaded it to Docker Hub, where it sat among millions of legitimate images. The platform allowed pulls from external registries, so our container walked straight through. That’s the Docker security blind spot behind most registry-trust models: anything public gets treated as safe until proven otherwise.
The escalation
Now to the harder part: we probed deeper through the platform’s API. We configured our container with a privileged security context, a well-documented misconfiguration and one of the most common kubernetes security failures we see in the wild. That let us break out of the container’s isolation and reach the underlying node.
The takeover
Every pod in their Kubernetes cluster carried its own service account token. One of the tokens we accessed had permission to request secrets across the entire cluster, including the sensitive kube-system namespace.
Here’s the operative point: we had full control of their demo environment, the same Kubernetes sandbox potential customers use to evaluate the platform.
On top of that, while our technical team worked through the cluster, we tried a simpler route: a sales demo call got us credentials into their Google Workspace environment. Which means the lesson here is simple. Security is only as strong as its weakest link, and here, that link wasn’t code.
The lesson
We found this during our initial assessment. In practice, it’s a clear case for testing every environment a business runs, not just production. Demo environments deserve the same Kubernetes security rigour as the systems they’re built to sell, and Docker security discipline shouldn’t stop at the registry gate either.
A demo environment might seem inconsequential. Isolated containers might seem harmless on their own. And a trial account might seem too minor to matter.
Here’s why that’s wrong: in the hands of a determined attacker, those assumptions become the way in, and a breach of a demo environment can expose exactly how your real infrastructure is built.
What would a free trial signup uncover in your own infrastructure?
A sandbox, a demo, a trial account nobody scoped like production. Don’t wait for a real attacker to find what yours is hiding. Contact CovertSwarm and put every environment your business runs, not just production, under constant, targeted attack.