GraalVM 25 adds stricter JavaScript/WebAssembly sandboxing via Polyglot API

What’s new

GraalVM 25 formalizes sandbox policies that let JVM hosts run guest JavaScript or WebAssembly with clear security boundaries. Use cases are familiar: third‑party dependencies, user plugins, and server scripting where you want customization without giving away the keys to the kingdom. The platform ships predefined policies from TRUSTED to CONSTRAINED (and an UNTRUSTED option for truly hostile code), and each policy both preconfigures context/engine defaults and validates any further customizations so you can’t accidentally weaken protections.

How it works

Policies map to concrete restrictions: CONSTRAINED requires explicit language lists, bans native access and process creation, blocks system exit where supported, redirects stdout/stderr, and forbids host file/socket/environment access and most host object/method interactions unless intentionally allowed. Validation is the guardrail — change a setting and the policy checks whether that change breaks the intended security posture. It’s polyglot at heart: your JVM app still runs the guest code via the Polyglot API, but now with a permissions model that behaves a lot like sandboxing in browsers or container runtimes.

Why it matters

Who wants a rogue plugin to bring down the JVM? No one. Sandboxing addresses the uncomfortable reality of supply‑chain risk and multi‑tenant servers by making least‑privilege the default for untrusted logic. It has been reported that teams experimenting with GraalVM are already using these policies for plugin ecosystems and isolated scripting—so expect more projects to treat embedded scripting like a first‑class security concern, not an afterthought.

Sources: graalvm.org, Lobsters