WordPress 6.9.10 Security Release: Stored XSS in Comments Admin and WP_Http DoS — Fedora 43 Patching and Detection Guide

The WordPress security team has shipped version 6.9.10, and Fedora has pushed the corresponding package update to Fedora 43 under advisory 2026-e0ebe50146. This is not a routine maintenance release — it fixes two distinct security defects that map directly to real attacker workflows:

1. A stored cross-site scripting (XSS) vulnerability in the Comments administration page, exploitable through pending comments, reported by Thomas Chauchefoin at Trail of Bits.
2. A denial-of-service condition in the WP_Http::make_absolute_url() method, reported by Anthropic.

The stored XSS is the higher-stakes issue. A flaw that fires in the administrative comments queue means the victim is not a casual site visitor — it is the moderator, editor, or administrator reviewing pending comments. That is precisely the account class an attacker wants to compromise, because session theft or action forgery against a wp-admin session is a direct path to full site takeover (theme/plugin file edits, rogue admin creation, webshell upload). The WP_Http DoS is a lower-severity but broadly reachable code path: WP_Http underpins outbound HTTP for core, plugins, and themes — update checks, API integrations, webhook delivery, oEmbed, pingbacks. Any flaw in URL canonicalization that can be triggered with attacker-influenced input risks site availability.

If you operate WordPress on Fedora 43 (or any distribution packaging WordPress 6.9.x), treat this as a priority patching event, especially for sites that allow public comment submission.

Technical Analysis

Affected Products and Versions

• WordPress core versions prior to 6.9.10 on the 6.9 branch (sites on older branches should consult the corresponding backported security release from wordpress.org).
• Fedora 43 wordpress package — fixed via Fedora update 2026-e0ebe50146.
• Any deployment where wp-admin/edit-comments.php (the Comments administration screen) is reachable by privileged users and untrusted parties can submit comments that land in the moderation queue. This includes sites using native WordPress comments with moderation enabled — the default configuration for most content sites.

Vulnerability 1: Stored XSS via Pending Comments (Comments Administration Page)

How it works (defender's view): WordPress sites with comment moderation enabled place submitted comments into a pending queue. A moderator later opens wp-admin → Comments (/wp-admin/edit-comments.php) to approve, spam, or trash them. In vulnerable versions, insufficient output encoding/sanitization of a comment-derived field rendered on that page allows attacker-controlled markup to execute JavaScript in the moderator's browser session.

Attack chain:

1. Attacker submits a comment containing a crafted payload through the public comment form (/wp-comments-post.php). No authentication is required on sites with open commenting.
2. The payload is stored in the WordPress database (wp_comments table) and sits dormant in the pending queue.
3. A moderator or administrator loads the Comments administration page. The unencoded field is rendered, and the payload executes in the context of the authenticated wp-admin session.
4. From there, classic post-XSS actions apply: nonce theft, forged admin actions via the victim's session, creation of a rogue administrator account, or injection of a PHP backdoor through the theme editor — all with the moderator's privileges.

Exploitation requirements: the target site must accept comments (or an attacker must otherwise be able to inject content into a field rendered on the comments admin screen), and a privileged user must eventually view the queue. On busy sites with active moderation, that second condition is nearly guaranteed — which is exactly why stored XSS in admin surfaces is a favorite of both opportunistic botnets and targeted intrusions.

Vulnerability 2: DoS in WP_Http::make_absolute_url()

WP_Http::make_absolute_url() is responsible for converting relative URLs to absolute ones — a routine operation performed when WordPress core or plugins process redirects, feed content, oEmbed responses, or remote API payloads. A defect in how the method parses or canonicalizes attacker-influenced URLs can be abused to cause excessive resource consumption or a crash condition, degrading site availability.

The practical exposure here depends on which site features pass untrusted input through WP_Http. Common vectors on real-world sites include pingback/trackback processing, oEmbed of attacker-supplied URLs, RSS/feed consumption plugins, and any plugin that fetches remote content based on user input. If any of these paths are reachable by unauthenticated users, the DoS is remotely triggerable without credentials.

Exploitation Status

As of this writing, there is no confirmed public proof-of-concept, no reported in-the-wild exploitation, and no CISA KEV listing for either issue. The vulnerabilities were responsibly disclosed (Trail of Bits and Anthropic, respectively) and patched in a coordinated release. Do not let that lull you into a slow patch cycle: WordPress security releases are reverse-engineered within hours of publication, and stored XSS against admin panels is one of the most reliably weaponized bug classes in the CMS ecosystem. Patch diffs are public the moment the release ships.

Detection & Response

This is a technical threat, and the highest-value detection work targets the delivery mechanism: malicious comment submissions and subsequent suspicious administrative behavior. The rules below focus on the comment-submission attack surface (wp-comments-post.php) and post-exploitation signals — not on generic XSS regexes that will drown your queue in false positives.

SIGMA Rules

The first rule looks for script-bearing comment submissions in web server access logs — a pre-compromise indicator that lets you find and purge malicious pending comments before a moderator opens the queue. The second catches a high-confidence post-exploitation behavior: a rogue admin account created shortly after comments moderation activity, surfaced through WordPress's user-creation audit trail where application logging is forwarded to syslog.

---
title: Potential XSS Payload Submitted via WordPress Comment Form
id: 3f7a2c51-9b4d-4e8a-b6c1-2d5e8f0a1b3c
status: experimental
description: Detects HTTP POST requests to wp-comments-post.php containing script tags or event-handler attributes in the request, consistent with delivery of a stored XSS payload targeting the WordPress Comments administration page fixed in WordPress 6.9.10.
references:
  - https://linuxsecurity.com/advisories/fedora/fedora-43-wordpress-2026-e0ebe50146
  - https://wordpress.org/news/category/security/
  - https://attack.mitre.org/techniques/T1189/
author: Security Arsenal
date: 2026/02/18
tags:
  - attack.initial_access
  - attack.t1189
  - attack.t1059.007
logsource:
  category: webserver
  product: apache
  service: access
detection:
  selection_method:
    cs-method: 'POST'
    cs-uri-stem|contains: '/wp-comments-post.php'
  selection_payload:
    cs-uri-query|contains:
      - '<script'
      - '%3Cscript'
      - 'onerror='
      - 'onload='
      - 'javascript:'
      - '<img'
      - '%3Cimg'
  condition: selection_method and selection_payload
falsepositives:
  - Rare; legitimate commenters do not submit markup in query strings, but plugins that log comment bodies to access logs may match
detailed_fields:
  - c-ip
  - cs-user-agent
  - cs-referrer
level: high
---
title: WordPress Admin Account Creation Following Comments Moderation Activity
id: 8c1e4d62-7a3f-4b9c-a5d2-6e8f1c0b4a7d
status: experimental
description: Detects WordPress user creation events (role administrator) recorded in syslog-forwarded application logs, which may indicate post-exploitation persistence after a successful stored XSS attack against a wp-admin session via the Comments administration page.
references:
  - https://linuxsecurity.com/advisories/fedora/fedora-43-wordpress-2026-e0ebe50146
  - https://attack.mitre.org/techniques/T1136/001/
author: Security Arsenal
date: 2026/02/18
tags:
  - attack.persistence
  - attack.t1136.001
logsource:
  product: linux
  service: wordpress
detection:
  selection:
    Message|contains|all:
      - 'user_register'
      - 'administrator'
  condition: selection
falsepositives:
  - Legitimate admin onboarding by site operators; correlate with change tickets and moderator session activity
level: medium

A note on tuning: the webserver rule assumes your access logs capture the query string for comment submissions. Many comment payloads travel in the POST body, which access logs do not record. If you run ModSecurity or a WAF (OWASP CRS), alert on CRS XSS rule hits scoped to /wp-comments-post.php and treat those as candidate stored-XSS deliveries requiring comment-queue review — that is far more actionable than a raw CRS alert storm.

KQL (Microsoft Sentinel / Defender)

For environments forwarding Apache/Nginx logs via CEF/Syslog into Sentinel, this hunt surfaces suspicious comment submissions plus a correlation view of who is touching the comments moderation surface afterward.

// Hunt: Suspicious comment submissions to wp-comments-post.php (potential stored XSS delivery)
let suspicious_terms = dynamic(["<script", "%3Cscript", "onerror=", "onload=", "javascript:", "%3Cimg", "<svg"]);
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where RequestMethod == "POST"
| where RequestURL has "wp-comments-post.php"
| extend HasPayload = tostring(suspicious_terms) // placeholder; evaluated below
| extend LowerURL = tolower(RequestURL)
| where LowerURL has_any (suspicious_terms)
| summarize SubmissionCount = count(), DistinctAgents = dcount(RequestClientApplication), SampleAgents = make_set(RequestClientApplication, 3)
  by SourceIP, RequestURL, bin(TimeGenerated, 1h)
| order by SubmissionCount desc;
// Correlation: administrator logins and comment moderation page views after suspicious submissions
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has "edit-comments.php" or SyslogMessage has "user_register" or SyslogMessage has "wp-login.php"
| where SyslogMessage has "administrator" or SyslogMessage has "edit-comments.php"
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL

On Fedora hosts running WordPress, use VQL to rapidly inventory which systems are still running a vulnerable WordPress core and to spot recently modified PHP files in the webroot — a standard post-takeover artifact when an XSS-compromised admin session is used to plant a backdoor via the theme or plugin editor.

-- Hunt: Identify vulnerable WordPress installs and recently modified PHP files (possible backdoors)
LET installs = SELECT FullPath AS VersionFile,
       read_file(filename=FullPath, length=4096) AS Content
FROM glob(globs=['/usr/share/wordpress/wp-includes/version.php',
                 '/var/www/html/wp-includes/version.php',
                 '/var/www/*/wp-includes/version.php',
                 '/srv/www/**/wp-includes/version.php'])

SELECT VersionFile,
       parse_string_with_regex(string=Content,
         regex="wp_version\\s*=\\s*'([^']+)'") AS VersionMatch,
       if(condition=VersionMatch =~ '6\\.9\\.10',
          then='PATCHED', else='REVIEW — possibly vulnerable') AS Status
FROM installs

-- Hunt: PHP files modified in the last 7 days inside WordPress webroots
SELECT FullPath, Mtime, Size
FROM glob(globs=['/usr/share/wordpress/**/*.php',
                 '/var/www/html/**/*.php',
                 '/srv/www/**/*.php'])
WHERE Mtime > (now() - 7 * 24 * 3600)
  AND FullPath !~ 'wp-content/uploads/.*\\.cache'
ORDER BY Mtime DESC

Remediation Script (Bash — Fedora 43)

The following script applies the Fedora 43 WordPress update, verifies the installed core version, and flags pending comments containing script-like markup so moderators can purge them before opening the queue in a browser.

#!/usr/bin/env bash
# WordPress 6.9.10 remediation for Fedora 43 (advisory 2026-e0ebe50146)
set -euo pipefail

echo "[1/5] Applying Fedora 43 wordpress security update..."
dnf -y update wordpress

echo "[2/5] Verifying installed WordPress version..."
VERSION=$(grep -oP "wp_version\s*=\s*'\K[^']+" /usr/share/wordpress/wp-includes/version.php || echo "unknown")
echo "Detected WordPress core version: ${VERSION}"
if [[ "${VERSION}" == "6.9.10" ]]; then
  echo "PASS: WordPress core is at 6.9.10 (patched)."
else
  echo "FAIL: Expected 6.9.10, found ${VERSION}. Do not mark this host remediated."
  exit 1
fi

echo "[3/5] Scanning pending comments for script-like payloads (requires wp-cli)..."
if command -v wp >/dev/null 2>&1; then
  for site_path in /usr/share/wordpress /var/www/html; do
    if [[ -f "${site_path}/wp-config.php" ]]; then
      echo "  Checking ${site_path}..."
      wp --path="${site_path}" comment list --status=hold --format=csv \
        --fields=comment_ID,comment_author,comment_author_IP,comment_content \
        2>/dev/null | grep -Ei '<script|onerror=|onload=|javascript:|<svg|<img' \
        && echo "  WARNING: suspicious pending comments found above — delete via wp-cli, NOT via the browser UI" \
        || echo "  No suspicious pending comments detected in ${site_path}."
    fi
  done
else
  echo "  wp-cli not installed; review pending comments in the database directly before moderating."
fi

echo "[4/5] Reloading web services..."
systemctl reload httpd 2>/dev/null || systemctl reload nginx 2>/dev/null || true

echo "[5/5] Reminder: force re-authentication for all wp-admin sessions."
echo "Done."

Important operational note: if you suspect malicious comments are already sitting in the pending queue, do not open the Comments admin page in a browser to delete them — that is the exact action that triggers the stored XSS on unpatched sites (and on patched sites, defense-in-depth still applies). Purge suspect comments via wp comment delete <ID> --force or direct database queries instead.

Remediation

Primary action — patch immediately:

• Fedora 43: apply the update from advisory 2026-e0ebe50146 (dnf update wordpress) and verify core reports version 6.9.10. Reference: https://linuxsecurity.com/advisories/fedora/fedora-43-wordpress-2026-e0ebe50146
• Self-hosted / other distributions: update via the WordPress admin dashboard (Dashboard → Updates) or download 6.9.10 from https://wordpress.org/download/ and review the release notes at https://wordpress.org/news/category/security/. If your site runs an older major branch, apply the corresponding backported security release — WordPress maintains security fixes for supported older branches.
• Managed hosting: confirm with your provider that automatic security updates to 6.9.10 have completed; do not assume auto-update is enabled — verify wp_version yourself.

Reduce exposure while patching (or if patching must be staged):

• Temporarily require login for comments (Settings → Discussion → "Users must be registered and logged in to comment") or disable comments entirely on sites where they are not business-critical. This removes the unauthenticated delivery vector for the stored XSS.
• Purge the pending queue from the command line, not the browser, before and after patching.
• Restrict wp-admin access by source IP (VPN/bastion only) at the web server or WAF layer. An attacker who steals a session they cannot use from a foreign IP gains far less.
• Enforce WAF rules (ModSecurity + OWASP CRS, or your cloud WAF equivalent) in blocking mode for XSS patterns scoped to /wp-comments-post.php.
• Review admin accounts and sessions: after patching, invalidate all sessions (wp user reset-password for admin users, or rotate AUTH_KEY/SECURE_AUTH_KEY/related salts in wp-config.php to kill every active session cookie) and audit wp_users for unexpected administrator accounts created in the exposure window.
• Audit outbound-HTTP consumers for the DoS issue: inventory plugins that fetch remote URLs from user input (feed readers, link checkers, oEmbed-heavy page builders) and disable any that are non-essential until patched.

Post-patch validation: confirm wp-includes/version.php reports 6.9.10 on every host (the VQL hunt above scales this), review web logs for the past 30 days for suspicious comment submissions, and confirm no PHP files in the webroot were modified outside your deployment pipeline.

The Bottom Line

Stored XSS in an admin moderation surface is one of the highest-consequence bug classes in the WordPress ecosystem because it converts an unauthenticated interaction — a public comment submission — into an authenticated administrator session. The 6.9.10 release closes that door, along with a DoS in the HTTP client that underpins core and plugin functionality. Fedora 43 users should apply advisory 2026-e0ebe50146 today, purge pending comment queues from the command line, rotate wp-admin sessions, and verify core version across every host. The patch diff is public; assume the exploit is not far behind.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub