Command injection testing, proven by execution
OS command injection is when user input reaches a system shell and gets executed as a command — the most direct form of remote code execution there is. Sintropyc tests every input that could reach a system call and proves each finding with a controlled execution oracle, never a guess from an error message.
Why command injection is the worst-case bug
If an attacker can run one shell command, they can usually run all of them — read and exfiltrate data, pivot into your network, install persistence, take the host. It sits at the top of severity for a reason: it isn't access to data, it's access to the machine.
Where it comes from
- Calls that shell out with user input — image and video processing, PDF and document conversion, archive tools,
pingand network utilities - Filenames, URLs and metadata passed to command-line tools (ffmpeg, imagemagick, git, curl)
- Unsafe use of
system(),exec(), backticks, orchild_processwith a shell - Argument injection — sneaking extra flags into an otherwise 'safe' command
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
For command injection, Sintropyc injects shell-metacharacter payloads into every input that could reach a system call and confirms execution with a safe oracle — a controlled time delay or an out-of-band callback the server makes — before reporting. Proof is the executed effect (a benign, non-destructive marker), never rm, downloads or anything that touches your data.
Sintropyc proves execution with the smallest safe signal — a sleep, an echo, a DNS / HTTP callback. It never runs destructive commands or pulls binaries onto your host. Escalation only with your explicit go-ahead.
What you get
- Every input that can reach a system command tested, including argument injection
- Each finding proven by a real execution oracle (timing or out-of-band), not an error
- The fix (no shell, pass args as an array, strict allow-lists) per finding
- A retest after you ship it
Common questions
Do you actually run commands on our server?
Only benign, controlled ones that prove execution — a delay, an echo, a callback. Never destructive commands, never binary downloads. Any real post-exploitation needs your explicit sign-off.
What if the command's output isn't shown (blind)?
Blind command injection is confirmed the same way as blind SSRF or SQLi — a controlled time delay or an out-of-band callback proves the command ran even with no visible output.
Is this the same as SSTI?
Related but distinct: SSTI abuses a template engine (often reaching RCE); command injection reaches the OS shell directly. Both are top-severity and both are in scope.