A sandbox escape vulnerability in an algorithmic trading competition platform allowed an attacker to extract live AWS IAM credentials using only standard Python.
A simple Base64 encoding trick adds to a growing body of research revealing that cloud sandbox isolation is far weaker than vendors advertise.
Researcher JakOb discovered the flaw on April 15, 2026, while participating in the platform’s competition, and responsibly disclosed it the same day.
The platform evaluates user-submitted Python trading bots inside AWS Lambda execution environments (eu-west-1, Python 3.12), which were assumed to be fully isolated.
AWS Lambda Vulnerability
The researcher first identified that the platform applied a plaintext keyword output filter to detect sensitive data in logs, then bypassed it entirely by Base64-encoding the payload before printing it.
In a single submission run, the researcher recovered the full set of temporary AWS STS credentials AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN along with the internal file system structure of /var/task.
which contained platform-internal Python files co-deployed alongside participant submissions. Because os.listdir() succeeded without any additional privileges, reading those files would require nothing more than a follow-up probe.
Just weeks earlier, on April 6, 2026, Palo Alto Networks’ Unit 42 published “Cracks in the Bedrock,” documenting critical vulnerabilities in Amazon Bedrock AgentCore’s Code Interpreter sandbox.
Researchers demonstrated that the sandbox permitted recursive DNS queries to arbitrary public domains. enabling DNS tunneling to exfiltrate sensitive IAM credentials and establish a full command-and-control channel from inside the sandbox.
The technique of encoding sensitive data, such as environment variables, into Base64 subdomains mirrors almost exactly what JakOb used in the trading platform attack.
Separately, Trend Micro researchers in 2025 documented how overprivileged containers in Amazon EKS environments could be exploited via packet sniffing and API spoofing to extract AWS credentials directly from containerized workloads.
The consistent thread across all three cases: once attacker code runs in a cloud execution environment, inadequate process isolation renders the container itself the attack surface.
The trading platform’s core mistake was treating output filtering as a security control. The filter operated post-execution on plaintext, meaning the data was already collected by the time the filter ran.
Encoding the output bypassed it instantly, a technique well-documented in adversarial contexts. AWS’s own Bedrock Guardrails team has acknowledged this class of bypass, according to JakOb, noting that users can request encoded responses to circumvent output-level safety mechanisms.
Mitigation
Security experts and the researcher’s own whitepaper converge on the same set of mitigations:
- Enforce OS-level isolation using seccomp-restricted sandboxes such as nsjail or gVisor, never rely on import blocklists or keyword filters
- Strip sensitive environment variables before invoking untrusted code; AWS STS credentials should never be injected into an untrusted execution context
- Apply least-privilege IAM policies to Lambda execution roles, and shorten STS session durations to 15–30 minutes for automation workloads
- Log and alert on all STS AssumeRole usage via CloudTrail to detect potential credential abuse after exposure
- Replace unsafe deserialisers like
jsonpicklewith the standardjsonmodule to eliminate CWE-502 deserialization attack surfaces
The researcher confirmed that no credentials were used and no systems beyond the author’s own submission were accessed.
The vendor acknowledged the issue and added a fix to its to-do list. However, responses characterized the severity as limited, a position inconsistent with the actual blast radius that the exposed IAM role could permit.
No Comment! Be the first one.