CVE-2013-1464: XSS in the WordPress Audio Player plugin's SWF
CVE-2013-1464 affected the Audio Player plugin for WordPress, a once-common way to embed an mp3 player on a page. The vulnerability lived not in the plugin's PHP code but in the Flash (SWF) file it shipped to render the player in the browser.
The vulnerability class
Flash movies of this era commonly read configuration values, known as flashvars, directly from the URL that loaded them, then used those values inside ActionScript without validating or encoding them. When a flashvar value ends up inside a function that evaluates or displays it unescaped, an attacker can craft a URL where that parameter contains script-triggering syntax, and have it execute in the context of the page embedding the SWF. This is the same broad category as a reflected cross-site scripting flaw in a PHP page, just carried through a different runtime: the browser trusts the SWF's embedding page, and the SWF trusts its own flashvars.
In this specific plugin, a parameter identifying which player instance to load was passed straight into the SWF without sanitisation, so a crafted link to the player file, with a malicious value for that parameter, could break out of the expected value and run attacker-supplied script in the visitor's browser session on that WordPress site.
Why this mattered at the time
Flash-based plugins were extremely common in the WordPress ecosystem through the early 2010s, and most site owners never thought of a bundled SWF asset as something that needed its own patching discipline, separate from the plugin's PHP files. A single vulnerable SWF, reused across thousands of installs, meant one flaw affected every site running an unpatched copy of the plugin, and the attack required nothing more than getting a victim to click a link.
The fix
The vendor addressed the issue by validating and properly encoding the flashvar before it was used inside the SWF, closing off the injection point rather than trying to filter specific payload patterns. The fixed version was released within about a week of the vendor being notified.
What this means today
SWF-based WordPress plugins have almost entirely disappeared, since modern browsers no longer run Flash content at all, which removes this entire vulnerability class by default rather than by patch. The lasting lesson is broader: any component that reads untrusted input from a URL and renders it, whatever the runtime, needs to treat that input as hostile and encode it before display, not just the PHP layer most WordPress security advice focuses on.
Key takeaways
- CVE-2013-1464 was a reflected XSS carried through a flashvar in a bundled SWF, not the plugin's PHP code
- Flash content that echoes URL-supplied parameters without encoding is as vulnerable as PHP that does the same
- A single shared SWF asset meant one flaw affected every site running the unpatched plugin
- The vendor fix validated and encoded the flashvar before use
- The vulnerability class itself disappeared once browsers stopped running Flash, but the underlying lesson about encoding untrusted input still applies
This note has been rewritten and checked for this edition; it is not a copy of the original post.