2026.09.57 — 2026-09-28

Breaking

• Run installation-wide jobs once across instances (b3059c3d)

  When several Studio instances share one database, every instance used to run every background job, so housekeeping, reapers, sweeps and partition maintenance ran once per instance. Jobs whose work is on shared state now run on one instance per tick, through ShedLock on Studio's database (a new shedlock table): preview housekeeping, the event, request-reply and metric reapers, the request-reply deadline sweep, partition maintenance, scrape tier C and topology discovery. A crashed instance frees its jobs within a minute or one interval. The job status API reports each job's scope and when another instance last ran it; a tick another instance ran never makes a job look stalled.

Added

• Run installation-wide jobs once across instances (b3059c3d)

  When several Studio instances share one database, every instance used to run every background job, so housekeeping, reapers, sweeps and partition maintenance ran once per instance. Jobs whose work is on shared state now run on one instance per tick, through ShedLock on Studio's database (a new shedlock table): preview housekeeping, the event, request-reply and metric reapers, the request-reply deadline sweep, partition maintenance, scrape tier C and topology discovery. A crashed instance frees its jobs within a minute or one interval. The job status API reports each job's scope and when another instance last ran it; a tick another instance ran never makes a job look stalled.

Security

• Update the embedded Tomcat to 11.0.25 (8fafe514)

  Spring Boot 4.1 still manages Tomcat 11.0.24, which carries three critical vulnerabilities (GHSA-9xv2-5v5q-p794, GHSA-gcx9-497g-6cp6, GHSA-h3x4-894j-xpx5). Studio now runs 11.0.25. The plugin template compiles against the same version.

  Development tooling is patched too: adm-zip, used by the module federation build, is raised to 0.6.1, and the documentation site builds on Vite 6.4.3. Neither ships in the image.

• Send a Content-Security-Policy and sandbox plugin SVG assets (a782d7b3)

  Every response now carries a Content-Security-Policy. Scripts, connections and workers must come from Studio's own origin, plugins (object/embed) are refused, and no page may frame Studio. If an injection bug ever let markup through, it could neither load a script from elsewhere nor send data out.

  Every SVG a plugin serves is now sandboxed, as its icon already was, so an SVG opened directly renders inert instead of running as Studio.

  Plugin UIs are unaffected when they bundle what they load, as the plugin guide asks. A UI that pulled scripts, fonts or data from another origin must bundle them instead.

• End a user's sessions when their access is taken away (f2b0ac59)

  Disabling a user, removing a grant from them, or changing a role's permissions now signs out every affected user at once. Their next request answers 401. Before, a session kept the grants it had at sign-in until it timed out, up to 8 hours.

  Sessions are also stored in the database again. Spring Boot 4 moved session auto-configuration into its own module, which was missing, so sessions were held in memory: lost on restart and not shared between instances. Studio now uses spring-boot-starter-session-jdbc and the existing spring_session tables. The session cookie is now named SESSION instead of JSESSIONID, so everyone signs in again once after upgrading.

• Require CSRF unless a bearer token authenticated the request (0fd38986)

  A request that carried any Authorization header skipped the CSRF check, even when the header authenticated nothing. Next to a signed-in browser's session cookie, a junk header (Basic, an unknown bearer token, anything) let a state-changing request through without a CSRF token.

  An Authorization header that is not a valid API bearer token is now refused with 401, and only a request a bearer token authenticated skips CSRF. API clients that send a valid token see no change; a client that sent a stale or malformed header alongside a session must drop it.