fix(helm): escape all user-supplied TOML string values with toJson

[snese]

What problem does this solve?

The configmap template renders user-supplied string values with raw interpolation:

{{ $k }} = "{{ $v }}"

If a value contains double quotes or backslashes, the rendered TOML is malformed. For example, MY_VAR: 'say "hello"' produces:

env = { MY_VAR = "say "hello"" }

This breaks TOML parsing at runtime. A crafted value could also inject arbitrary TOML keys.

The same unsafe pattern exists in 8 fields across the template: env values, command, working_dir, allow_bot_messages (Discord/Slack), allow_user_messages (Slack), and STT model/base_url.

Related: openabdev#425 (Helm chart analysis report)

Credit

This issue was originally identified and fixed by @thekkagent in openabdev/openab#380 as part of a larger Helm chart extensibility PR. This PR extracts the TOML escaping fix as a standalone security patch, and extends it to cover all remaining string fields in the template.

Proposed Solution

Replace all "{{ $v }}" patterns with {{ $v | toJson }}.

toJson outputs a valid JSON string (with surrounding quotes and proper escaping). TOML basic string syntax is compatible with JSON strings, so the output is valid TOML.

Input value	Before (broken)	After (correct)
hello	"hello"	"hello"
say "hi"	"say "hi"" ❌	"say \"hi\"" ✅
path\to\file	"path\to\file" ❌	"path\\to\\file" ✅

Fields changed

Field	Risk level	Notes
env values	High — arbitrary user input	Primary fix target
command	Low — CLI binary path	Defense in depth
working_dir	Low — file path	Defense in depth
allow_bot_messages (Discord)	Low — has enum validation	Defense in depth
allow_bot_messages (Slack)	Low — has enum validation	Defense in depth
allow_user_messages (Slack)	Low — has enum validation	Defense in depth
model (STT)	Low — has default value	Defense in depth
base_url (STT)	Low — has default value	Defense in depth

Fields NOT changed (no user input)

Field	Reason
bot_token, app_token, api_key	Use env var placeholders (${...}), not user values
allowed_channels, allowed_users, trusted_bot_ids	Already use toJson
args	Already uses toJson

Why this approach?

toJson is already used elsewhere in this template (for args, allowed_channels, etc.), so this is consistent with the existing escaping strategy. It produces output identical to the original for values without special characters, making it fully backward compatible.

Alternatives Considered

1. Fix only env values — rejected

The env field has the highest risk since it accepts arbitrary user input. However, applying the same fix to all string fields is trivial (same one-line pattern) and eliminates the entire vulnerability class from the template. Leaving some fields unfixed would be inconsistent.

2. Use Helm quote function — rejected

quote wraps a value in double quotes but does not escape internal quotes or backslashes. It would not fix the injection.

3. Use TOML literal strings ('...') — rejected

TOML literal strings don't process escape sequences, but they also can't contain single quotes. This would trade one injection vector for another.

Validation

• helm lint charts/openab — passed (0 failures)
• Default values render identically to main (no behavioral change)
• Special characters (double quotes, backslashes) render correctly escaped TOML
• All affected fields tested: env, command, working_dir, allow_bot_messages, allow_user_messages, model, base_url

# Test env with special characters
helm template test charts/openab \
  --set agents.kiro.discord.botToken="test" \
  --set-string 'agents.kiro.discord.allowedChannels[0]=123456789' \
  --set 'agents.kiro.env.NORMAL=hello' \
  --set 'agents.kiro.env.QUOTES=say "hi"' \
  --set 'agents.kiro.env.BACKSLASH=path\\to\\file' \
  -s templates/configmap.yaml

Output:

env = { BACKSLASH = "path\\to\\file", NORMAL = "hello", QUOTES = "say \"hi\"" }

# Test all other fields with features enabled
helm template test charts/openab \
  --set agents.kiro.discord.botToken="test" \
  --set-string 'agents.kiro.discord.allowedChannels[0]=123456789' \
  --set agents.kiro.discord.allowBotMessages="mentions" \
  --set agents.kiro.slack.enabled=true \
  --set agents.kiro.slack.botToken="xoxb-test" \
  --set agents.kiro.slack.appToken="xapp-test" \
  --set agents.kiro.slack.allowBotMessages="all" \
  --set agents.kiro.slack.allowUserMessages="involved" \
  --set agents.kiro.stt.enabled=true \
  --set agents.kiro.stt.apiKey="sk-test" \
  -s templates/configmap.yaml

All fields render correctly with proper quoting.

Scope

One file changed, 8 lines modified. No new features, no new values fields, no template logic changes. Pure security fix.

[amazon-q-developer]

Summary

This PR correctly fixes a TOML injection vulnerability in the env field by using toJson for proper escaping. The fix prevents malformed TOML when environment variable values contain quotes or backslashes.

Critical Security Issues Found

While reviewing this security fix, I identified identical TOML injection vulnerabilities in other user-supplied string fields throughout the same template:

• command (line 81)
• allow_bot_messages for Discord (line 32) and Slack (line 67)
• allow_user_messages for Slack (line 76)
• model (line 103)
• base_url (line 104)

These fields use the same unsafe pattern "{{ $value }}" that this PR fixes for env. They are vulnerable to the same attack: user-supplied values containing quotes or backslashes will produce malformed TOML and enable injection attacks.

Recommendation

The current fix for env is correct and should be merged, but a follow-up PR should apply the same toJson escaping to all other user-supplied string fields to comprehensively address this vulnerability class across the entire template.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.

[snese]

/q review

[amazon-q-developer]

This PR correctly addresses a TOML injection security vulnerability by replacing raw string interpolation with the toJson filter across all affected fields. The implementation properly escapes special characters (quotes, backslashes) in user-supplied values, preventing malformed TOML and potential injection attacks. The changes are consistent, well-tested, and backward compatible. No blocking issues identified.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.