# WordPress Flash XSS in *flashmediaelement.swf*

Reflected XSS in WordPress's flashmediaelement.swf via GET flashVars bypassing three defenses: invalid URL escapes, ES6 backticks, and Chrome's auto-injected embed id.

- Payout: hidden
- Severity: medium
- Program: Automattic
- Found by: cure53
- Disclosed: 2016-07-10
- Write-up quality: 8/10
- Original: https://hackerone.com/reports/134546
- Library page: https://bugbountylibrary.com/r/h1%3A134546
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:medium tech:wordpress technique:parser-differential technique:source-review vuln:xss

**Target:** flashmediaelement.swf (Flash file in wp-includes/js/mediaelement)
**Root cause:** The SWF's 'GET Killer' compares parsed query-string keys against flashVars keys, but Flash strips invalid URL escapes (e.g. %g) so the parsed key differs from the actual parameter name, defeating the scrub. A blacklist misses ES6 backtick execution, and the ExternalInterface.objectID check is satisfied by Chrome's auto-generated embed id.
**Steps:**
1. Request `https://example.com/wp-includes/js/mediaelement/flashmediaelement.swf?%#jsinitfunctio%gn=alert`1``
2. Flash strips the invalid `%g` escape so the parameter arrives as `jsinitfunction`, while the GET Killer's parsed key still contains `%g` and does not match, so it is not scrubbed
3. The value `alert`1`` uses backticks (not blacklisted parentheses) to invoke alert via ExternalInterface.call
4. Chrome's direct-SWF embed includes `id="plugin"`, satisfying the ExternalInterface.objectID check so the callback fires
**How found:** Team reviewed the SWF's defensive code (GET Killer, illegal-char blacklist, objectID check) and reasoned about Flash's tolerant URL-escape stripping, ES6 template-literal execution, and browser-generated embed markup to bypass each layer.
**Exploitation:** Attacker crafts a URL to the SWF with an obfuscated GET parameter name and a backtick-based JS payload; victim opening the URL in Chrome executes the JS in the WordPress origin.
**Insight:** When a Flash/JS sanitizer compares parsed parameter names against actual ones, exploit parser differentials: Flash strips invalid URL escapes, so `%g` in the parsed key won't match the delivered key. Also check ES6 backticks against blacklists that only ban parentheses, and inspect browser-generated embed markup for auto-injected ids that satisfy objectID checks.

## Proof of concept (copied exactly from the original report)

**PoC URL exploiting flashmediaelement.swf XSS**

```
https://example.com/wp-includes/js/mediaelement/flashmediaelement.swf?%#jsinitfunctio%gn=alert`1`
```