CVE-2024-4439

What it actually does

This vulnerability is a stored cross-site scripting flaw in WordPress Core’s Avatar block rendering. WordPress insufficiently escapes a user display name before outputting it in pages that render avatars, allowing attacker-controlled HTML or JavaScript to be stored and later executed in another visitor’s browser. Exploitation can occur through authenticated display-name manipulation by contributor-level users and above, and in some configurations through unauthenticated comment author data when a page includes the comment block and displays the comment author’s avatar. Successful exploitation runs script in the security context of the affected WordPress site and can enable session riding, content manipulation, credential phishing, nonce theft where exposed to the page, or unauthorized actions as a privileged viewer.

Why it matters to the business

An attacker can turn normal site content or comments into a delivery point for malicious browser code. If an administrator or editor views an affected page, the attacker may be able to manipulate site settings, create or alter content, inject redirects, or stage phishing from a trusted domain. The risk is elevated because exploitation is weaponized, the EPSS score is high, and WordPress is widely deployed; even without being listed in CISA KEV, exposed sites should treat this as a high-priority remediation item.

How an attack unfolds

An attacker identifies a WordPress site running a vulnerable Core version and determines whether avatars are rendered through the Avatar block or through comment blocks that show commenter avatars. In the authenticated path, the attacker obtains or uses a low-privileged contributor-level account, changes the account display name to include a crafted JavaScript payload, and causes that display name to be rendered in an Avatar block. In the unauthenticated path, if comments are enabled and the vulnerable comment/avatar rendering path is present, the attacker submits a comment using a crafted author name or related identity field that is later displayed with an avatar. The payload is stored by WordPress and executes when another user visits the affected page. If the victim is a privileged user, the script can attempt to perform same-site actions, inject additional malicious content, redirect visitors, capture page-accessible tokens, or create persistence through administrative changes available to the victim’s browser session.

How to fix it

Upgrade WordPress Core to a fixed release immediately. Sites running WordPress 6.5.2 or earlier should upgrade to WordPress 6.5.3 or later, preferably the latest currently supported WordPress release. If immediate patching is not possible, reduce exposure by disabling or moderating comments, removing vulnerable Avatar/comment block usage from public pages, restricting contributor and author account creation, reviewing existing contributor display names and comment author names for markup, and applying a web application firewall rule that blocks script-like input in display-name and comment-submission fields. These mitigations reduce risk but should not be treated as a substitute for upgrading Core.

How to confirm the fix worked

Confirm the installed WordPress Core version is 6.5.3 or later, or a maintained branch that contains the security fix. Review pages and templates that use Avatar blocks or comment blocks with avatars and verify that display names and comment author names are rendered as text rather than interpreted as HTML. In a non-production test environment, attempt to save a benign encoded XSS test string in a display name or comment author field and confirm it is escaped in the rendered page. Verify auto-updates or patch-management records show the WordPress Core update completed successfully, and clear page, object, and CDN caches so older vulnerable rendered content is not served.

Typical attack path

1. Fingerprint the target as WordPress and identify a vulnerable Core version at or below 6.5.2.
2. Find pages that render Avatar blocks or comment blocks with commenter avatars enabled.
3. Use a contributor-level account to set a malicious display name, or submit a crafted comment where unauthenticated comments are accepted and rendered with avatars.
4. Wait for the malicious display name or comment author identity to be rendered on a public or administrative page.
5. Trigger JavaScript execution when an editor, administrator, or other visitor opens the affected page.
6. Use the victim’s browser session to perform actions available to that user, such as altering content, injecting redirects, staging phishing, or attempting administrative changes.

How to detect it

Investigate whether suspicious script-like content was submitted to user profile, account-editing, registration, or comment endpoints and later viewed by privileged users. Review web server access logs, WordPress application logs if enabled, WAF events, authentication logs, administrative audit logs, and backup or content-change records. Look for POST requests to comment submission and profile/user editing paths containing encoded HTML, JavaScript event handlers, script tags, SVG payloads, iframe tags, or javascript: URLs. Correlate suspicious submissions with subsequent administrator or editor page views of posts, pages, comments, or block editor screens that render avatars. Examine recent changes to site content, widgets, templates, plugin/theme files, administrator users, redirects, and site settings after those views. Also inspect caches and generated HTML for persisted payloads because the malicious script may continue executing from cached pages even after the original input is changed.

• /wp-comments-post.php
• /wp-admin/profile.php
• /wp-admin/user-edit.php
• /wp-login.php?action=register
• <!-- wp:avatar
• core/avatar
• %3Cscript
• <script
• </script>
• %3C%2Fscript%3E
• onerror=
• onload=
• onclick=
• onmouseover=
• javascript:
• javascript%3A
• <svg
• %3Csvg
• <iframe
• %3Ciframe
• document.cookie
• document.location
• window.location
• fetch(
• XMLHttpRequest
• eval(
• atob(
• String.fromCharCode
• <img src=x onerror=

What your security team should do

• Patch WordPress Core to the latest supported version immediately, prioritizing internet-facing sites and sites that allow comments or contributor-level users.
• Search for stored XSS payloads in user profile display names, comment author metadata, pages, posts, reusable blocks, and cached rendered content.
• Temporarily require moderation for all comments and restrict new contributor/author accounts until patching and review are complete.
• Review recent administrative activity after suspicious page views, especially content edits, plugin/theme changes, user creation, redirect changes, and settings modifications.
• Add WAF and SIEM detections for script-like input submitted to profile, user-edit, registration, and comment endpoints.
• Purge application, page, CDN, and reverse-proxy caches after remediation to remove any previously rendered malicious content.
• Because public exploit activity is weaponized and EPSS is high, handle confirmed exposure as an incident if suspicious payloads or privileged-user page views are found.