Blocksy WordPress Theme CVE-2026-8365: Brief Summary of PHP Object Injection to Remote Code Execution

Introduction

A two-stage PHP Object Injection chain in the Blocksy WordPress theme lets authenticated users with contributor-level access plant serialized PHP objects that execute arbitrary code when a database migration runs. The vulnerability, tracked as CVE-2026-8365 with a CVSS 3.1 score of 8.8, combines an inadequate input filter with an unrestricted @unserialize() call to deliver full Remote Code Execution through a built-in POP gadget.

Blocksy is a popular free WordPress theme developed by Creative Themes, marketed as a fast, modern theme optimized for the Gutenberg editor and WooCommerce. It has over 300,000 active installations on the WordPress.org theme directory, plus a premium "Blocksy Pro" tier. WordPress powers approximately 42.6% of all websites, so a vulnerability in a theme this widely deployed has considerable potential reach.

Technical Information

Vulnerability Classification

CVE-2026-8365 falls under CWE-502 (Deserialization of Untrusted Data). The NVD record, published June 9, 2026, assigns the CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. That means a network attack vector, low attack complexity, low privileges required (contributor role), no user interaction needed, unchanged scope, and high impact on confidentiality, integrity, and availability. The source CNA is [email protected].

The Two-Stage Attack Chain

The vulnerability chains two independent weaknesses that together produce a full RCE primitive.

Stage 1: Serialized Object Injection via the REST API

The Blocksy theme registers a blocksy_meta REST API field for setting post metadata through the WordPress REST API. The blocksy_sanitize_post_meta_options() function validates input for this field, and it is referenced at admin/helpers/validator.php line 75 and admin/helpers/meta-boxes.php line 104.

The sanitization logic only blocks values containing the characters < or >. That check is meant to stop HTML and XSS injection, and it is wholly insufficient against PHP Object Injection. Serialized PHP objects use the format O:length:"className":count:{...}, which contains no angle brackets and passes the filter without issue.

An authenticated attacker with contributor-level access (or above) can send a REST API request containing a crafted blocksy_meta field with a serialized Blocksy\RaiiPattern PHP object. The sanitization function accepts the value and stores it in the WordPress wp_postmeta table, where the payload sits dormant.

Stage 2: Deserialization Trigger via V200 Migration

The V200 database migration activates the stored object. During the migration, the SearchReplacer::run_recursively() function, located at inc/classes/db-versioning/utils/db-search-replacer.php line 98, iterates over database values and unconditionally applies @unserialize() to every string value it encounters.

The critical flaw is that the unserialize() call omits PHP's allowed_classes parameter. Without that restriction, PHP fully reconstructs any serialized object, including the attacker-controlled Blocksy\RaiiPattern instance.

Stage 3: POP Gadget Execution via RaiiPattern::__destruct()

The Blocksy\RaiiPattern class, defined at inc/classes/raii.php line 12, implements the RAII (Resource Acquisition Is Initialization) pattern. Its __destruct() magic method executes a cleanup callable via call_user_func() when the object is destroyed.

The attacker controls both the callable and its arguments, since both are embedded in the serialized object properties, so call_user_func() executes arbitrary PHP callables. This is a textbook Property-Oriented Programming (POP) gadget chain, in which a legitimate class method meant for resource cleanup becomes an arbitrary code execution primitive.

Attack Prerequisites

The V200 migration dependency adds a timing constraint. The attacker has to inject the payload first, and the migration has to run afterwards, typically when the site upgrades to a version that includes the V200 migration step. The result is a delayed detonation. The malicious payload can sit in the database for an extended period before it executes, which complicates detection and attribution.

Root Cause Analysis

Two distinct coding decisions enabled this chain:

1. Incomplete input validation: The blocksy_sanitize_post_meta_options() function was designed with HTML injection in mind and filters only for < and > characters. It did not account for serialized PHP object strings, which belong to a different attack class entirely. This is a common pattern in WordPress theme and plugin development, where sanitization is built around web output contexts rather than safe data storage.

2. Unrestricted deserialization: The SearchReplacer::run_recursively() function calls @unserialize() without specifying allowed_classes. PHP has supported the allowed_classes option since version 7.0, specifically to mitigate this class of vulnerability. The @ error suppression operator also hides any deserialization errors, so the behavior is silent.

Either weakness alone would be insufficient for exploitation. Without the sanitization bypass, the serialized object could not be stored. Without the unrestricted deserialization, the stored string would remain inert. The chain requires both.

Affected Systems and Versions

The vulnerability affects the Blocksy theme for WordPress in all versions up to and including 2.1.41. That covers both the free version on the WordPress.org theme directory and the premium Blocksy Pro variant.

The Wordfence advisory confirms version 2.1.42, released May 14, 2026, as the first patched version. The changelog for this release describes the fix as "Improve validation of post meta for unexpected values."

Sites are vulnerable if they meet all of the following conditions:

• Run Blocksy theme version 2.1.41 or earlier
• Have at least one user account with contributor-level access or above
• Will trigger or have triggered the V200 database migration

The Trac references in the advisory point to source code in versions 2.1.35 and 2.1.41, which confirms that the vulnerability spans at least this range. The NVD entry's description says "versions up to and including 2.1.35", and the Wordfence advisory extends this to 2.1.41, so all versions in this range should be considered affected.

Vendor Security History

Creative Themes has a documented history of security vulnerabilities across the Blocksy theme and its companion plugin:

Input validation failures run through these disclosures: two XSS vulnerabilities, an SVG upload bypass, and now a critical PHP Object Injection flaw. The pattern suggests that security review at Creative Themes has historically not caught sanitization gaps before release.

The vendor does not appear to maintain a dedicated security disclosure page or bug bounty program. The understated changelog entry for version 2.1.42 ("Improve validation of post meta for unexpected values") does not explicitly identify the change as a security fix, which may lead site administrators to treat it as a routine update rather than a critical security patch.

References

• NVD: CVE-2026-8365
• CVE.org: CVE-2026-8365 Record
• Wordfence Advisory: Blocksy <= 2.1.41 PHP Object Injection
• Wordfence Advisory (alternate link)
• Blocksy Theme Source: meta-boxes.php (v2.1.35)
• Blocksy Theme Source: validator.php (v2.1.35)
• Blocksy Theme Source: db-search-replacer.php (v2.1.35)
• Blocksy Theme Source: raii.php (v2.1.35)
• Blocksy Theme Source: meta-boxes.php (v2.1.41)
• Blocksy Theme Source: validator.php (v2.1.41)
• Blocksy Theme Source: db-search-replacer.php (v2.1.41)
• Blocksy Theme Source: raii.php (v2.1.41)
• Blocksy Changelog
• WordPress.org: Blocksy Theme
• CWE-502: Deserialization of Untrusted Data
• OWASP: PHP Object Injection
• OWASP: Deserialization of Untrusted Data
• WPScan: Blocksy Theme Vulnerabilities
• Patchstack: Blocksy Companion Vulnerabilities
• Patchstack: Blocksy Theme XSS (CVE-2026-2583)
• NVD: CVE-2024-11420
• SentinelOne: CVE-2026-2583