Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-364q-w7vh-vhpc

HIGHFix: OliveTin/OliveTin@2f77000

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

Also known asCVE-2026-31817GO-2026-4670
Published
Mar 11, 2026
Updated
Mar 23, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Mar 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐹github.com/OliveTin/OliveTin

Real-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:

  1. Path segments: ["var", "olivetin", "logs", "Ping the Internet.1741320000...", "..", "..", "..", "tmp", "pwned.yaml"]
  2. The .. segments traverse upward past the log directory.
  3. Final resolved path: /tmp/pwned.yaml

Two files are written:

  • .yaml file — contains YAML-serialized InternalLogEntry (action title, icon, timestamps, exit code, output, tags, username, tracking ID)
  • .log file — 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.yaml to 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.

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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/OliveTin/OliveTinall versions0.0.0-20260309102040-b03af0e2eca3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

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
O3 Security · Impact-Aware SCA

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.

GHSA-364q-w7vh-vhpc: OliveTin Remote… | O3 Security