hunt-command-injection

Validates command injection boundaries using harmless observable markers on authorized targets.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-command-injection-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-command-injection
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-command-injection
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-command-injection-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a web application passes user input into system commands, job runners, converters, or diagnostic features, testers need a disciplined way to confirm whether a shell parsing boundary actually exists without executing real commands, triggering callbacks, or causing side effects. ## Core Features & Use Cases - Evidence-Gated Validation: Confirms injection boundaries only through single-variable probes with harmless markers such as controlled DNS records, task name echoes, or fixed output filenames. - Strict Engagement Gates: Requires authorization, locked scope, and an established host/identity baseline before any probe, and treats WAF blocks, captchas, and timeouts as inconclusive. - Routing and Escalation Control: Routes confirmed execution boundaries to RCE and chain-review workflows, path-like inputs to LFI testing, and template-like inputs to SSTI testing. - Use Case: During an authorized assessment of a ping/dns diagnostic endpoint, use this Skill to verify whether a separator character causes unintended extra parsing, proven only by a controlled DNS marker, before escalating. ## Quick Start Ask the agent to run the command injection specialist route against the authorized diagnostic endpoint and verify the parsing boundary using only harmless observable markers.

Frequently Asked Questions about hunt-command-injection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for command injection without executing commands?

Use harmless observable markers provided by the application itself, such as controlled DNS resolution records, task name echoes, or fixed output filenames. A single-variable probe that triggers unexpected parsing visible in these markers confirms the boundary without running any system command.

What input signals indicate possible command injection?

Signals include command-like input fields, diagnostic actions, DNS lookup features, archive converters, git wrappers, job runners, shell error messages, and process execution boundaries. Each signal must be confirmed with real request or source code evidence before probing.

When should command injection testing stop immediately?

Stop when validation would require executing system commands, writing files, establishing callbacks, reading environment variables, or touching internal networks or shared workers. Out-of-scope targets, third parties, and irreversible side effects also trigger an immediate stop.

Why is a shell error message not proof of command injection?

Shell-like error text, client-side encoding differences, WAF interceptions, and frontend string concatenation are all false positives. Valid proof requires a reproducible single-variable input causing unintended extra parsing visible in server-side task parameters, security logs, or controlled DNS markers.

Can library or API calls be assumed to be command injection?

No. Server-side calls to libraries or APIs cannot be assumed to involve shell interpretation based on feature names alone. You must distinguish shell interpretation from library invocation through request or source code evidence before claiming an injection boundary.