The application exposes a URL fetcher that attempts to force http URLs, and an upload endpoint that superficially checks MIME and filename. Using file:// and php:// style paths we bypassed the http check (file:///http/../...) to read local files and source code. We discovered an upload endpoint that only checks the filename contains .png/.jpg/.jpeg and that mime_content_type() begins with image/. By embedding PHP inside a PNG and naming the file shell.png.php we uploaded a webshell. The fetcher can read files via file:///http/../..., so we triggered the uploaded shell through the fetcher to achieve remote code execution even though system and common exec functions were disabled.
Visiting the challenge page shows a single input asking for an image URL to fetch.
Screenshot: Fetched image UI.
A normal request like:
GET /?url=http://google.com
works and returns fetched HTML.
file:// and bypassing http checkI tried fetching local files using file:///etc/passwd and received the file contents.
Payload:
?url=file:///etc/passwd
To bypass the server-side check that insists on 'http' being present in the URL, I used:
?url=file:///http/../etc/passwd
stripos($url, 'http') === false is used by the app as a guard; the crafted path contains the literal sequence http while still resolving to the local file due to file:///http/../etc/passwd → /etc/passwd. This returned /etc/passwd contents.
Using the same technique I retrieved application files: