Unquoted variables are expanded and then split on whitespace or on characters defined by IFS, which can change how commands interpret arguments. That means a value that looks harmless in source code can become multiple tokens at runtime. Security teams should treat unquoted expansion as a reliability and security issue, especially in automation and privileged scripts.
Why This Matters for Security Teams
Unquoted shell expansion is not just a scripting style issue. It changes how Bash tokenises data at runtime, which can turn a single variable into multiple arguments or alter command behaviour in ways the author did not intend. In automation, backup jobs, admin scripts, and deployment tooling, that can create misconfiguration, data loss, or unintended privilege use. The risk is higher when scripts process filenames, user input, environment values, or secrets that may contain spaces, wildcard characters, or leading dashes.
For security teams, the key point is that this failure mode often bypasses code review intuition. A line that looks correct in source can behave differently when it meets real operational data. That is why the issue belongs in secure coding guidance, not just shell hygiene. It also aligns with the broader control logic in the NIST Cybersecurity Framework 2.0, especially around protecting system integrity and reducing preventable operational errors.
In practice, many security teams encounter this only after a maintenance script has already misprocessed files, passed the wrong arguments, or executed an unsafe command path.
How It Works in Practice
Bash expands variables before it decides where one argument ends and the next begins. If a variable is unquoted, word splitting can occur on spaces, tabs, and newlines, and pathname expansion may also apply if the content matches glob patterns. That means a value such as
Report Q4
can become two arguments, while a value containing
*
may expand into matching files in the current directory. In privileged scripts, that can produce destructive outcomes.
The safest pattern is to quote every expansion unless there is a deliberate reason not to. Developers should also treat arrays differently from scalar strings, because arrays preserve intended argument boundaries. When validating input, the control objective is not to make shell data “safe” in the abstract, but to ensure each argument is passed exactly once and only where intended. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports disciplined configuration management and least-privilege operational practices that reduce the impact of scripting mistakes.
- Quote variable expansions:
“$var”
instead of
$var
.
- Use arrays when passing multiple arguments to commands.
- Avoid parsing command output with shell word splitting.
- Sanitise or reject values that begin with
–
when they could be read as options.
- Set strict shell options only with full understanding of their side effects.
Current best practice also recommends testing scripts with unusual filenames, empty values, embedded newlines, and leading wildcard characters because those are the cases that reveal unsafe assumptions. These controls tend to break down in legacy automation that mixes shell parsing with ad hoc text processing because the script depends on implicit token boundaries rather than explicit argument handling.
Common Variations and Edge Cases
Tighter quoting often increases script complexity and can make quick one-line commands feel less convenient, so organisations need to balance safety against maintainability. That tradeoff is usually worth it in anything that runs unattended, handles production data, or operates with elevated privileges.
There is no universal standard for every shell edge case, but current guidance is consistent on the main principle: preserve argument boundaries explicitly. A common exception is intentional word splitting, which should be rare and documented. Another edge case is filenames that contain newlines or leading hyphens; those can still confuse weakly written loops even when the script appears to quote most variables. In security-sensitive environments, the right pattern is to use defensive shell constructs and treat external data as untrusted until it is safely represented.
This also matters in CI/CD, cron jobs, and admin scripts that call other tools. A mistake at the shell layer can cascade into package managers, cloud CLIs, or identity administration commands. For teams aligning operational hygiene to NIST Cybersecurity Framework 2.0, the practical goal is to reduce human-error-driven control failures before they become incidents.
Where Bash is used in privileged automation, the safest assumption is that any unquoted expansion is a defect until proven otherwise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Secure coding and controlled change reduce avoidable shell parsing errors. |
| NIST SP 800-53 Rev 5 | SI-10 | Input validation is directly relevant to unsafe shell expansion of external data. |
Standardise quoting and review shell scripts as controlled operational changes.
