GSpeech TTS CVE-2026-96578

Exploitation requires that the GSpeech TTS plugin is active and its output-buffer rewrite runs on the page displaying the comment, and that the site accepts comments (the injection vector is Comment Content). The payload must be constructed from kses-allowed tags/attributes so it survives WordPress comment sanitization, then relies on the plugin's request-time HTML rewrite to become executable. Practical limiting factors: comments from unauthenticated users are frequently held for moderation or require approval depending on site configuration, so auto-published comments materially increase exposure; a victim must subsequently load the affected page for the stored script to fire; and sites not running GSpeech (or not rendering GSpeech output on the commented page) are unaffected.

This is a genuine but moderate-priority issue rather than 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, base 7.2 High) indicates a network-reachable, low-complexity, unauthenticated stored XSS with a scope change - consistent with the description, where an unauthenticated attacker plants a comment that later executes against any visitor of the rendered page. The scope change (S:C) is well-justified: the plugin's output-buffer callback rewrites HTML at request time, so a payload stored under the WordPress site's security context executes in the browser context of other users. No EPSS score was provided in the input, there is no CISA KEV listing, and no public POC is referenced - exploitation status is therefore 'no public exploit identified at time of analysis.' Note one tension worth flagging: the CVSS marks UI:N, but as a stored XSS the payload only fires when a victim actually loads an affected page, so real-world triggering still depends on a user visiting the injected content even though no explicit interaction with the attacker is needed. The novel element raising practical risk is the mXSS-style bypass: the payload is stored using only kses-allowed tags/attributes (so WordPress comment sanitization passes it) and becomes malicious only after the plugin's output rewrite, defeating the platform's standard defense. Overall: credible, unauthenticated, and bypasses a normally-trusted control, but impact is limited to C:L/I:L/A:N and the affected product has a narrow footprint, keeping this below critical.

An unauthenticated attacker submits a blog comment containing only kses-permitted HTML tags and attributes, which passes WordPress comment sanitization and is stored. When the GSpeech plugin's output-buffer callback later rewrites the rendered page HTML, the benign-looking markup is transformed into active event handlers/style fragments, so arbitrary script executes in the browser of any user who views that page. No public exploit code is referenced in the available data, but the technique is fully described and low-complexity.