CVE-2026-48708

An attacker with network access to the OliveTin web interface triggers two or more action executions concurrently (e.g., by firing simultaneous HTTP POST requests to `/api/StartAction`). Because each request runs in a separate goroutine and the template engine uses a single unsynchronized `text/template.Template` instance, one goroutine's `Parse` can overwrite the internal template tree while another goroutine's `Execute` is still reading it [ref_id=1]. This race can cause cross-user command contamination (User A's arguments rendered in User B's shell command), a Go runtime panic from concurrent map writes (process crash), or execution of unintended shell commands. The CVSS reflects the need for low privileges and high attack complexity (the race window must be hit).

The race condition lives in `service/internal/tpl/templates.go`, where a package-level `var tpl = template.New("tpl")` is shared across all goroutines. Every action execution calls `parseTemplate` which performs `tpl.Parse(source)` followed by `t.Execute()` on that same singleton without any synchronization. The call chain from `service/internal/executor/executor.go` shows that each `ExecRequest` spawns a goroutine, so concurrent actions race on the shared template instance.

The advisory recommends creating a new template per `parseTemplate` call instead of reusing the package-level singleton: `template.New("").Option("missingkey=error").Funcs(...).Parse(source)` [ref_id=1]. This eliminates the shared mutable state entirely because each goroutine gets its own independent `*template.Template` object, so concurrent `Parse` and `Execute` calls cannot interfere with each other. The patch does not appear in the bundle, but the advisory explicitly states that option 1 (new template per call) is the recommended fix.