Users upload profile images; the server stores them in the web root and serves them back. What's the risk?

"They're just profile images" is the assumption that turns an upload form into a remote shell. The moment users can write a file into a directory the web server will serve and execute, the upload feature becomes a code-delivery channel.

Why this is dangerous

If the server runs PHP, JSP, ASPX, etc., an attacker uploads avatar.php instead of a PNG and then requests it — the server executes it, granting remote code execution (RCE) and a foothold on the host. Even without a scripting engine, an uploaded HTML or SVG file served from your origin runs JavaScript in your users' browsers, giving stored XSS and session theft. Attackers bypass naive checks with double extensions (shell.php.png), null bytes, fake Content-Type headers, or polyglot files whose magic bytes look like an image but whose tail is live code.

The correct fix

Layer the defenses:

• Validate real content, not just the extension or client-supplied Content-Type — check magic bytes and, ideally, re-encode the image so any embedded payload is stripped.
• Store uploads outside the web root or on object storage / a separate origin that cannot execute code and serves with a benign Content-Type plus Content-Disposition: attachment.
• Randomize filenames so attackers can't predict or overwrite paths, and strip the original name.
• Constrain size and type, and run AV/scanning where appropriate.

Why the distractors are wrong

"No risk — they're just images" is exactly the blind spot that ships the vulnerability; the file's claimed type is attacker-controlled. "Slower page loads" and "excessive disk usage" are real operational concerns, but they're about capacity, not compromise — an interviewer asking "what's the risk?" wants you to name RCE / stored XSS and the storage and validation controls that prevent an uploaded file from ever being executed or interpreted as markup.