Script Sandbox Escape Leaks a Persistent Production API Key
The Risk
This platform offers a feature that runs a user's small program in what it describes as a safe, locked-down box. That box was not actually a real barrier: any logged-in user could break out of it and run ordinary system commands on the company's own production servers. While doing so, an attacker could read a working access key that the server quietly placed inside the box, and that key kept working long after the job finished, even after logging out. The damage was limited because the key only reached the attacker's own account and the servers were otherwise well fenced off, but the feature was presented as a trustworthy place to handle secrets and that trust was misplaced.
The Vulnerability
The script-pipeline feature advertises a sandboxed Python environment. It blocks a small fixed set of modules and the file-open builtin, but the deny list is enforced by module name only. That is the entire weakness.
Allowed modules transitively import the blocked ones, so simple attribute access re-exposes them. Importing a permitted networking module and then reaching through it to the operating-system module returned the full, unrestricted module even though importing it by name raised an error. From there, the standard process-spawning calls were available, which is arbitrary command execution inside the production worker pod, not merely file reading.
The same name-only weakness left a native file-read capability and a native-library loading capability directly usable. The sandbox source file itself was world-readable inside the pod, disclosing the exact allow and deny lists an attacker would use to refine the escape.
The Attack
Leaking the per-job key
Every job pod had a live API key injected into its environment. A script that read the process environment file printed that key into the job logs in plaintext. The job that runs the script and the log endpoint that returns its output are both ordinary authenticated API actions, so no special role was required.
- Generate an API key on your own account through the normal profile page.
- Create a pipeline whose script stage reads the process environment file using an allowed module.
- Trigger a job and poll until it completes.
- Read the job logs. The script output block contains the full pod environment, including the injected key, plus the disclosed sandbox source showing the deny lists.
Proving the key persists
The leaked key authenticated independently against the production API and returned the owner's data, confirming it was live. Critically, it was not revoked when the job completed, so it became a long-lived credential that survived session logout and refresh-token revocation.
Arbitrary command execution
Running a script that reached the operating-system module through an allowed module and called the process-spawning functions returned the worker's user identity, the kernel banner, and the contents of the system password file. This proved full in-pod command execution rather than file read alone.
The Impact
Two concrete consequences were demonstrated against production: arbitrary command execution inside the worker pod, and theft of a persistent API key that outlived the job. Both stem from a Python isolation boundary the product presents as trustworthy.
The impact was genuinely capped by the surrounding defense-in-depth, which is why this is High rather than Critical. The leaked per-job key was scoped to the attacker's own user: it listed only the attacker's own projects, cross-tenant project reads returned not-found at the database layer, and billing returned permission-denied. The log endpoint that carries the leak enforced per-object ownership with random identifiers and no global or admin listing, so an attacker could not harvest other tenants' leaked keys. Outbound network egress was firewalled, no cluster service-account token was mounted, the pod ran unprivileged with all capabilities dropped under a kernel-level sandbox, and the certificate material present was a self-signed placeholder that could not impersonate the public edge.
So this is a genuine in-pod sandbox escape plus persistent self-scoped credential theft within the attacker's own tenant, not a cross-tenant or cluster compromise. It still fully defeats an isolation boundary that users may reasonably trust with secrets.
Remediation
- Do not rely on a name-only deny list. Module blocking that checks the import name is trivially bypassed by reaching the same module through an allowed one. Run untrusted scripts in a real isolation boundary at the process or kernel level rather than an in-interpreter filter.
- Do not inject a live, broadly-scoped API key into the script environment. If the script needs credentials, scope them tightly to the job and revoke them the instant the job ends.
- Ensure per-job credentials are short-lived and bound to the job, so a leaked value cannot outlive the work it was issued for.
- Remove world-readable sandbox internals from the worker pod so the exact allow and deny lists are not handed to an attacker.