GHSA-xc5w-4v5w-7x65 is a medium-severity (CVSS 6.6) OS Command Injection vulnerability in github.com/OliveTin/OliveTin. O3 Security confirms whether GHSA-xc5w-4v5w-7x65 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OliveTin OS Command Injection via Custom regex: Argument Type Bypassing Shell Safety Check
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-xc5w-4v5w-7x65.
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-xc5w-4v5w-7x65 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 372,324 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 checkShellArgumentSafety() function maintains a blocklist of argument types unsafe for Shell mode actions, but does not include regex:-prefixed types. Because regex: support was added independently via typeSafetyCheckRegex(), any Shell mode action using a regex:-typed argument bypasses the safety check unconditionally. The unvalidated value is then interpolated directly into the sh -c command string via Go's text/template with no escaping, enabling shell injection. Notably, even restrictive-looking patterns are exploitable — for example, a pattern blocking common shell metacharacters remains bypassable via POSIX command substitution.
Details
OliveTin is an open source web UI for running pre-configured shell commands. In the OliveTin service component, the function checkShellArgumentSafety() in service/internal/executor/arguments.go enforces a blocklist of argument types that are unsafe for use in Shell mode actions (actions that execute via sh -c). The blocklist includes password, very_dangerous_raw_string, url, email, and raw_string_multiline. It does not handle custom regex: prefixed argument types.
Custom regex: types are supported by a separate function, typeSafetyCheckRegex(), which checks whether a submitted value matches the provided pattern. These two functions evolved independently: when regex: prefix support was added to typeSafetyCheckRegex, checkShellArgumentSafety was not updated to treat regex: types as unsafe for Shell mode. As a result, any action configured with a Shell mode handler and a regex:-typed argument passes the safety check unconditionally, regardless of how permissive or restrictive the pattern is.
The argument value then reaches handleShellBranch → wrapCommandInShell, where Go's text/template interpolates it directly into the sh -c command string with no escaping.
Critically, this vulnerability is not limited to obviously permissive patterns like regex:.*. An admin who writes a restrictive-looking pattern such as regex: ^[^;|&<>]+$ - explicitly blocking the five most common shell injection characters (semicolon, pipe, ampersand, both redirects) — is still fully exploitable via POSIX command substitution.
PoC
- Deploy OliveTin
docker run -d --name olivetin-poc -p 1337:1337 \
-v /tmp/olivetin-poc/config:/config \
ghcr.io/olivetin/olivetin:3000.11.3
- Write the configuration below as /tmp/olivetin-poc/config/config.yaml , which represents a realistic admin-authored action: a Shell mode command that accepts user-supplied input validated by a custom regex pattern.
actions:
- title: Custom Input Action
id: custom_input
shell: echo "Input was {{ .Arguments.customInput }}"
arguments:
- name: customInput
type: "regex:^[^;|&<>]+$"
title: Custom Input
- Trigger RCE via command substitution.
curl -s -X POST http://localhost:1337/api/v1/StartAction \
-H "Content-Type: application/json" \
-d '{"bindingId":"custom_input","arguments":[{"name":"customInput","value":"$(touch /tmp/rce_proof)"}]}'
- Now verify RCE by checking presence of file
docker exec olivetin-poc ls -la /tmp/rce_proof
Impact
An unauthenticated attacker with network access to an OliveTin instance can achieve full OS command injection - and in practice remote code execution — as the OliveTin process user, provided a Shell mode action exists with any regex:-typed argument whose pattern permits $, backtick, or parentheses.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/OliveTin/OliveTin | ≥ 0.0.0-20251025234746-ef5a67e7b8ea&&< 0.0.0-20260708084548-995ff79736f2 | 0.0.0-20260708084548-995ff79736f2 |
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-20260708084548-995ff79736f2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xc5w-4v5w-7x65 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-xc5w-4v5w-7x65 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-xc5w-4v5w-7x65. 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-xc5w-4v5w-7x65 in your dependencies?
O3 detects GHSA-xc5w-4v5w-7x65 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.