Photo Upload Reads Files Off the Production Servers

The Vulnerability

The photo-upload feature handed every uploaded file to ImageMagick, a server-side image-processing library, for conversion. ImageMagick supports a special coder that opens an arbitrary file path on the server and renders its bytes into the output image. By uploading a small vector image that referenced a local file path through that coder, the contents of any file readable by the application user were rendered into the stored photo.

Two factors turned this into a reliable read primitive:

• The output was served publicly. Stored photos were delivered from a public image host with no authentication, so the rendered file contents could be fetched by anyone, with no cookies.
• A signature filter was bypassable. A web filter blocked the obvious sensitive paths, but an equivalent path that normalized to the same file (for example a doubled slash) sailed past the filter while still reading the target.

The processing ran on the production application stack, confirmed by reading the server hostname back through the same channel.

The Attack

The Read Primitive

The core payload was a vector image whose embedded image element pointed at a server file path through the file-reading coder. Saved with an image extension so the endpoint accepted it, the upload caused the library to read the target file and paint its bytes into the result:

<svg xmlns="http://www.w3.org/2000/svg" width="300" height="50">
  <image xlink:href="text:/etc//passwd" x="0" y="0" width="800" height="1000"/>
</svg>

The naive path was blocked by the web filter, but the doubled-slash variant normalized to the same file and was not signatured, so it passed and the read succeeded.

Reading the Results

Each stored photo was served from the public image host, so the rendered file content opened directly in a browser tab or fetched with no credentials. Using the application's own working-directory reference, application-relative files were reachable without knowing the deploy path. Reads demonstrated on production included the system account file, the server hostname, and the full application source and configuration: the dependency manifest (revealing an internal package registry), the database configuration, and the secret-management initializers.

Probing the Internal Network

The same image-processing sink fetched URLs server-side and followed redirects, so an upload could be aimed at internal-only hosts and the cloud instance-metadata service. Out-of-band callbacks confirmed the requests originated from the company's own production cloud addresses. This server-side request capability was blind (no response body returned to the attacker) and is noted as additional impact of the same upload path.

The Impact

An authenticated free-account user could read arbitrary files off production application servers, with the contents returned on a public, unauthenticated image host. Confirmed reads included the system account file, the production hostname, the full application source and configuration, and a hardcoded production third-party integration key and secret recovered as literal strings from the source.

Production source-code and credential disclosure on a live host is a serious exposure on its own and a strong foothold for further attacks. On this legacy stack, a disclosed signing secret would enable session forgery and code execution, though the production signing secret and database password were injected from environment variables and were not recoverable through this channel, so that escalation is documented rather than claimed.

Remediation

• Disable the dangerous coders in the image-processing library policy (the file-reading, URL-fetching, and raw coders), restricting it to a strict allow-list of safe image formats.
• Validate and re-encode uploads through a hardened pipeline rather than passing raw user files to a broad converter.
• Do not rely on a signature filter for path blocking; the bypass shows it is trivially defeated by path normalization.
• Block server-side egress from the processing host to internal addresses and the instance-metadata endpoint.
• Rotate the hardcoded integration credentials and move all secrets out of source into environment-injected configuration.