CVE-2021-23174

What it actually does

CVE-2021-23174 is an authenticated persistent cross-site scripting vulnerability in the Download Monitor WordPress plugin versions 4.4.6 and earlier. An administrator-level user can store malicious JavaScript in vulnerable fields, specifically post_title or downloadable_file_version[0]. When another user views the affected Download Monitor content in the WordPress administrative interface or a rendered page that outputs the stored value without proper sanitization or encoding, the script executes in that user’s browser context. Because the CVSS scope is changed, successful exploitation can affect users or browser sessions beyond the vulnerable component itself, enabling session actions, data exposure available to the victim, or unauthorized changes performed through the victim’s browser.

Why it matters to the business

The practical risk is highest where multiple administrators, editors, support staff, agencies, or delegated site operators share WordPress management duties. A malicious or compromised administrator account could plant script code that runs later for other privileged users, potentially leading to account takeover, unauthorized content changes, theft of sensitive administrative data, or further compromise of the WordPress site. Although exploitation requires high privileges and user interaction, the EPSS score is high, indicating notable likelihood of exploitation activity relative to many vulnerabilities. Organizations using Download Monitor on public WordPress sites should treat this as a meaningful post-compromise and insider-risk issue, especially because vulnerable versions have been public for years.

How an attack unfolds

An attacker first obtains administrator-level access to a WordPress site running Download Monitor 4.4.6 or earlier, either through credential theft, password reuse, phishing, exploitation of another plugin, or misuse by an insider. The attacker then creates or edits a Download Monitor item and places JavaScript payloads into the vulnerable post_title or downloadable_file_version[0] fields. The plugin stores the value persistently. When another privileged user later views the affected download entry, file version metadata, listing, or related administrative screen, the browser interprets the injected content as script instead of plain text. The script can perform actions as the victim within WordPress, read page-accessible data, modify plugin or site settings, create additional administrative users if permissions and nonces can be abused or obtained, or redirect the user to credential-harvesting infrastructure. No public KEV listing or ransomware association is currently indicated, but exploitation remains plausible wherever an attacker already has or can obtain high-privilege WordPress access.

How to fix it

Upgrade the Download Monitor WordPress plugin to a version newer than 4.4.6. If an exact fixed version is not available from package metadata, install the latest version from the official WordPress plugin repository or vendor source. After upgrading, review existing Download Monitor entries and file version metadata for suspicious HTML, script tags, event-handler attributes, encoded JavaScript, iframes, or external URLs. If immediate upgrade is not possible, restrict WordPress administrator access to trusted users only, enforce multi-factor authentication, limit access to the wp-admin interface by IP or VPN where feasible, disable the plugin if not business-critical, and prevent untrusted administrators from creating or editing Download Monitor content. Web application firewall rules may reduce obvious script payloads but should not be considered a complete fix for stored XSS.

How to confirm the fix worked

Confirm the installed Download Monitor plugin version is greater than 4.4.6 by checking the WordPress Plugins page, WP-CLI, or the plugin metadata file. With WP-CLI, use commands such as `wp plugin list | grep -i download-monitor` and verify the reported version. Inspect stored Download Monitor posts and associated metadata for payload-like content in titles and downloadable file version fields. Test in a non-production environment by attempting to save benign XSS test strings in the affected fields and confirming they are rejected, sanitized, or displayed as escaped text rather than executed. Review access controls to ensure only necessary personnel have administrator privileges, and verify MFA is enabled for privileged accounts.

Typical attack path

1. Identify a WordPress site using the Download Monitor plugin at version 4.4.6 or earlier.
2. Obtain administrator-level WordPress access through phishing, credential theft, reuse of leaked credentials, another vulnerability, or insider misuse.
3. Create or modify a Download Monitor download entry or file version.
4. Insert a JavaScript payload into the post_title or downloadable_file_version[0] parameter.
5. Wait for another administrator or privileged user to view the affected Download Monitor content or administrative page.
6. Execute JavaScript in the victim’s browser session.
7. Use the victim’s authenticated browser context to steal accessible data, change site content or settings, add persistence, or redirect the victim to attacker-controlled infrastructure.

How to detect it

To determine whether this was already exploited, review WordPress administrative activity, web server access logs, security plugin logs, and database/content exports for evidence of suspicious changes to Download Monitor entries. Focus on POST requests made by administrator accounts to plugin-related edit endpoints, especially requests containing `post_title` or `downloadable_file_version[0]` with HTML or JavaScript-like content. Search stored download titles and file version metadata for `<script>`, event-handler attributes such as `onerror=` or `onload=`, JavaScript URI handlers, iframes, SVG-based payloads, base64-encoded script blocks, or references to unfamiliar external domains. Correlate suspicious content changes with login events, new administrator creation, password changes, plugin/theme editor activity, uploads of PHP files, and unexpected redirects. Browser-executed XSS may leave limited server-side traces, so the most reliable evidence is malicious stored content, anomalous privileged account activity, and subsequent administrative actions performed shortly after a victim viewed the poisoned entry.

• post_title=<script
• post_title=%3Cscript
• downloadable_file_version[0]=<script
• downloadable_file_version%5B0%5D=%3Cscript
• downloadable_file_version[0]
• downloadable_file_version%5B0%5D
• <script
• %3Cscript%3E
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• <iframe
• %3Ciframe
• <svg
• %3Csvg
• document.cookie
• localStorage
• sessionStorage
• eval(
• atob(
• wp-admin/post.php
• wp-admin/post-new.php
• wp-admin/admin-ajax.php
• download-monitor

What your security team should do

• Inventory WordPress sites and identify all installations of the Download Monitor plugin, prioritizing internet-facing sites and sites with multiple administrators.
• Upgrade Download Monitor to the latest available version on all affected WordPress instances running version 4.4.6 or earlier.
• Review Download Monitor content for stored script payloads, suspicious external links, iframes, SVG payloads, encoded JavaScript, and unexpected administrator-created entries.
• Audit WordPress administrator accounts for unauthorized users, stale agency/vendor accounts, weak authentication, or recent privilege changes.
• Enable MFA for all WordPress administrator accounts and remove unnecessary administrator privileges.
• Review web server, WordPress, and security plugin logs for suspicious POST requests to Download Monitor administrative endpoints or unexpected edits to download entries.
• If suspicious payloads are found, treat the site as potentially compromised: preserve logs, rotate administrator passwords, invalidate sessions, inspect for web shells or malicious plugins, and review recent site changes.
• Because the EPSS score is high despite the need for admin privileges, include this vulnerability in routine WordPress plugin patch SLAs rather than deferring it as low priority.