WP Sessions Time Monitoring Full Automatic CVE-2026-107648

No authentication required (PR:N): an unauthenticated attacker can inject via the 'action', 'function', 'plugin', 'post_type', 'post_status', 'ids', 'loggedout', or POST 'post_title' parameters handled by the WP Sessions Time Monitoring Full Automatic plugin in versions ≤1.1.5. The key limiting factor is that this is STORED XSS: the payload does not harm the attacker and only executes when another user - typically an administrator reviewing the plugin's active-session/activity pages - subsequently loads the page containing the injected content. Exploitation therefore requires the plugin to be installed and active, and requires a victim to view the affected admin/monitoring view for impact to materialize.

This is a moderate-priority issue, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N = 7.2 High) indicates remote, low-complexity, unauthenticated injection with a scope change, which is the standard Wordfence profile for unauthenticated stored XSS. However, there is no CISA KEV listing, no EPSS score provided, and no SSVC decision data in the input, so active-exploitation and automatability signals are absent. No public exploit code is referenced either. The realistic impact is partial (C:L/I:L) and browser-bound rather than direct server compromise: the 'unauthenticated' injection vector raises exposure, but actual harm requires a victim (notably an admin) to later view the injected content, which tempers the raw score. Net: treat as a routine-but-prompt patch, especially on sites running this plugin, rather than a drop-everything KEV-class event. Note one tension to verify: the vector encodes UI:N even though stored XSS payloads only execute when a user subsequently loads the affected page - Wordfence scores the injection step as requiring no interaction, which is defensible but means real-world impact still depends on a viewer.

An unauthenticated attacker submits a crafted request setting a tracked parameter such as 'action', 'function', 'post_type', or 'post_title' to a value containing a JavaScript payload. The plugin stores this input and later renders it without proper escaping, so when a logged-in administrator or other user opens the activity-monitoring page, the script executes in their browser session. No public exploit code was identified at time of analysis, though the vulnerable code paths are visible in the plugin's public source.