Summary
AG2's SandboxShellTool can allow an attacker-influenced command to include an additional shell statement because its filtering omits newline and carriage-return separators. When the accepted command is passed to sh -c, that statement may run with the privileges of the agent process.
AG2's SandboxShellTool can allow an attacker-influenced command to include an additional shell statement because its filtering omits newline and carriage-return separators. When the accepted command is passed to sh -c, that statement may run with the privileges of the agent process.
Affected context
The issue affects SandboxShellTool configurations that use allowed=[...] or readonly=True and rely on the shell filtering logic in AG2. The filter checks command prefixes and selected shell syntax but does not account for newline or carriage-return separators before the raw command is passed to a shell. With the default LocalEnvironment backend, execution occurs as a host subprocess under the agent process's privileges.
The issue affects SandboxShellTool configurations that use allowed=[...] or readonly=True and rely on the shell filtering logic in AG2. The filter checks command prefixes and selected shell syntax but does not account for newline or carriage-return separators before the raw command is passed to a shell. With the default LocalEnvironment backend, execution occurs as a host subprocess under the agent process's privileges.
Exploit preconditions
- Attack surface: Commands submitted to the AG2 SandboxShellTool.
- Required access: An attacker must be able to influence a command processed by the agent or tool.
- Relevant configuration: The tool uses
allowed=[...]orreadonly=Truefiltering. - Trigger point: The filtered command is passed to
sh -c. - Why exploitation is possible: The filter omits newline and carriage-return separators, allowing an additional statement to pass through the checks.
- Attack surface: Commands submitted to the AG2 SandboxShellTool.
- Required access: An attacker must be able to influence a command processed by the agent or tool.
- Relevant configuration: The tool uses
allowed=[...]orreadonly=Truefiltering. - Trigger point: The filtered command is passed to
sh -c. - Why exploitation is possible: The filter omits newline and carriage-return separators, allowing an additional statement to pass through the checks.
Why this happens
The root cause is incomplete shell-syntax validation. The filtering logic checks for selected operators and command prefixes but fails to account for newline and carriage-return separators. Passing the resulting raw string to a shell can therefore turn input intended to represent an allowed command into multiple statements. This is command injection (CWE-78) enabled by incomplete denylist filtering (CWE-184).
The root cause is incomplete shell-syntax validation. The filtering logic checks for selected operators and command prefixes but fails to account for newline and carriage-return separators. Passing the resulting raw string to a shell can therefore turn input intended to represent an allowed command into multiple statements. This is command injection (CWE-78) enabled by incomplete denylist filtering (CWE-184).
Potential impact
- An additional command may execute as a host subprocess with the agent process's privileges.
- Confidentiality could be affected if the process can access sensitive files or data.
- Integrity could be affected through modification of accessible resources.
- Availability may be affected by disruptive commands.
- An additional command may execute as a host subprocess with the agent process's privileges.
- Confidentiality could be affected if the process can access sensitive files or data.
- Integrity could be affected through modification of accessible resources.
- Availability may be affected by disruptive commands.
General mitigation guidance
Defensive patterns focus on avoiding shell interpretation and reducing trust in agent-controlled command strings. Common approaches include:
- Prefer structured process execution that passes an executable and arguments without invoking a shell.
- Use explicit command and argument allowlists rather than relying on partial shell-syntax filters.
- Treat agent-generated or user-influenced commands as untrusted and validate them against a strict schema.
- Run tools in an isolated environment with least-privilege permissions and limited access to host resources.
- Use secure-by-default configurations that disable arbitrary command execution when it is not required.
Defensive patterns focus on avoiding shell interpretation and reducing trust in agent-controlled command strings. Common approaches include:
- Prefer structured process execution that passes an executable and arguments without invoking a shell.
- Use explicit command and argument allowlists rather than relying on partial shell-syntax filters.
- Treat agent-generated or user-influenced commands as untrusted and validate them against a strict schema.
- Run tools in an isolated environment with least-privilege permissions and limited access to host resources.
- Use secure-by-default configurations that disable arbitrary command execution when it is not required.
How teams detect issues like this
- Use static analysis to identify shell invocation APIs that receive dynamically constructed or agent-influenced strings.
- Review filters and validators for incomplete denylist logic, especially where input is subsequently interpreted by a shell.
- Check whether newline and carriage-return characters are considered at every validation boundary.
- Apply policy checks that prefer structured process invocation and restrict shell execution to approved use cases.
- Automated code review tools may help flag dynamic shell command construction for manual assessment.
- Use static analysis to identify shell invocation APIs that receive dynamically constructed or agent-influenced strings.
- Review filters and validators for incomplete denylist logic, especially where input is subsequently interpreted by a shell.
- Check whether newline and carriage-return characters are considered at every validation boundary.
- Apply policy checks that prefer structured process invocation and restrict shell execution to approved use cases.
- Automated code review tools may help flag dynamic shell command construction for manual assessment.
