GHSA-xhq6-w3f2-m5w6

Impact

ToolGuard in qwed-open-responses (both the Python and npm packages) does not recognise several executable OpenAI Responses API output item types as tool calls. They are treated as "no tool calls", so a response that asks the application to run a shell command, apply a file patch, or perform a computer-use action is reported as verified=True.

Affected item types:

None of ToolGuard's checks apply to these items: the default blocklist (which includes shell, bash, exec, …), allowed_tools, dangerous-argument patterns, custom validators, and max_calls_per_response.

Who is affected: applications that enable OpenAI's local shell, shell, apply-patch, computer-use or custom (free-form) tools and rely on ToolGuard / ResponseVerifier, VerifiedOpenAI.responses.create(), or OpenResponsesMiddleware to gate execution. A prompt-injected or misbehaving model can then cause a command such as rm -rf / to be executed, even though the application believes QWED has verified the action.

Applications that only use function_call / Chat Completions tool_calls / Anthropic tool_use are not affected by this advisory.

Root cause

Tool-call detection is shape-based. An item is only treated as a tool call if:

• its type starts with tool_call, function_call or tool_use, or contains tool; or
• it carries tool_name, or both name and arguments.

Executable items whose payload is in action, operation, command(s) or input match none of these rules, so they fall through as tool-free content. The streaming middleware uses the same rules to decide whether to verify an item at all, so it yields these items unverified. The result is an implicit allow for unknown or unmodelled executable item types, which contradicts the fail-closed model ("absence of verification is not success").

Patches

Fixed in 0.6.1 (pip and npm). The fix:

• normalizes client-executed action items into tool calls, so the blocklist, allowlist, dangerous-pattern and validator checks apply to them:

  Item type	Checked as tool
  local_shell_call	local_shell (argv also scanned as a joined command line)
  shell_call	shell
  apply_patch_call	apply_patch
  computer_call	computer_use
  custom_tool_call / mcp_approval_request	the item's own name

• adds local_shell, apply_patch and computer_use to the default blocklist (shell was already on it);

• fails closed on unknown *_call / *_request items in protocol positions (output[] of a response object, streamed items and output_item events). Provider-hosted items (web_search_call, file_search_call, code_interpreter_call, image_generation_call, mcp_call) keep their existing behavior;

• rejects action items that also carry another call envelope, or whose tool_name / toolName disagrees with name;

• applies the same rules in the core verifier, ArgumentGuard, the streaming middleware and the npm package.

Breaking change: apps that intentionally run local_shell, apply_patch or computer_use through ToolGuard must construct it with use_default_blocklist=False / { useDefaultBlocklist: false }. This drops the entire default blocklist, so re-add any names that should stay blocked via blocked_tools, and preferably configure an allowed_tools allowlist.

Workarounds

Until you can upgrade:

• In the code that dispatches model output, refuse to execute any Responses item type other than the ones you explicitly support and verify (for example, only function_call).
• Do not enable local_shell, shell, apply_patch, computer_use or custom tools in combination with QWED gating on affected versions.

References

• Reproduced on v0.6.0 (7293d2d) for both the Python and npm packages.