CVE-2026-48708

Summary

Summary OliveTin's template engine uses a single shared text/template.Template instance (tpl package-level variable in service/internal/tpl/templates.go) across all goroutines. Every action execution calls tpl.Parse(source) followed by t.Execute() on this shared instance with no synchronization. When two or more actions execute concurrently (which is the normal case, each ExecRequest spawns a goroutine), a race condition occurs: one goroutine's Parse overwrites the template tree while another goroutine is calling Execute, causing: Cross-user command contamination: User A's arguments rendered in User B's shell command template Go runtime panic: Concurrent map writes in Go's text/template internal structures cause a fatal crash Incorrect command execution: Template/argument mismatch produces unexpected or dangerous shell commands CWE CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) CWE-567 (Unsynchronized Access to Shared Data in a Multithreaded Context) Affected Versions All versions (the shared template has existed since the template system was introduced) Details The Shared Template Instance In service/internal/tpl/templates.go: This is a package-level variable, a single template.Template shared across the entire process. Unsafe Parse + Execute Pattern The parseTemplate function is called for every template rendering: Critical: tpl.Parse(source) returns the same pointer as tpl (Go's template.Parse modifies the receiver and returns it). So t and tpl are the same object. When two goroutines call parseTemplate concurrently: If the goroutines interleave: Goroutine A would execute rm -rf {{ .Arguments.path }} with dataA, which either errors (missing key) or, if dataA happens to have a path argument, executes with an unintended value. No Synchronization Exists A search for any synchronization primitives in the tpl package confirms zero mutex, lock, or atomic operations: Concurrent Goroutine Confirmation In service/internal/executor/executor.go, ExecRequest launches each action in a new goroutine: The execution chain includes stepParseArgs, which calls ParseTemplateWithActionContext, which calls parseTemplate. Multiple concurrent action executions will race on the shared tpl variable. Go Runtime Crash Vector Go's text/template.Parse internally modifies the template's common struct, which contains a tmpl map[string]Template. In Go, concurrent map writes cause an unrecoverable fatal error: This is not a panic that can be recovered, it terminates the entire process. Two concurrent Parse calls can trigger this, crashing OliveTin. Template Contamination Vector Even without a crash, the race can produce dangerous results: User A triggers action: shell: "echo Hello {{ .Arguments.name }}" with name=Alice User B triggers action: shell: "sudo systemctl restart {{ .Arguments.service }}" with service=nginx Race occurs: User A's Execute runs on User B's parsed template If User A's arguments contain a service key, that value is substituted into sudo systemctl restart {{ .Arguments.service }} If User A's arguments do NOT contain service, missingkey=error causes an error, but only AFTER the template was already partially evaluated Call Chain PoC Prerequisites OliveTin instance with at least 2 configured actions Ability to trigger concurrent action executions Config Step 1: Trigger concurrent executions Step 2: Check for crash Step 3: Check logs for contamination Python PoC, Race Trigger Go Race Detector Verification If you can run OliveTin with Go's race detector enabled: Expected output: Impact Process Crash (DoS): Concurrent map writes in Go cause an unrecoverable fatal error, crashing the entire OliveTin service Cross-User Command Contamination: User A's arguments may be rendered in User B's shell command template, potentially executing commands with wrong/dangerous arguments Privilege Escalation via Contamination: If a low-privilege user's arguments contaminate a high-privilege action's template, the result could be unintended command execution Data Leakage: Arguments (which may contain secrets like passwords) could be rendered in another user's action output Remediation Create a new template per parse call instead of reusing the package-level singleton: go func parseTemplate(source string, data any) (string, error) { t, err := template.New(""). Option("missingkey=error"). Funcs(template.FuncMap{"Json": jsonFunc}). Parse(source) if err != nil { return "", err } var sb strings.Builder err = t.Execute(&sb, data) // ... } Alternative: Use template.Must(tpl.Clone()) to create a thread-safe copy per call: go func parseTemplate(source string, data any) (string, error) { clone, _ := tpl.Clone() t, err := clone.Parse(source) // ... } Alternative: Add a mutex around parseTemplate (but this serializes all template rendering and hurts performance): go var tplMutex sync.Mutex func parseTemplate(source string, data any) (string, error) { tplMutex.Lock() defer tplMutex.Unlock() // ... } Option 1 (new template per call) is the recommended fix, it's simple, safe, and has negligible performance impact. Resources Go text/template documentation: "A Template's Parse method must not be called concurrently" CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization service/internal/tpl/templates.go, shared tpl variable and parseTemplate function service/internal/executor/executor.go, ExecRequest goroutine launch (line ~524)

Impact

Affected versions

Security releases

Remediation advice