Summary
The CodeArt Google MP3 Audio Player plugin for WordPress contains an unauthenticated path-traversal vulnerability in its download handler. A remote attacker may retrieve sensitive files by supplying a crafted path, potentially exposing database credentials and secret keys and enabling full site compromise.
Affected context
The vulnerability affects WordPress installations using the CodeArt Google MP3 Audio Player plugin through version 1.0.11. It occurs when the plugin's direct_download.php handler accepts attacker-controlled file paths without sufficiently restricting access to the intended audio files. Risk is greater when the web server process can read configuration files such as wp-config.php.
Exploit preconditions
- Attack surface: The plugin's publicly reachable
direct_download.phpendpoint - Required access: No authentication is generally required
- Trigger point: Processing of the
fileparameter - Why exploitation is possible: The handler may resolve traversal sequences as filesystem paths without enforcing an approved directory boundary
Why this happens
The underlying bug is improper neutralization of path elements supplied through a file-download parameter. When user-controlled input is used to construct filesystem paths without canonicalization and boundary enforcement, traversal sequences can escape the intended media directory and access other readable files. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly called path traversal.
Potential impact
- Sensitive WordPress configuration files may be disclosed
- Database credentials and application secret keys could be exposed
- Attackers may gain information useful for authentication or session forgery
- The WordPress site could be compromised through follow-on attacks
- Data confidentiality and site integrity may be affected
General mitigation guidance
Mitigation generally focuses on reducing filesystem access through user-controlled paths and enforcing a strict separation between public media and application configuration.
Common defensive patterns include:
- Resolving requested paths canonically and confirming they remain within an approved directory
- Mapping opaque download identifiers to server-side filenames instead of accepting filesystem paths
- Allowing only expected file types and normalized filenames
- Denying access to configuration, credential, and source files at the web-server layer
- Running the web process with the minimum filesystem permissions required
- Treating download parameters as untrusted input regardless of authentication status
- Rotating exposed credentials and secrets when unauthorized file access is suspected
How teams detect issues like this
Organizations can look for this vulnerability through:
- Static analysis rules that identify user-controlled input reaching filesystem operations
- Code review checks for download handlers that concatenate or resolve raw path parameters
- Tests using traversal variants against every file-serving endpoint
- Web-server logs showing requests to download handlers with encoded or repeated parent-directory segments
- Monitoring for unusual requests targeting configuration files or other non-media resources
- Policy enforcement requiring canonical path checks, allowlisted storage roots, and least-privilege service accounts
Automated security review tools may help identify unsafe file path construction, but findings should be validated against deployment-specific filesystem permissions.
