# Wordpress 4.7.2 - Two XSS in Media Upload when file too large.

Oversized upload filenames are interpolated unescaped into the media upload error message, executing XSS in the admin's control panel.

- Payout: hidden
- Severity: high
- Program: WordPress
- Found by: skansing
- Disclosed: 2017-07-17
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/203515
- Library page: https://bugbountylibrary.com/r/h1%3A203515
- Tags: area:web domain:web impact:ato kind:bounty platform:hackerone sev:high tech:wordpress technique:source-review vuln:xss

**Target:** wp-admin media-new.php upload error handler (handlers.min.js / script-loader.php)
**Root cause:** The uploader l10n string `file_exceeds_size_limit` uses `%s` for the filename, and `uploadSizeError()` does `.replace('%s', file.name)` then appends the result to `#media-items` via jQuery without escaping the filename.
**Steps:**
1. Create a ~20MB file named `Dinosaurs secret life<img src=x  onerror=alert(1)>.png`
2. Go to `http://127.0.0.1/wp-admin/media-new.php`
3. Drag-and-drop or select the file via 'Select Files'
4. Size error appears and the onerror payload fires, executing alert(1) in the admin panel
**How found:** Noticed that two 'file too large' cases interpolate the filename into DOM unsanitized; traced `$uploader_l10n` from script-loader.php into handlers.min.js where `uploadSizeError` does `.replace('%s', file.name)` and appends to `#media-items`.
**Exploitation:** Attacker crafts an oversized file with an HTML/JS payload in the filename and gets an admin to upload it (or uploads it themselves in the admin UI); the size-error path interpolates the filename into DOM, executing script in the admin's session.
**Insight:** Client-side l10n error strings that use `%s` placeholders for user-controlled values (filenames) are a recurring XSS sink; check every `.replace('%s', ...)` fed into jQuery `.append()` in uploader/error handlers, and note validation order — the size check fires before file-type validation, so any extension works.

