SmartMag CVE-2025-64204

Exploitation requires an authenticated WordPress account with at least low-level privileges (PR:L - e.g., contributor/author or any role able to submit content into the vulnerable SmartMag field), plus victim user interaction (UI:R): a privileged user must view the page where the stored payload renders for the script to execute. The specific vulnerable field/feature is not named in the available data. Limiting factors: attacker must already have a valid account (not remote-unauthenticated), the payload only fires when another user loads the affected content, and the site must run SmartMag version 10.3.1 or earlier.

This is a moderate-severity Stored XSS (CWE-79) in the ThemeSphere SmartMag WordPress theme, affecting all versions up to and including 10.3.1. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L, base 6.5) indicates a network-reachable, low-complexity flaw but one that requires an authenticated account with at least low privileges (PR:L) AND victim user interaction (UI:R), with a changed scope (S:C) reflecting that injected script executes in another user's browser context. The real-world signals point to LOW urgency: EPSS is only 0.17% (5th percentile), there is no CISA KEV listing (not actively exploited), and no public exploit (POC) is identified in the provided data. These low-risk signals are consistent with each other and with the CVSS profile - the privilege and user-interaction requirements meaningfully constrain exploitation. This should be treated as a routine patch-cycle item rather than an emergency; it is a genuine but not high-priority issue. No signals conflict, though note the source is a single Patchstack advisory (no independent NVD enrichment beyond the referenced record), so affected-version precision ('n/a through <= 10.3.1') depends entirely on Patchstack.

A low-privileged authenticated user (e.g., a contributor/author account on a WordPress site running SmartMag) submits content containing a malicious script payload into a vulnerable field. The payload is stored and later rendered when an administrator or other user views the affected page, executing attacker-controlled JavaScript in that victim's authenticated browser session. No public exploit code is identified at time of analysis, and exploitation requires both an account and a victim viewing the content.