CVE-2026-8365: Blocksy WordPress Theme RCE via Serialized Object Injection

Technical summary

CVE-2026-8365 exploits a chain of two vulnerabilities in Blocksy versions up to 2.1.35. First, the blocksy_sanitize_post_meta_options() function in the blocksy_meta REST API field applies insufficient input sanitization—it only strips '<' and '>' characters but does not prevent serialized PHP object strings from being stored in post meta. Second, during the V200 database migration, the SearchReplacer::run_recursively() function calls @unserialize() on all string values without specifying an allowed_classes parameter, enabling arbitrary class instantiation. A crafted serialized Blocksy\RaiiPattern object can be injected via the REST API; upon migration, its __destruct() magic method is invoked, executing arbitrary PHP callables via call_user_func(). The attack requires authentication and contributor-level capabilities, placing it within the reach of many WordPress installs that grant such roles to freelancers, editors, or other collaborative users.

Business impact

This vulnerability creates a post-authentication remote code execution pathway for any Blocksy user whose site grants contributor or higher roles to external parties or compromised accounts. An attacker gaining contributor access—through phishing, credential compromise, or plugin exploitation—can achieve complete site takeover without requiring admin privileges. The impact extends to data exfiltration, malware injection, website defacement, and lateral movement into connected systems. Organizations relying on Blocksy for client sites, SaaS platforms, or multi-author publishing face heightened risk if user access is not tightly controlled.

Affected systems

Blocksy WordPress theme versions up to and including 2.1.35 are affected. The vulnerability manifests during the upgrade process to versions containing the V200 database migration. Any Blocksy installation that has stored malicious serialized objects in post meta prior to upgrade will trigger the vulnerability when the migration runs. Sites that have never granted contributor-level access or do not use the blocksy_meta REST endpoint may have lower practical risk, though the vulnerability remains present.

Exploitability

Exploitation requires authentication and contributor-level WordPress role or above. The attack is non-interactive once the object is injected—the payload activates automatically during the database migration that occurs on upgrade. No user action or social engineering is needed at execution time. For sites with liberal contributor access policies, the barrier to exploitation is low; for restrictively managed sites, it depends on whether an attacker can first obtain a valid contributor account through credential compromise or authorization misconfiguration.

Remediation

Update Blocksy to the patched version released after 2.1.35 (verify against the official Blocksy changelog and security advisory for the exact version number). Additionally, audit WordPress user roles and revoke unnecessary contributor-level permissions. Review access logs and post meta for suspicious serialized objects if you suspect prior exploitation. If you cannot patch immediately, restrict REST API access to blocksy_meta or disable the REST API for untrusted user roles at the application level, though this may impact site functionality.

Patch guidance

Check the official Blocksy website and security advisories for the release that addresses CVE-2026-8365. Most WordPress theme updates can be applied directly through the WordPress admin dashboard. Before patching production sites, test the update in a staging environment to confirm compatibility with custom code and active plugins. After patching, the V200 migration will run safely on next admin action; no manual migration step is required. Monitor error logs during and after upgrade for any migration-related issues.

Detection guidance

Search post meta and database logs for serialized PHP object strings, particularly those containing 'Blocksy\\RaiiPattern'. Monitor REST API requests to endpoints containing 'blocksy_meta' for POST/PUT operations from contributor-level accounts. Check the WordPress debug log for PHP unserialize() warnings or notices during database migrations. Review access logs for unusual contributor account activity or new accounts created around the time of suspected compromise. Network-based detection should flag suspicious database queries or PHP process spawning following REST API calls to Blocksy endpoints.

Why prioritize this

This vulnerability merits immediate attention due to its high CVSS score (8.8), post-authentication code execution capability, and the prevalence of WordPress sites using popular themes. The exploitation chain is reliable and requires only contributor-level access, a role commonly granted to external contributors, vendors, and content teams. The automatic trigger on upgrade means affected sites face risk during a routine maintenance window. Organizations should prioritize patching and access review within days, not weeks.

Risk score, explained

The CVSS 3.1 score of 8.8 (HIGH) reflects the combination of network accessibility, low complexity, and high confidentiality, integrity, and availability impact. The score assumes an authenticated attacker; the requirement for contributor-level or above reduces the attack surface compared to unauthenticated RCE but does not eliminate it, since many organizations grant such roles liberally. The automatic code path during migration—no user interaction required—supports the high score. Organizations with strict role management may argue their practical risk is lower; those with permissive policies should treat it as critical.

Frequently asked questions