Skip to content

OliveTin has Unvalidated `ot_`-prefixed Arguments that Bypass Input Filtering

Moderate severity GitHub Reviewed Published May 31, 2026 in OliveTin/OliveTin • Updated Jun 24, 2026

Package

gomod github.com/OliveTin/OliveTin (Go)

Affected versions

< 0.0.0-20260531214440-ebffd9f040f7

Patched versions

0.0.0-20260531214440-ebffd9f040f7

Description

Description

The filterToDefinedArgumentsOnly function in the executor is intended to discard any arguments not explicitly defined in the action's configuration. However, a special case allows any argument whose name starts with ot_ to bypass this filter. While two system arguments (ot_executionTrackingId and ot_username) are injected by OliveTin and overridden, all other ot_-prefixed arguments supplied by the user pass through unmodified.

These bypassed arguments are:

  1. Not type-checked — the validation loop only iterates over the action's defined arguments, so ot_-prefixed arguments skip all type safety checks entirely.
  2. Set as environment variables — via buildEnv(), with completely unvalidated values, and passed to the executed command.
  3. Included in the template context — available as .Arguments.ot_* in template rendering.

Affected Code

Filter bypass — service/internal/executor/executor.go (lines 728–731):

func keepArgument(name string, definedNames map[string]struct{}) bool {
    _, ok := definedNames[name]
    return ok || strings.HasPrefix(name, "ot_")
}

System args only override two keys — service/internal/executor/executor.go (lines 742–745):

func injectSystemArgs(req *ExecutionRequest) {
    req.Arguments["ot_executionTrackingId"] = req.TrackingID
    req.Arguments["ot_username"] = req.AuthenticatedUser.Username
}

Any other ot_-prefixed argument (e.g., ot_malicious) survives both functions.

Unvalidated values become environment variables — service/internal/executor/executor.go (lines 867–882):

func buildEnv(args map[string]string) []string {
    ret := append(os.Environ(), "OLIVETIN=1")
    for k, v := range args {
        varName := fmt.Sprintf("%v", strings.TrimSpace(strings.ToUpper(k)))
        if varName == "" { continue }
        ret = append(ret, fmt.Sprintf("%v=%v", varName, v))
    }
    return ret
}

The value v is never validated. It can contain newlines, shell metacharacters, null bytes, or any arbitrary data.

Proof of Concept

An attacker sends a StartAction request with extra ot_-prefixed arguments:

{
  "bindingId": "<any-action-id>",
  "arguments": [
    { "name": "ot_custom_var", "value": "arbitrary unvalidated content \n with newlines" },
    { "name": "ot_another",    "value": "$(whoami)" }
  ]
}

These arguments:

  • Pass through filterToDefinedArgumentsOnly (the ot_ prefix exempts them).
  • Are never type-checked (not in the action's argument definitions).
  • Become environment variables OT_CUSTOM_VAR and OT_ANOTHER in the executed command's environment.
  • Are available in the template rendering context as .Arguments.ot_custom_var and .Arguments.ot_another.

Impact

  • Environment variable pollution — attacker can set arbitrary environment variables (with OT_ uppercased prefix) in the execution environment of any action they can trigger. Scripts or programs that read custom environment variables could be influenced.
  • Potential for secondary exploitation — if any executed script or command reads OT_-prefixed environment variables, the unvalidated content could cause unexpected behavior.
  • Template context pollution — although Go's text/template does not recursively evaluate data values (mitigating direct template injection), the extra arguments are accessible in the template context and could interact unexpectedly with custom template logic.

Suggested Fix

Remove the ot_ prefix exception from keepArgument, or restrict it to only the two known system arguments:

var systemArgs = map[string]struct{}{
    "ot_executionTrackingId": {},
    "ot_username":            {},
}

func keepArgument(name string, definedNames map[string]struct{}) bool {
    _, isDefined := definedNames[name]
    _, isSystem := systemArgs[name]
    return isDefined || isSystem
}

Discovery Methodology

Both vulnerabilities were identified through manual source code review of the OliveTin repository, focusing on:

  • Input validation boundaries (API request fields flowing into file system operations and execution contexts)
  • Argument filtering and type-checking logic in the executor
  • File path construction in the log persistence feature

No automated scanners or fuzzing tools were used. The review was conducted against the current main branch source code.


References

@jamesread jamesread published to OliveTin/OliveTin May 31, 2026
Published to the GitHub Advisory Database Jun 24, 2026
Reviewed Jun 24, 2026
Last updated Jun 24, 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
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
None

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:L/PR:L/UI:N/S:U/C:N/I:L/A:N

EPSS score

Weaknesses

Improper Input Validation

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. Learn more on MITRE.

CVE ID

CVE-2026-53541

GHSA ID

GHSA-prj9-97mp-mwh2

Source code

Credits

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