The GHSA-48qw hardening added a checkPermissionsOnDatabase(UPDATE_SECURITY) gate on the polyglot engine (PolyglotQueryEngine.java:112-114,126,176,199), but only there. The SQL route to JavaScript never touches it: DefineFunctionStatement.executeSimple (DefineFunctionStatement.java:37-100), LocalSchema.registerFunctionLibrary, and SQLQueryEngine library-function invocation (SQLQueryEngine.java:198-224) do no scripting-permission check.
Exploit: any user authorized for the DB (including a read-only role) runs POST /api/v1/command/ {"language":"sql","command":"DEFINE FUNCTION x.run "" LANGUAGE js"} then SELECT x.run(), executing arbitrary JavaScript and defeating the control meant to restrict scripting to security admins. On this path allowedPackages is empty so Java.type host lookup and reflection are blocked, but IOAccess.ALL still permits load(url) SSRF/remote-JS inclusion and unbounded CPU/memory DoS.
Fix: gate DefineFunctionStatement.executeSimple, the SQLQueryEngine library-function wrapper (to also cover pre-existing libraries), and DeleteFunctionStatement with UPDATE_SECURITY for js/polyglot languages. Centralize as one assertCanExecuteUserCode(database) invoked by every code-execution surface. Also set IOAccess.NONE / PolyglotAccess.NONE on the Context (GraalPolyglotEngine.java:86,91).
The GHSA-48qw hardening added a checkPermissionsOnDatabase(UPDATE_SECURITY) gate on the polyglot engine (PolyglotQueryEngine.java:112-114,126,176,199), but only there. The SQL route to JavaScript never touches it: DefineFunctionStatement.executeSimple (DefineFunctionStatement.java:37-100), LocalSchema.registerFunctionLibrary, and SQLQueryEngine library-function invocation (SQLQueryEngine.java:198-224) do no scripting-permission check.
Exploit: any user authorized for the DB (including a read-only role) runs POST /api/v1/command/ {"language":"sql","command":"DEFINE FUNCTION x.run "" LANGUAGE js"} then SELECT x.run(), executing arbitrary JavaScript and defeating the control meant to restrict scripting to security admins. On this path allowedPackages is empty so Java.type host lookup and reflection are blocked, but IOAccess.ALL still permits load(url) SSRF/remote-JS inclusion and unbounded CPU/memory DoS.
Fix: gate DefineFunctionStatement.executeSimple, the SQLQueryEngine library-function wrapper (to also cover pre-existing libraries), and DeleteFunctionStatement with UPDATE_SECURITY for js/polyglot languages. Centralize as one assertCanExecuteUserCode(database) invoked by every code-execution surface. Also set IOAccess.NONE / PolyglotAccess.NONE on the Context (GraalPolyglotEngine.java:86,91).