ScriptTriggerExecutor sets allowedPackages to java.lang., java.util., java.time., java.math. (ScriptTriggerExecutor.java:56); trigger creation is gated only at UPDATE SCHEMA (LocalSchema.createTrigger:636). Permitting java.lang.* host-class lookup lets a trigger script do Java.type("java.lang.Runtime").getRuntime().exec(...) (or ProcessBuilder). The reflection denylist does not block Java.type host lookups, and allowCreateProcess(false) only restricts GraalVM's guest process API, not a host Runtime.exec reached through HostAccess.ALL.

Exploit: a user with UPDATE SCHEMA (schema admin, strictly less than security admin) runs CREATE TRIGGER ... EXECUTE JAVASCRIPT '<runtime.exec>' and obtains OS RCE when the trigger fires.

Fix: remove java.lang.* (and narrow the rest) from the trigger allow-list; if host interop is needed, expose an explicit @HostAccess.Export API surface instead of whole packages; consider gating trigger creation at UPDATE SECURITY. Prefer an allow-list (HostAccess.EXPLICIT) over the current denylist-over-HostAccess.ALL.

Related medium/low items to fold into the fix: IMPORT DATABASE SSRF via unfollowed-redirect re-validation (SourceDiscovery.java:113), BACKUP/EXPORT DATABASE missing authorization (BackupDatabaseStatement.java:56, ExportDatabaseStatement.java:52), chunked-transfer body-size DoS bypass (HttpServer.java:301,318-333), and no brute-force lockout on password auth (ServerSecurity.java:189-205).