GHSA-364q-w7vh-vhpc is a high-severity (CVSS 8.5) Path Traversal vulnerability in github.com/OliveTin/OliveTin. O3 Security confirms whether GHSA-364q-w7vh-vhpc is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OliveTin's unsafe parsing of UniqueTrackingId can be used to write files
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
When the saveLogs feature is enabled, OliveTin persists execution log entries to disk. The filename used for these log files is constructed in part from the user-supplied UniqueTrackingId field in the StartAction API request. This value is not validated or sanitized before being used in a file path, allowing an attacker to use directory traversal sequences (e.g., ../../../) to write files to arbitrary locations on the filesystem.
Affected Code
Entry point — service/internal/api/api.go (line 130):
The UniqueTrackingId from the API request is passed directly to the executor without validation:
execReq := executor.ExecutionRequest{
Binding: pair,
TrackingID: req.Msg.UniqueTrackingId, // user-controlled, no validation
// ...
}
Tracking ID accepted as-is — service/internal/executor/executor.go (lines 508–512):
The tracking ID is only replaced with a UUID if it is empty or a duplicate. Any other string, including one containing path separators, is accepted:
_, isDuplicate := e.GetLog(req.TrackingID)
if isDuplicate || req.TrackingID == "" {
req.TrackingID = uuid.NewString()
}
Filename construction — service/internal/executor/executor.go (line 1042):
The tracking ID is interpolated directly into the log filename:
filename := fmt.Sprintf("%v.%v.%v",
req.logEntry.ActionTitle,
req.logEntry.DatetimeStarted.Unix(),
req.logEntry.ExecutionTrackingID,
)
File write — service/internal/executor/executor.go (lines 1068–1069 and 1082–1083):
The filename is joined to the configured log directory using path.Join, which calls path.Clean internally. path.Clean resolves .. path segments, causing the final file path to escape the intended directory:
// Results file (.yaml)
filepath := path.Join(dir, filename+".yaml")
err = os.WriteFile(filepath, data, 0600)
// Output file (.log)
filepath := path.Join(dir, filename+".log")
err := os.WriteFile(filepath, []byte(data), 0600)
Proof of Concept
An attacker sends the following StartAction request (Connect RPC or REST):
{
"bindingId": "<any-executable-action-id>",
"uniqueTrackingId": "../../../tmp/pwned"
}
Assuming the action title is Ping the Internet and the timestamp is 1741320000, the constructed filename becomes:
Ping the Internet.1741320000.../../../tmp/pwned
When path.Join processes this with a configured results directory like /var/olivetin/logs:
path.Join("/var/olivetin/logs", "Ping the Internet.1741320000.../../../tmp/pwned.yaml")
path.Clean resolves the traversal:
- Path segments:
["var", "olivetin", "logs", "Ping the Internet.1741320000...", "..", "..", "..", "tmp", "pwned.yaml"] - The
..segments traverse upward past the log directory. - Final resolved path:
/tmp/pwned.yaml
Two files are written:
.yamlfile — contains YAML-serializedInternalLogEntry(action title, icon, timestamps, exit code, output, tags, username, tracking ID).logfile — contains the raw command output (potentially attacker-influenced if the action echoes its arguments)
Impact
- Arbitrary file write to any path writable by the OliveTin process.
- OliveTin frequently runs as root inside Docker containers, so the writable scope is often the entire filesystem.
- An attacker could:
- Overwrite OliveTin's own
sessions.yamlto inject authenticated sessions. - Write to entity file directories to inject malicious entity data.
- Write to system cron directories or other locations to achieve remote code execution.
- Cause denial of service by overwriting critical system files.
- Overwrite OliveTin's own
Suggested Fix
Validate the UniqueTrackingId to ensure it only contains safe characters before use. A strict UUID format check is the simplest approach:
import "regexp"
var validTrackingID = regexp.MustCompile(`^[a-fA-F0-9\-]+$`)
// In ExecRequest, before accepting the user-supplied ID:
if req.TrackingID == "" || !validTrackingID.MatchString(req.TrackingID) {
req.TrackingID = uuid.NewString()
}
Alternatively, sanitize the filename in stepSaveLog by stripping or rejecting path separators and .. sequences.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/OliveTin/OliveTin | all versions | 0.0.0-20260309102040-b03af0e2eca3 |
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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/OliveTin/OliveTin to 0.0.0-20260309102040-b03af0e2eca3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-364q-w7vh-vhpc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-364q-w7vh-vhpc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-364q-w7vh-vhpc. 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-364q-w7vh-vhpc in your dependencies?
O3 detects GHSA-364q-w7vh-vhpc across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.