Attack Vectors

Inquiry form to posts or pages (slug: inquiry-form-to-posts-or-pages) version 1.0 is reported as Medium severity (CVSS 4.3, CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N) under CVE-2026-6293.

The primary entry point is a Cross-Site Request Forgery (CSRF) scenario: an attacker can trick a logged-in WordPress administrator (or another user with access to the plugin’s settings) into submitting a hidden request that updates plugin settings. This requires user interaction (for example, clicking a link or visiting a page while already authenticated), which is reflected in the “UI:R” part of the CVSS vector.

Once the settings are modified, the issue can escalate into Stored Cross-Site Scripting (Stored XSS) via the inq_header parameter (and potentially other settings fields, per the advisory), where malicious content is saved and later rendered in the WordPress admin or site pages where the stored value is displayed.

Security Weakness

According to the published details, the plugin’s settings update process lacks standard WordPress protections. The handler triggers based solely on $_POST[‘inq_hidden’] == ‘Y’ and does not use nonce validation (for example, there is no call to check_admin_referer() and no nonce present in the settings form).

The advisory also states there is insufficient input sanitization on user-supplied fields and missing output escaping when rendering stored values. In combination, this creates a pathway where a forged settings update can persist attacker-controlled content that is later displayed, resulting in stored XSS.

Because this is a settings-focused CSRF issue, the practical risk is heavily influenced by who can access the plugin’s settings, how often administrators browse the web while logged into WordPress, and whether additional controls (like web filtering, WAF rules, or restrictive admin policies) are in place.

Technical or Business Impacts

Even at a Medium CVSS score, CSRF-to-Stored-XSS issues can create disproportionate business risk because they can undermine trust in your website and marketing operations. Potential impacts include unauthorized changes to site behavior, insertion of unwanted content, and scripted actions that run in the context of an authenticated user when the stored payload is viewed.

From a marketing and revenue perspective, stored XSS can enable outcomes like lead-form manipulation, on-site message tampering, traffic redirection, or brand-damaging content injection—often in ways that are difficult to spot immediately. From a governance perspective, it can also complicate incident response and compliance reporting if user data or customer journeys are affected.

Remediation note: the source indicates no known patch is available at this time. Given that, risk-based mitigations may include: uninstalling the Inquiry form to posts or pages plugin and replacing it with a maintained alternative; restricting access to WordPress admin (IP allowlisting/VPN); enforcing least-privilege admin roles; using a reputable WAF; and increasing monitoring for unexpected settings changes and suspicious scripts. Your best path depends on your organization’s risk tolerance and reliance on the plugin.

Similar Attacks

Stored XSS in WordPress plugins has been repeatedly documented as a real-world risk because it can persist in the environment and trigger when an administrator or visitor loads affected pages. One widely referenced example is CVE-2019-9978 (Social Warfare), which was publicly tracked as a stored XSS issue in a WordPress plugin and illustrates how plugin-level XSS can become a business-impacting website compromise.