View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007938 | OXID eShop (all versions) | 4.04. Security | public | 2026-04-30 08:55 | 2026-05-27 10:01 |
| Reporter | michael_keiluweit | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 7.5.0 | ||||
| Fixed in Version | 7.4.1 | ||||
| Summary | 0007938: Insufficient filename validation in media-library upload (defense-in-depth) | ||||
| Description | The validator chain executed during media-library file upload performs only minimal checks on the filename submitted by the client (non-empty, does not start with a dot, allowed extension). Filenames that carry path-related metadata are not rejected. The downstream code uses a path-joining helper that interprets such metadata when assembling the storage location, and the filesystem layer auto-creates intermediate directories. In the current production runtime stack the attack is neutralised by a sanitisation step performed outside the application code. No successful escape from the media folder was reproduced in the standard environment. However, the application itself provides no defense. The protection is provided incidentally by an external layer that the application neither knows nor controls. Expected The application's filename validator rejects filenames containing path metadata or empty-segment patterns and aborts the upload with a validation failure, regardless of any sanitisation performed by lower layers. Actual The application's validator accepts such filenames. The final storage location is determined by an external sanitisation step that is not part of the application code. Impact - Today: no observable impact in the standard runtime stack. - Latent: any change to the upload pipeline that bypasses the runtime-level sanitisation. Modern HTTP-foundation components, GraphQL upload handlers, alternative process models, an upstream proxy with its own multipart pre-processing turns this into an arbitrary file-write inside the shop tree. In combination with content-type issues already on file (see related ticket), this becomes a persistent attack on the shop origin. | ||||
| Steps To Reproduce | 1. Log in to the admin backend with a user that has upload rights. 2. Open the Media Library. 3. Upload a file whose filename, as transmitted in the multipart body, contains characters that would normally be interpreted as path metadata. (The filename on the local disk is irrelevant; only the value submitted in the multipart envelope matters.) 4. Observe the response of the upload endpoint and the location where the file is stored on disk. In the standard environment the file ends up inside the regular media folder; the validator chain, however, did not reject the request. The cleanup happened below the application layer. | ||||
| Tags | No tags attached. | ||||
| Theme | Not defined | ||||
| Browser | Not defined | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
