Author: nopnop (@__nopnop)
Published: August 26, 2026
Source: https://nopnop.pro/2026/08/26/escaping-google-cloud-application-integration-sandbox/
Summary
Security researcher nopnop documents a sandbox-escape vulnerability, CVE-2025-0982, in Google Cloud’s Application Integration service. The service’s JavaScript task feature ran customer code on the Rhino engine (a Java-based JavaScript interpreter), and a weakness in its custom Java sandbox let the author break out and execute arbitrary OS commands inside Google’s own Borg cluster infrastructure — categorized by Google as a “Breach of Google Cloud’s production environment.” The finding was reported to Google’s Vulnerability Reward Program (VRP), triaged P0/S0, and mitigated within 48 hours; it earned a $75,000 bounty. Google switched new JavaScript tasks to the V8 engine, fully deprecated and blocked Rhino on March 30, 2026, and published security bulletin GCP-2026-044. The findings are verified through real exploitation against the live service, not theoretical.
Technical Details
Application Integration is a fully managed iPaaS; because Google runs the execution environment itself, a sandbox escape there impacts Google infrastructure rather than an isolated customer tenant, which is what made it an unusually high-value target. The JavaScript task ran on Rhino, which can reach into Java classes from JavaScript and therefore requires strict sandboxing. Google implemented that sandbox with a custom Java Security Manager stack: a server-wide GoogleSecurityManager/TaskSecurityPolicy (path-based file read/write/delete/exec rules) plus a SandboxingGoogleSecurityManager that marks a script’s thread untrusted and routes its checks through a per-thread JavaScriptPermissionChecker.
The author first probed the Java access available from JavaScript, learned the sandbox class name from a SecurityException message, and used environment reconnaissance (Java system properties, working-directory paths referencing borglet) to confirm the code ran on Borg. To study the sandbox, they exfiltrated the large server binaries — which turned out to be ELF executables with embedded Java classes — through the only available channel, the size-limited event.log() output, by base64-chunking the files and reassembling them offline, then decompiled the classes.
The root cause was two misconfigurations in that sandbox that combined into an escape:
- An over-broad reflection permission. The checker’s static
COMMON_PERMISSIONSset includedReflectPermission("suppressAccessChecks")(added so Rhino would function). Because that permission enables reflection to bypass access modifiers, the script could reach the private staticCOMMON_PERMISSIONSfield itself and add permissions to it — includingAllPermission, which made the per-threadPermissionCheckerapprove everything for the script’s thread. - Execute rights on the Java binary. The startup policy granted
FileOperation.EXECon$JAVA_HOME/bin/java, and scripts already had write access to/tmp.
Crucially, disabling the thread checker did not by itself grant code execution: the server-wide TaskSecurityPolicy still governed all file and exec operations. The escape worked because process creation needs JVM runtime permissions (for the internal thread that reaps the child process) that were only gated by the now-neutralized per-thread checker, not by TaskSecurityPolicy. The resulting chain was therefore: use reflection to grant AllPermission and the needed runtime permissions, write a small Java payload class to /tmp, and run it via the permitted $JAVA_HOME/bin/java to obtain command execution. This summary describes the mechanism at a conceptual level and omits the article’s full payload code.
Impact
Successful exploitation gave arbitrary command execution as the service’s execution identity inside Google’s Borg production infrastructure — a breach of Google Cloud’s production environment rather than a single customer’s tenant, which is why Google rated it P0/S0 and awarded a top-tier $75,000 bounty. The author notes network egress was blocked from the sandbox, but code execution on Google’s core infrastructure is inherently severe. There is no customer-side “affected version,” since this was a flaw in a Google-operated managed service.
Mitigation
Remediation was entirely Google-side and is complete: within 48 hours of the report Google mitigated the issue by disabling Rhino, moved new JavaScript tasks to the V8 engine (Jan 2025), and by March 30, 2026 fully deprecated and blocked Rhino (pre-2025 integrations required migration). Google published bulletin GCP-2026-044. Customers of Application Integration need take no action beyond migrating any legacy Rhino-based JavaScript tasks. The transferable lessons for anyone building language sandboxes: a single powerful primitive like suppressAccessChecks can unravel an entire reflection-based sandbox, so keep security-critical permission sets immutable and out of reach of sandboxed code; do not grant execute rights on interpreters/runtimes (e.g. the java binary) to confined workloads; and ensure every enforcement layer covers the same operations, since a gap where one layer (here, runtime/thread permissions) is guarded by only a single, defeatable check is enough to escape.