A2A Samples .NET CLI Agent allowlist bypass enables shell command injection

[N0zoM1z0]

Summary

The samples/dotnet/A2ACliDemo/CLIServer sample upgrades remote A2A TextPart
content into a local shell command. It attempts to protect execution with an
allowlist, but the allowlist only checks the first token returned by
ParseCommand(input).

On Unix-like systems the remaining unvalidated argument string is interpolated
into:

/bin/bash -c "{command} {arguments}"

An attacker can use an allowed first token such as echo and place shell
metacharacters in the argument string. Example:

echo a2a-safe; printf A2A_PWNED_7f4d7c

ParseCommand treats echo as the command, IsCommandAllowed("echo") accepts
it, and /bin/bash -c executes the trailing printf command.

Affected Target

• Repository: a2aproject/a2a-samples
• Commit tested: d536d049451864995df9b5bb0b4f2e2d3cf65274
• Component: samples/dotnet/A2ACliDemo/CLIServer/CLIAgent.cs

Security Impact

If the sample CLI agent is exposed to untrusted A2A clients, a remote client can
execute shell metacharacters after any allowlisted command token. This bypasses
the sample's stated command allowlist boundary and can become remote command
execution in deployments that reuse the sample.

This is a sample issue rather than a core SDK issue, but it is security-relevant
because the sample explicitly demonstrates a bridge from A2A messages to
system-level operations.

The repository README also warns that data received from external agents,
including messages and artifacts, should be treated as untrusted input. This
issue is a concrete example of that boundary being crossed: untrusted A2A
message text is interpreted as a shell command line.

The configured allowlist also includes interpreter and package-manager style
commands such as python, node, npm, and dotnet. Even if shell
metacharacter injection were fixed, these entries should be treated carefully
because they can execute attacker-provided program text or project scripts when
arguments remain remotely controlled.

Root Cause

The code extracts message text from the A2A request:

var userText = GetTextFromMessage(messageSendParams.Message);

It parses only the first whitespace-delimited token as the command:

var parts = ParseCommand(input);
var command = parts.Command;
var arguments = parts.Arguments;

It allowlists only command:

if (!IsCommandAllowed(command)) { ... }

But then passes both command and attacker-controlled arguments through a
shell:

process.StartInfo.Arguments = $"-c \"{command} {arguments}\"";

The guard and sink do not protect the same semantic object.

Steps to reproduce

From the extracted package directory:

cd attachments
bash reproduce.sh

The included PoC is source-anchored and does not require the .NET SDK. It checks
the vulnerable anchors in CLIAgent.cs, replays the sample's parse and allowlist
logic, and executes the resulting benign shell command locally to prove that the
trailing marker command runs.

The script clones the tested a2a-samples commit if no local checkout is
provided. To run against an existing checkout:

cd attachments
A2A_SAMPLES_TARGET_DIR=/path/to/a2a-samples bash reproduce.sh

Expected result:

{
  "verdict": "fail",
  "first_token_allowed": true,
  "marker_observed": true
}

Suggested Fix

Avoid shell interpretation for user-controlled message text. Prefer one of:

• dispatch each allowed command to a fixed handler;
• invoke a fixed executable with an argument array and no shell;
• validate the complete command grammar, including arguments, before execution;
• remove interpreters and package managers such as python, node, npm, and
  dotnet from the default allowlist unless their arguments are separately
  constrained by command-specific parsers;
• remove shell-backed execution from the public sample or mark it as trusted
  local-only.

Attachments

attachments.zip

[chopmob-cloud]

Confirmed against CLIAgent.cs at the cited commit, and the report is precise. ParseCommand splits only on the first space and IsCommandAllowed validates only that first token, so everything after it flows unchecked into the execution string. The sink is the shell invocation itself:

process.StartInfo.FileName = "/bin/bash";
process.StartInfo.Arguments = $"-c \"{command} {arguments}\"";   // and cmd.exe /c on Windows
process.StartInfo.UseShellExecute = false;

Worth calling out that UseShellExecute = false reads like the mitigation but is not one here. It only stops .NET from asking the OS shell to resolve FileName. The code then hands a full command line to /bin/bash -c (or cmd.exe /c) explicitly, so a shell parses the string regardless, and ;, |, &&, $(...), backticks are all live. echo a2a-safe; printf A2A_PWNED runs exactly as reported.

The robust fix is to stop building a shell command line at all, rather than trying to escape or filter one. In .NET the idiom is to exec the allowlisted program directly and pass arguments as a vector:

var psi = new ProcessStartInfo
{
    FileName = command,          // the allowlisted executable, no /bin/bash, no cmd.exe
    UseShellExecute = false,
    RedirectStandardOutput = true,
    RedirectStandardError = true,
};
foreach (var arg in argumentTokens)   // parsed into a list, not one interpolated string
    psi.ArgumentList.Add(arg);

ArgumentList builds the native argv with per-platform quoting and never invokes a shell, so a metacharacter in an argument arrives at the target program as a literal argv entry instead of being interpreted. That removes the whole injection class, and only then does the first-token allowlist actually bound what runs. ArgumentList is available on the sample's net9.0 target. One caveat: on Windows, dropping cmd.exe matters specifically because cmd re-parses metacharacters even when arguments are passed as a list, so the direct-exec form is what closes it on both platforms. This also nudges the allowlist toward real executables rather than shell builtins (a bare echo is a cmd builtin on Windows and not a standalone program), which is a healthy constraint for a security-sensitive sample anyway.

The second point in the report is the one I would keep even after the shell fix: allowlisting interpreters and package managers (python, node, npm, dotnet) still permits arbitrary code once any argument is remotely controlled, since python -c ..., npm run <script>, and friends are code-execution by design. For a sample that advertises the A2A-message-to-system-operation bridge, it is probably worth narrowing the default allowlist to genuinely inert commands and adding an explicit "do not expose this to untrusted clients" note next to it, so the security boundary the sample demonstrates is one that actually holds.