# Uploads into executable web directories

Uploaded or extracted files landing in web-served or executable paths, or reaching interpreters like Ghostscript

_Area: Web injection and code execution. Seen in 3 disclosed reports; latest 2026-10-21. Updated 2026-10-24._

## How it works

An upload feature assumes that a file it accepts is inert data. That assumption breaks when the file is stored somewhere the server will later execute or interpret it. Two mechanisms appear in the evidence: (1) the file is written into a web-served directory under an executable extension, so a request to its URL runs it [E2](https://bugbountylibrary.com/r/h1%3A1122791.md); (2) the file is handed to a processor that interprets its contents as a program, regardless of the name it was uploaded under [E3](https://bugbountylibrary.com/r/h1%3A403417.md). A third shape is subtler: the framework sniffs the real format from contents but keeps the attacker-influenced source extension when naming derived files, so a benign-looking image produces an executable derivative [E1](https://bugbountylibrary.com/r/h1%3A3923967.md).

## Where it shows up

- Archive import/extract endpoints (SCORM, courseware, zip import) writing members into web-accessible paths [E2](https://bugbountylibrary.com/r/h1%3A1122791.md)
- Upload handlers that preserve the client-supplied filename or extension
- Image pipelines that shell out to ImageMagick/Ghostscript with default delegates [E3](https://bugbountylibrary.com/r/h1%3A403417.md)
- Media finalize/sideload flows that trust remote `Content-Disposition` filenames or persist unvalidated metadata [E1](https://bugbountylibrary.com/r/h1%3A3923967.md)
- Any code path where format detection and filename/extension selection come from different sources

## How to review

Trace the file from receipt to storage to any later read. The invariant: no attacker-influenced file may end up at a path the web server executes, and no file may reach an interpreter that treats its contents as code. Check: is the destination directory web-served? Is the stored extension attacker-controlled or derived from the source name? Does the processor have delegates/policies disabled for active formats (PS/EPS/PDF/XPS)? Are archive members filtered for executable extensions before extraction? For media flows, confirm the derivative filename is generated server-side and does not inherit the source extension [E1](https://bugbountylibrary.com/r/h1%3A3923967.md).

## Variants seen

- Archive extraction into a web-served courseware directory with executable members surviving [E2](https://bugbountylibrary.com/r/h1%3A1122791.md)
- Image processor delegating to Ghostscript, executing a PostScript payload renamed as an image [E3](https://bugbountylibrary.com/r/h1%3A403417.md)
- Content-sniffed image with source `.php` extension reused for derivatives, plus unvalidated `original_image` metadata [E1](https://bugbountylibrary.com/r/h1%3A3923967.md)

## Impact and severity

All three reached remote code execution, the highest severity. Severity rises when the endpoint needs only a low-privilege account (author role [E1](https://bugbountylibrary.com/r/h1%3A3923967.md), authenticated user [E2](https://bugbountylibrary.com/r/h1%3A1122791.md)) and when the written file is directly reachable by URL. Missing extension filtering and default interpreter policies were the deciding factors.

## Why fixes fail

Renaming an upload to `.jpg` does not stop interpretation when the processor sniffs contents [E3](https://bugbountylibrary.com/r/h1%3A403417.md); blocking one extension does not cover archive members or derived filenames [E1](https://bugbountylibrary.com/r/h1%3A3923967.md)[E2](https://bugbountylibrary.com/r/h1%3A1122791.md). Fixes must address the storage location and the interpreter policy, not just the upload name.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A3923967.md
- E2: https://bugbountylibrary.com/r/h1%3A1122791.md
- E3: https://bugbountylibrary.com/r/h1%3A403417.md