The Ajax Load More WordPress plugin before 7

CVE-2026-6495 is a reflected XSS in the WordPress plugin Ajax Load More affecting versions before 7.8.4. WPScan's proof-of-concept shows the vulnerable path is the alm_preview parameter, where attacker-controlled shortcode content is reflected back into the page without proper sanitization or escaping; the practical victim is a logged-in privileged user, especially a WordPress admin, who opens a crafted URL.

The vendor's HIGH 7.1 score is too generous for real enterprise prioritization. Yes, JavaScript in an admin's browser can be dangerous on WordPress, but the chain still requires social engineering, a live authenticated admin session, and same-site browser execution rather than unauthenticated server compromise; that combination materially narrows both reachable population and blast radius.

Why this verdict

• Down from vendor HIGH because UI:R is the whole ballgame — the attacker does not get impact unless a target user opens a malicious link while logged in
• Requires a privileged victim session — in practice this implies phishing, chat-delivery, or some other prior foothold into user communications rather than opportunistic internet exploitation at scale
• Blast radius is narrow — each successful exploit is typically one WordPress site/tenant and one browser session, not a fleet-wide pre-auth takeover surface
• No exploitation amplifier — no KEV listing, no credible active-campaign reporting, and the supplied EPSS is extremely low
• Still not LOW — public PoC exists, no authentication is required to build/host the exploit URL, and admin-context JavaScript on WordPress can absolutely become serious for the affected site

Why not higher?

This is not a pre-auth server compromise, not an RCE, and not a wormable edge bug. The need for a privileged user click is compounding friction: it assumes reachable users, successful lure delivery, and an active authenticated browser session on the target site.

Why not lower?

Reflected XSS against WordPress admins is not harmless. If the lure lands, attacker-controlled JavaScript runs in the site's origin and can abuse the victim's session for meaningful site-level actions, so this deserves more than backlog-only treatment.

1. Restrict WordPress admin access — Put /wp-admin/ and other admin-only paths behind IP allowlists, VPN, or identity-aware proxy controls where possible. This does not fix the bug, but it reduces the chance that a phished admin opens the target URL from an uncontrolled context; for a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, so implement this as hygiene rather than an emergency change.
2. Enforce MFA and dedicated admin browser profiles — Require MFA for WordPress admins and push admins to use a separate browser/profile only for site administration. MFA will not stop XSS already running in the browser, but dedicated admin browsing habits materially cut click-through probability from everyday email/chat workflows; again, no mitigation SLA applies here, so this is a risk-reduction control before patch completion within the remediation window.
3. Watch for alm_preview abuse — Add reverse-proxy, WAF, or web-server detections for requests containing alm_preview= with encoded tags, event handlers, or shortcode-breaking input. This is useful for hunting and triage because reflected XSS often leaves obvious payload artifacts in logs, and for a MEDIUM issue it is an appropriate monitoring control while you patch inside the remediation window.
4. Harden plugin governance — Limit who can install or keep nonessential WordPress plugins, and remove unused ones from internet-facing sites. That shrinks future XSS and plugin-chain abuse exposure; for this verdict there is no mitigation SLA — go straight to the 365-day remediation window.

Run this on the target WordPress host or from a management shell that can read the site's plugin files. Invoke it as bash check-alm-cve-2026-6495.sh /var/www/html and use an account with read access to the WordPress installation; root is not required unless filesystem permissions are locked down.

#!/usr/bin/env bash
# check-alm-cve-2026-6495.sh
# Detects whether the Ajax Load More WordPress plugin is vulnerable to CVE-2026-6495
# Usage: bash check-alm-cve-2026-6495.sh /path/to/wordpress
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

WP_ROOT="${1:-}"
if [ -z "$WP_ROOT" ]; then
  echo "UNKNOWN - missing WordPress path argument"
  exit 2
fi

PLUGIN_FILE="$WP_ROOT/wp-content/plugins/ajax-load-more/ajax-load-more.php"
if [ ! -f "$PLUGIN_FILE" ]; then
  echo "UNKNOWN - plugin file not found: $PLUGIN_FILE"
  exit 2
fi

VERSION_LINE=$(grep -iE '^\s*Version:\s*' "$PLUGIN_FILE" 2>/dev/null | head -n1)
if [ -z "$VERSION_LINE" ]; then
  echo "UNKNOWN - could not read plugin version from $PLUGIN_FILE"
  exit 2
fi

VERSION=$(printf '%s' "$VERSION_LINE" | sed -E 's/^\s*Version:\s*//I' | tr -d '\r' | xargs)
if [ -z "$VERSION" ]; then
  echo "UNKNOWN - parsed empty version string"
  exit 2
fi

verlt() {
  # returns success if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

TARGET_FIXED="7.8.4"

if verlt "$VERSION" "$TARGET_FIXED"; then
  echo "VULNERABLE - Ajax Load More version $VERSION is earlier than fixed version $TARGET_FIXED"
  exit 1
fi

if [ "$VERSION" = "$TARGET_FIXED" ] || ! verlt "$VERSION" "$TARGET_FIXED"; then
  echo "PATCHED - Ajax Load More version $VERSION is $TARGET_FIXED or newer"
  exit 0
fi

echo "UNKNOWN - unable to compare version $VERSION"
exit 2

Sources

1. NVD CVE-2026-6495
2. WPScan plugin overview for Ajax Load More
3. WPScan vulnerability detail / PoC
4. WordPress.org plugin page
5. GitHub repository and releases
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. FIRST EPSS API documentation