MEDIUM 4.4

CVE-2026-12430: Blocksy Companion WordPress Plugin Stored XSS Vulnerability

Blocksy Companion, a popular WordPress plugin, contains a stored cross-site scripting (XSS) vulnerability affecting all versions through 2.1.45. Authenticated users with editor-level permissions or higher can inject malicious scripts into the plugin's admin settings that will execute for anyone viewing the affected pages. This vulnerability only manifests in WordPress multisite installations or single-site setups where the unfiltered_html capability has been disabled—a common hardening practice. The threat is limited to authenticated attackers but can lead to session hijacking, credential theft, or site defacement.

Source data · NVD / CISA · public domain

CVSS
3.1 · 4.4 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N
Weaknesses (CWE)
CWE-79
Affected products
0 configuration(s)
Published / Modified
2026-06-19 / 2026-06-22

NVD description (verbatim)

The Blocksy Companion plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 2.1.45 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with editor-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

8 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-12430 is a Stored XSS vulnerability (CWE-79) in Blocksy Companion stemming from insufficient input sanitization and output escaping in admin settings. An editor-level or higher authenticated user can craft malicious input that persists in the plugin's configuration, and the unescaped output is rendered to subsequent page viewers. The vulnerability exploits the plugin's failure to properly sanitize user input before storage and to escape output at render time. Notably, the vulnerability is conditional: it only triggers when unfiltered_html has been revoked from users (including administrators), which is standard practice in hardened multisite environments. In single-site installations where administrators retain unfiltered_html capability, the attack surface is effectively reduced because admins can already inject arbitrary HTML/JavaScript at will through other vectors.

Business impact

In affected multisite WordPress networks, this vulnerability allows editor-level insiders or compromised editor accounts to deface pages, redirect users, steal credentials, or distribute malware to site visitors. The persistence of the injected scripts means the attack continues until detected and remediated. For organizations running Blocksy Companion across multiple sites, a single compromised editor account could compromise multiple properties. This is particularly concerning for agencies, SaaS platforms, and enterprises managing shared WordPress environments where editor accounts are delegated to less-trusted team members or external partners.

Affected systems

Blocksy Companion plugin for WordPress versions up to and including 2.1.45 are vulnerable. The vulnerability is restricted to: (1) WordPress multisite installations, or (2) single-site installations where the unfiltered_html capability has been disabled. Standard single-site WordPress installations where administrators retain unfiltered_html are not affected because administrators already possess the ability to inject scripts through other mechanisms. Organizations using Blocksy Companion in a hardened multisite environment with granular permission controls face the highest risk.

Exploitability

Exploitation requires valid WordPress authentication with editor-level permissions or above. An attacker must either possess legitimate editor credentials or compromise an account with such privileges. The attack does not require user interaction beyond normal site navigation—once the malicious payload is stored in plugin settings, it executes whenever the page is visited. However, the vulnerability is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, indicating no widespread active exploitation has been confirmed. The conditional nature (only affecting multisite or hardened single-site installs) further restricts the practical attack surface.

Remediation

Upgrade Blocksy Companion to a patched version released after 2.1.45. Verify the specific patch version against the official Blocksy plugin repository or vendor advisory. Until patching is possible, restrict editor-level permissions to trusted users only, conduct a security audit of all users with editor or higher privileges, and review plugin settings for any suspicious scripts or unexpected configuration changes. Monitor admin activity logs for unauthorized modifications to plugin settings. If compromise is suspected, inspect the plugin settings database entries directly for injected scripts.

Patch guidance

Check the official Blocksy Companion plugin page on WordPress.org or the vendor's website for the latest patched version. Update through the WordPress admin dashboard (Plugins > Updates) once a fix is confirmed available. Before deploying to production, test the update in a staging environment to ensure compatibility with your theme and other plugins. Verify in the plugin changelog that the update specifically addresses CVE-2026-12430 and input sanitization improvements.

Detection guidance

Review Blocksy Companion plugin settings and configuration for suspicious script content, particularly in text fields and code sections. Check WordPress admin activity logs and database audit logs for changes to plugin settings by editor-level or higher accounts, especially outside normal business hours. Use WordPress security plugins to scan for stored XSS payloads. Search plugin configuration data for common XSS patterns such as <script>, onclick=, onerror=, and javascript: URLs. Query the WordPress postmeta and options tables for unexpected JavaScript within Blocksy settings entries. Monitor website traffic for signs of injected redirects or unexpected client-side behavior on pages that should not contain such functionality.

Why prioritize this

While the CVSS score of 4.4 reflects medium severity, the conditional nature of this vulnerability (multisite or hardened single-site only) and the requirement for authenticated editor-level access limit its overall risk. However, the persistence of stored XSS and its impact on multiple site visitors warrant timely patching. Organizations with multisite WordPress networks, especially those managing user-delegated editor accounts, should prioritize this update. Single-site installations with standard admin-only unfiltered_html permissions face lower risk but should still apply the patch during regular maintenance windows.

Risk score, explained

The CVSS 3.1 score of 4.4 (MEDIUM) reflects: network-based attack vector, high complexity due to permission requirements (editor or above), high privilege level needed, no user interaction required once stored, changed scope (XSS can affect other users), and limited impact (confidentiality and integrity each low, no availability impact). The conditional requirement that unfiltered_html be disabled, combined with the need for authenticated access, prevents a higher score despite the persistence of stored XSS. Organizations with relaxed permission models may experience greater practical impact than the score suggests.

Frequently asked questions

Does this affect my single-site WordPress installation with default settings?

Likely not. The vulnerability only manifests if you have explicitly disabled the unfiltered_html capability (standard in multisite networks but not typical for single-site installs). If your site administrators have unfiltered_html permission enabled—the default—they can already inject scripts through other means, so this plugin vulnerability is less of a concern. However, you should still update as a defensive best practice.

What should I do if I suspect my Blocksy settings have been compromised?

Immediately audit all users with editor-level permissions and change passwords for any accounts you don't recognize or trust. Review the plugin's stored settings (in wp_options table, specifically Blocksy-prefixed entries) for any suspicious JavaScript or HTML. Consider restoring settings from a known-good backup if malicious content is found. Then upgrade to the patched version and review site pages for any injected content visible to visitors.

Is this vulnerability being actively exploited in the wild?

No. The vulnerability is not listed on CISA's Known Exploited Vulnerabilities catalog, which means no widespread active exploitation has been publicly confirmed as of the publication date. However, you should not rely on this as justification for delay—determined attackers targeting your organization may exploit this regardless of public awareness.

Why does this only affect multisite or hardened single-site setups?

In standard single-site WordPress, administrators have unfiltered_html capability by default, which allows them to inject scripts directly through the editor and other native tools. This plugin vulnerability becomes a distinct security concern only when that capability is revoked, which is common in multisite networks where admins want to prevent lower-privilege users from injecting arbitrary code. In those restricted environments, the plugin's XSS flaw becomes exploitable by editor-level users.

This analysis is provided for informational purposes and based on available vulnerability intelligence as of the publication date. No exploit code or weaponized proof-of-concept is provided. Organizations should verify patch availability and compatibility in their environment before deployment. Consult the official Blocksy plugin repository and your WordPress security team for vendor-specific guidance. SEC.co makes no warranty regarding the completeness or accuracy of remediation steps, and liability is disclaimed to the fullest extent permitted by law. Always test security updates in a staging environment first. Source: NVD (public-domain), retrieved 2026-07-27. Analysis generated by SEC.co (claude-haiku-4-5).