CVE-2026-97315 in Responsive Blocks Plugin
Summary
by MITRE • 10/15/2026
The Responsive Blocks WordPress plugin before 2.3.0 does not sanitise or escape some of the values submitted with its Form block before adding them to the HTML notification email sent to the site owner, allowing unauthenticated users to inject arbitrary HTML, such as phishing links, into that email.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Responsive Blocks WordPress plugin versions prior to 2.3.0 represents a critical security flaw rooted in insufficient input validation and output encoding mechanisms within its Form block functionality. This specific weakness allows unauthenticated attackers to inject arbitrary HTML content into automated notification emails that are sent to the site administrator upon form submission by end users. The core technical failure lies in the plugin's handling of user-supplied data, where values submitted through public-facing forms are processed and included in outgoing email notifications without being properly sanitized or escaped for their specific context. In web application security, this is a classic manifestation of Cross-Site Scripting (XSS) when viewed from the perspective of the recipient client, but more accurately classified as Stored XSS via Email Injection because the malicious payload persists within the system's data store and is rendered by the administrator's email client upon retrieval.
From an architectural standpoint, the vulnerability exploits the trust relationship between the application backend and the administrative user interface. When a visitor submits a form, the plugin aggregates various fields into an HTML-formatted notification message intended for the site owner. Because these input values are not subjected to rigorous sanitization routines that strip or encode potentially dangerous characters such as angle brackets, quotes, and script tags, any malicious code embedded in the submission is preserved intact within the email body. Consequently, when the administrator opens this email using a web-based mail client or an email application with HTML rendering capabilities enabled, the injected scripts execute automatically within the context of that environment. This execution occurs without requiring any additional interaction from the victim beyond opening the message, significantly lowering the barrier for exploitation and increasing the likelihood of successful compromise.
The operational impact of this vulnerability is severe due to its potential for facilitating sophisticated phishing campaigns against site administrators. An attacker can craft a form submission containing HTML content that mimics legitimate login pages or urgent security alerts, directing the administrator to malicious URLs designed to harvest credentials or install malware on their device. Since the email appears to originate from the trusted WordPress environment itself, it bypasses many user skepticism filters and standard anti-phishing heuristics that rely on domain reputation analysis. Furthermore, if the administrator's session cookies are accessible within the same browser context as the email client, cookie theft via JavaScript execution could lead to complete account takeover. This scenario aligns directly with the MITRE ATT&CK framework technique T1566.002, which describes Spearphishing Link attacks where victims are lured into clicking a malicious link delivered through social engineering tactics facilitated by trusted channels.
In terms of industry-standard vulnerability classifications, this issue corresponds to CWE-79: Improper Neutralization of Input During Web Page Generation commonly known as Cross-Site Scripting. Specifically, it falls under the sub-category of Stored XSS because the payload is saved on the target server and later retrieved by victims. Additionally, the lack of proper output encoding for HTML contexts highlights a failure in adher to secure coding practices regarding context-sensitive escaping. The vulnerability also touches upon CWE-20: Improper Input Validation, as the application fails to adequately filter or validate user inputs before processing them into sensitive outputs like administrative notifications. These classifications underscore the necessity for developers to implement strict allow-listing strategies and robust encoding functions tailored to each output destination, whether it be HTML bodies, attributes, URLs, or JavaScript contexts.
To mitigate this vulnerability effectively, immediate action must be taken by updating the Responsive Blocks plugin to version 2.3.0 or later, where these input handling mechanisms have been corrected. For organizations unable to patch immediately due to compatibility constraints, temporary mitigation strategies should focus on restricting form submission capabilities if possible and ensuring that administrators use email clients with strict HTML rendering policies disabled for untrusted sources. Implementing Content Security Policy headers can also help mitigate the impact of any successfully injected scripts by preventing unauthorized script execution within the browser environment where the emails are viewed. Long-term remediation requires a comprehensive review of all user input handling processes across the WordPress ecosystem, enforcing rigorous sanitization at ingestion and context-aware escaping at output to prevent similar injection vectors in other plugins or custom code modules that interact with administrative notifications.