How I Accidentally Discovered an Undocumented Behavior in “Web for Pentester 1”
Most security labs are built around predictable, well-documented vulnerabilities. But every once in a while, during experimentation, you try something that should not work, yet it works perfectly. This is the story of how a simple challenge in Web for Pentester 1 unexpectedly turned into a fully automated command-injection mass mailer, and how I discovered a behavior that was never documented in the exercise.
The Setup
I was working on the Command Injection challenge in Web for Pentester 1.
The premise is simple: exploit a parameter that is executed by the server as part of a shell command.
The vulnerable endpoint looked like this:
example1.php?ip=<input>
In the normal expected solution, the attacker injects something like:
127.0.0.1; cat /etc/passwd
The challenge is meant to demonstrate basic command injection and nothing more.
But I wanted to experiment with something different.
The Idea: Turning the Injection Into a Mass Mailer
To make the challenge more interesting, I decided to use the injection point to send emails. I wrote a small Python script that loops through an email list and injects a full shell command into the vulnerable parameter.
The base idea was:
URL: http://192.168.56.103/commandexec/example1.php?ip=127.0.0.1; echo “This is the body” | mail -s “Subject” email@example.com && echo “Mail sent” || echo “Mail failed”
I then automated the process using Python to build and send each injected request.
Unexpected Result: Everything Worked
To my surprise, every single request worked flawlessly.
The server executed the pipeline exactly as I injected it:
It ran the echo command.
It piped the body into the mail command.
It sent the email.
It evaluated the success and failure operators.
It returned clean responses.
In other words, the injection point behaved like a full shell terminal.
I had unintentionally turned the exercise into a functioning remote-controlled mass mailer.
This was never mentioned or suggested anywhere in the challenge description.
The “Undocumented Vulnerability”
After analyzing what was happening, I noticed several behaviors that were not documented in the official challenge:
The challenge never mentions that shell pipelines work.
It never mentions that operators such as && and || are accepted.
It never mentions that complex multi-part commands execute successfully.
It does not explain what shell is running behind the scenes.
There is no length restriction or sanitization on the input.
The official goal was to perform a simple command injection.
But the real backend allowed far more powerful exploitation.
In other words, the training environment unintentionally exposed a deeper, more flexible vulnerability than expected.
Why This Matters
Even though this took place in a controlled, educational environment, it highlights an important reality in cybersecurity.
Developers often assume that only simple commands will execute when using functions like system(), exec(), shell_exec(), popen(), or backtick execution. But unless the input is sanitized, the backend will usually process full shell syntax, including redirection, pipes, logic operators, and chained commands.
This is the kind of gap that leads to severe real-world compromises.
A developer might think they are allowing harmless input, while the attacker is actually gaining full shell execution.
This lab unintentionally simulated that exact scenario.
Conclusion
What began as a small experiment ended up revealing:
an undocumented behavior,
a full multi-command injection capability,
a working mass mailer built from a simple parameter,
and a valuable lesson about the unpredictability of shell-based execution.
This experience is a reminder that in penetration testing, unexpected behavior is often the most educational. You never know when a system will go beyond what the designer intended, and those moments provide the clearest view of how real vulnerabilities behave.