Topic starter
18/08/2026 2:36 pm
TL;DR: A Swift app that builds AppleScript around user-controlled paths can cross a data-code boundary and permit arbitrary command execution when escaping rules do not match the target interpreter, according to Sonar. The case reinforces that native argument passing is safer than string-built scripts, especially where untrusted content can arrive through files, archives, or repositories.
Editorial analysis by NHI Mgmt Group, based on content published by Sonar: “Escape from AppleScript: Even folder names can be user input”.
Key questions
Q: What breaks when shell escaping is used in the wrong interpreter context?
A: Escaping only protects the grammar of the interpreter it was written for, so a string that is safe for the shell can still break out of an outer AppleScript literal.
Q: Why do user-controlled paths become dangerous in launcher utilities?
A: Paths are dangerous when the application treats them as executable text instead of data.
Q: What are the signs that command construction is failing safely?
A: The main warning sign is any feature that concatenates a command string and then relies on manual escaping before execution.
Practitioner guidance
- Ban string-built command launchers Require structured process APIs for any feature that launches terminal commands, editors, or helpers from user-controlled paths.
- Review multi-interpreter code paths Flag any workflow where Swift, AppleScript, shell commands, or similar layers are chained together.
- Treat file paths as untrusted input Test archive extraction, cloned repositories, nested folders, and symlinked directory structures as potential payload carriers.
Bottom line: OpenInTerminal demonstrates that the real failure is not a bad character filter but a broken trust boundary between path data and executable script.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:21 pm
Parser boundary mistakes are a governance problem, not just a coding bug. This case shows what happens when a file path is allowed to cross from data into executable script without preserving argument boundaries. Security teams should treat multi-interpreter workflows as policy-relevant surfaces, because the risk arises from how trust is transferred between components, not from any single line of code. The practical conclusion is that secure runtime design must be part of access and endpoint governance.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should teams use structured execution instead of scripting for process launch?
A: Yes, when user-controlled values can influence the command. Structured execution preserves argument boundaries and avoids the uncertainty of nested escaping across interpreters. For endpoint tools, launchers, and automation helpers, that design is usually safer than sanitising a command string and hoping every parser sees it the same way.
👉 Read our full editorial: AppleScript injection in OpenInTerminal shows why shell escaping fails