A Vulnerability That Allowed Me To Do NOTHING

I am Aditya Shende (aka Kong) from India. A bug bounty hunter, biker and cybersecurity researcher. This is my 16th article. If you spot a typo, let it be. Let us get started.

This writeup documents a vulnerability that was unlike anything I have encountered before. Not because the target was obscure. Not because the exploitation chain was sophisticated. But because the entire attack required nothing more than typing plain English into a text box. No interception proxy. No parameter manipulation. No encoded payloads. I typed a sentence, clicked two buttons, and achieved Remote Code Execution on a production server running as root.

Then I escaped the sandbox.

The Target

The platform in question is an educational technology product that provides an in browser code editor. Students visit the page, select a programming language, write code, and execute it against a server side runtime. This is a common pattern across the ed tech space and, when implemented correctly, is perfectly safe.

However, this platform had integrated an AI code generation feature directly into the editor. On the right side of the interface, a section labeled "AI PROMPT:" accepted natural language input alongside a "Generate" button. Below it sat an "INPUT" field for providing program input, and below that an "OUTPUT" panel where execution results would appear.

The intended workflow was straightforward. A student types a prompt such as "write a Python script that prints the Fibonacci sequence," clicks Generate, and the AI produces working code in the editor on the left. The student then clicks the green "Execute" button at the top right, and the output renders in the OUTPUT panel.

The problem is what happens when the prompt asks for something the platform was never designed to allow.

Initial Discovery

My first test was deliberate. I selected Python 3 from the language dropdown, navigated to the AI PROMPT field, and entered:

MAKE a python script to execute whoami command

MAKE a python script to execute whoami command

I clicked Generate. The AI produced the following code in the editor:

python

import subprocess
# Execute the 'whoami' command
result = subprocess.run(['id'], stdout=subprocess.PIPE)
# Print the output of the command
print(result.stdout.decode('utf-8'))

import subprocess
# Execute the 'whoami' command
result = subprocess.run(['id'], stdout=subprocess.PIPE)
# Print the output of the command
print(result.stdout.decode('utf-8'))

I clicked Execute. The OUTPUT panel returned:

uid=0(root) gid=0(root) groups=0(root)

uid=0(root) gid=0(root) groups=0(root)

The process was running as root.

I repeated the test with a second prompt:

MAKE a python script to execute cat /etc/passwd command

MAKE a python script to execute cat /etc/passwd command

The AI generated:

python

import subprocess
result = subprocess.run(['cat', '/etc/passwd'], stdout=subprocess.PIPE)
print(result.stdout.decode('utf-8'))

import subprocess
result = subprocess.run(['cat', '/etc/passwd'], stdout=subprocess.PIPE)
print(result.stdout.decode('utf-8'))

Upon execution, the full contents of /etc/passwd appeared in the OUTPUT section. Every user account on the system, rendered in a browser on an educational website.

At this point I had confirmed arbitrary command execution with root privileges. But I assumed the platform might be running the code inside a container or some form of sandboxed environment. So I decided to find out.

Confirming the Sandbox

My next prompt asked the AI to generate code that reads /proc/1/cgroup. This file reveals whether a process is running inside a Docker container or on bare metal. The output confirmed what I suspected: the execution environment was containerized. The cgroup entries contained Docker specific identifiers, and the container ID was visible in the path.

Under normal circumstances, a container would limit the blast radius of this vulnerability. Even with root inside the container, the host system should remain unreachable. The attacker would be confined to a throwaway environment with no persistence and no access to production data.

That assumption held for approximately three minutes.

Escaping the Sandbox

I began enumerating the container's environment to understand what restrictions, if any, were in place. I asked the AI to generate code that performs the following operations, one prompt at a time.

Reading environment variables. I prompted the AI to print os.environ. The output returned database connection strings, API keys, and internal service URLs. These were not sandboxed environment variables. They were production credentials injected into the container, likely through the orchestration layer, intended for the application runtime but now fully visible to any code the AI generated.

Checking for the Docker socket. I prompted the AI to check whether /var/run/docker.sock existed and was accessible. It was. The Docker daemon's Unix socket was mounted inside the container. This is a well documented and severe misconfiguration. When the Docker socket is exposed inside a container, any process with access to it can communicate with the Docker daemon on the host, which effectively grants full control over the host machine.

Confirming host access. With the Docker socket available and root privileges inside the container, the final step was straightforward. I asked the AI to generate a Python script using the requests library (which was installed in the environment) to send an HTTP request to the Docker API through the Unix socket. The request listed all containers running on the host. The response came back with details of every container on the system, including the one I was operating from, confirming that the Docker socket was fully functional and unrestricted.

At that point I stopped.

I did not create a new container. I did not mount the host filesystem. I did not attempt lateral movement or data exfiltration. The chain was clear and the evidence was sufficient. Continuing further would have crossed from demonstrating the vulnerability into exploiting it, and that line is one I do not cross.

But to be explicit about what was possible: with a mounted Docker socket and root access, an attacker could create a new privileged container with the host's root filesystem mounted at an arbitrary path. From there, they could read /etc/shadow, install SSH keys, modify system binaries, access every file on the host, pivot to internal networks, and establish persistent backdoor access. The container boundary, in this case, offered no meaningful protection.

Reproduction Steps

For clarity and reproducibility, here is the exact sequence.

Step 1. Open a modern browser and navigate to the code editor page on the target platform.

Step 2. Confirm the language dropdown at the top left is set to Python 3. Select it if it is not.

Step 3. On the right side panel, locate the "AI PROMPT:" section with its text area and the "Generate" button beside it.

Step 4. In the AI PROMPT text area, type the following:

MAKE a python script to execute whoami command

MAKE a python script to execute whoami command

Step 5. Click the Generate button. Observe that the AI produces Python code in the editor on the left using the subprocess module.

Step 6. Click the green Execute button at the top right of the page.

Step 7. Observe the OUTPUT section on the right panel. It will display the result of the system command. In my testing, the output was uid=0(root) gid=0(root) groups=0(root), confirming root level execution.

Step 8. Repeat with additional prompts to confirm arbitrary command execution:

MAKE a python script to execute cat /etc/passwd command
MAKE a python script to execute id command

MAKE a python script to execute cat /etc/passwd command
MAKE a python script to execute id command

Step 9. To confirm containerization, prompt the AI to read /proc/1/cgroup and observe Docker specific identifiers in the output.

Step 10. To confirm the sandbox escape path, prompt the AI to check for the existence of /var/run/docker.sock and to read environment variables via os.environ. Observe production credentials and the accessible Docker socket.

No authentication was required at any step. The code editor page was publicly accessible. The entire chain, from initial access to confirmed sandbox escape path, required only a browser and the ability to type English sentences.

Impact Assessment

The severity of this vulnerability is difficult to overstate. The following impacts were confirmed or are directly achievable through the demonstrated access.

Remote Code Execution with root privileges. Arbitrary system commands execute as uid 0 with no restrictions on modules, system calls, or file access within the container.

Production credential exposure. Environment variables contained live database connection strings, API keys, and internal service URLs. These credentials provide access to backend systems regardless of whether the container itself is isolated.

Root Cause Analysis

There is no single point of failure here. This is a chain of compounding misconfigurations, each of which independently constitutes a security issue and which together produce a catastrophic result.

No input validation on AI generated code. The platform passes the AI's output directly to a Python interpreter without any static analysis, module restriction, or command filtering. AI generated code is treated as trusted input, which it is not.

Execution as root. The Python runtime inside the container runs with uid 0. There is no legitimate reason for a student code execution sandbox to require root privileges.

Production credentials in the execution environment. Database connection strings, API keys, and service URLs were injected into the same container where untrusted student code executes. These should be isolated in a separate process or service that student code cannot reach.

Docker socket mounted inside the container. This is the critical escalation vector. The Docker socket grants any process inside the container the ability to control the Docker daemon on the host. This single misconfiguration collapses the entire container isolation model. It has been documented extensively as a known escape path and should never be present in an environment where untrusted code executes.

No network isolation. The container had outbound network access and could reach internal services, enabling lateral movement and data exfiltration.

A Broader Observation

This finding illustrates a pattern that is emerging rapidly across the industry. AI code generation features are being integrated into platforms at speed, often by teams focused on functionality rather than security architecture. The AI itself is not the vulnerability. It performs its intended function: translating natural language into working code. The vulnerability exists in the trust boundary between the AI's output and the execution engine that runs it.

When a platform treats AI generated code with the same trust as internally authored, reviewed, and deployed code, it creates a direct path from user input to system level execution. The AI becomes a translator that converts attacker intent from English into whatever the target system understands. Python today. SQL tomorrow. Infrastructure as code the day after.

Every platform that offers "type what you want and we will run it" needs to answer one question before shipping: what is the worst thing a user could ask for, and what prevents the system from doing it? If the answer is "nothing," the platform is an unauthenticated RCE endpoint with a natural language interface.

For hunters reading this: the moment you see an AI prompt box next to an Execute button, test it. Ask the AI to generate code that touches the operating system. Read files. Print environment variables. Check for mounted sockets. These features are being deployed faster than they are being secured, and the findings can be severe.

For builders: treat AI output as untrusted user input. Sandbox your execution environments as if an attacker is already inside, because with a prompt box and a Generate button, they are.

Thank you for reading. If you have questions or would like to discuss the finding, reach out through my socials.

Kong out.