CVE-2026-96768 in GoSMTP Pro Plugin
Summary
by MITRE • 10/16/2026
The GoSMTP Pro plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Comment Content via Email Log Body in all versions up to, and including, 1.2.3 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The exploit is made possible because WordPress comment kses does not strip entity-encoded tag delimiters, allowing the payload to pass moderation as safe text before being decoded into live HTML by core email notification functions and written verbatim into the plugin's email log database table.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The GoSMTP Pro plugin for WordPress presents a significant security risk due to a stored cross-site scripting vulnerability present in all versions up to 1.2.3. This flaw stems from insufficient input sanitization and output escaping mechanisms within the application logic, specifically affecting how comment content is processed when logged via email notifications. The vulnerability allows unauthenticated attackers to inject arbitrary web scripts into pages that are subsequently viewed by other users. When a user accesses these compromised pages, the injected malicious code executes in their browser context, potentially leading to session hijacking, defacement, or further malware distribution depending on the attacker's objectives and the privileges of the affected user.
The technical root cause lies in the interaction between WordPress core comment handling functions and the GoSMTP Pro plugin’s email logging feature. Typically, WordPress employs a filtering mechanism known as kses to strip potentially dangerous tags from user input before storage or display. However, this specific vulnerability exploits a gap where entity-encoded tag delimiters are not stripped by the standard moderation filters. Consequently, an attacker can submit a comment containing encoded script tags that appear safe during initial validation and moderation processes. These payloads pass through as harmless text until they reach the plugin’s email notification functions, which decode the entities back into live HTML characters. The decoded content is then written verbatim into the plugin's internal database table for logging purposes without further sanitization or escaping prior to display.
This sequence of events creates a stored cross-site scripting vector because the malicious payload persists in the database and is rendered dynamically whenever an administrator or authorized user views the email log within the WordPress dashboard. Unlike reflected XSS, where the attack requires tricking a victim into clicking a crafted link, this vulnerability ensures that every time the vulnerable page loads for any authenticated user with access to the logs, the script executes automatically. This persistence amplifies the impact significantly, as it does not rely on social engineering tactics beyond initial submission and affects all users who view the compromised log entries.
From an industry standards perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The attack vector corresponds to ATT&CK technique T1059, specifically Command and Scripting Interpretation via browser-based execution, although the primary impact is data theft or session manipulation rather than direct system command execution. The failure to properly sanitize input before storage represents a classic violation of secure coding principles regarding trust boundaries between user input and internal processing logic.
Mitigation strategies should prioritize immediate updates to version 1.2.4 or later if available, as the developer likely addressed these sanitization gaps in subsequent releases. In cases where updating is not immediately feasible, administrators can implement temporary workarounds such as restricting access to the email log pages through additional authentication layers or IP whitelisting within web server configurations. Additionally, deploying a Web Application Firewall with rules capable of detecting and blocking entity-encoded script injection patterns may provide an extra layer of defense against exploitation attempts while longer-term remediation is planned. Regular security audits focusing on input validation and output encoding practices across all custom plugins are essential to prevent similar vulnerabilities in the future.