CVE-2026-57624: Verified Repro With Script Download

Blocksy Companion Pro (by Creative Themes) ships a premium "Code Editor" Gutenberg block (blocksy-companion-pro/code-editor) registered in framework/premium/features/code-editor.php. The block's render_callback extracts PHP source from the block innerHTML (or the code attribute) and passes it to get_eval_content(), which executes it with eval('?>' . $code). In versions <= 2.1.46 the callback performed no execution-context check, so the block executed arbitrary PHP whenever it was rendered through the standard WordPress block renderer (do_blocks()) — for example when an unauthenticated visitor requested the single-view URL of a published ct_content_block whose post_content contained a code-editor block. This yields unauthenticated remote code execution (CVSS 10.0, CWE-94). The vendor fix in 2.1.47 adds a guard that only allows execution when the block is rendered through the legitimate Blocksy content-block renderer (which sets an explicit ct_allow_code_editor flag); the standard do_blocks path no longer executes the code.

• Package / component affected: blocksy-companion-pro plugin, Blocksy\CodeEditor class in framework/premium/features/code-editor.php (the blocksy-companion-pro/code-editor Gutenberg block render callback).
• Affected versions: Blocksy Companion Pro <= 2.1.46 (fixed in 2.1.47).
• Risk level: Critical (CVSS 3.1 10.0, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).
• Consequences: An unauthenticated remote attacker can execute arbitrary PHP — and therefore arbitrary operating-system commands — in the context of the web server (www-data), leading to full site compromise, data exfiltration, and lateral movement on the host.

Impact Parity

• Disclosed / claimed maximum impact: Unauthenticated Remote Code Execution (Patchstack: "Required privilege: Unauthenticated", CVSS 10.0, CWE-94).
• Reproduced impact from this run: Unauthenticated remote code execution confirmed end-to-end. An HTTP GET with no cookies/credentials to a published content-block single-view URL caused the code-editor block's render_callback to eval() attacker-controlled PHP that ran shell_exec("id; whoami; hostname; uname -a"). The command output (uid=33(www-data) ..., hostname, kernel string) appeared in the HTTP response and was written to a marker file by the www-data user inside the WordPress container.
• Parity: full — the claimed unauthenticated code execution was demonstrated with concrete command output, plus a fixed-version negative control proving the patch blocks it.
• Not demonstrated: n/a (code execution was demonstrated, not merely a crash). The only element not reproduced in isolation is the unauthenticated injection of the code-editor block content into a content block; that is the companion IDOR CVE-2026-57630 (a separate, concurrently-disclosed CVE). The CVE-2026-57624 RCE primitive — unauthenticated eval() execution of the block content via the standard do_blocks path — is fully reproduced.

Root Cause

CodeEditor::__construct() registers the block with a render_callback that calls get_eval_content():

register_block_type('blocksy-companion-pro/code-editor', [
    'api_version' => 3,
    'render_callback' => function ($attributes, $content, $block) {
        // (vulnerable <=2.1.46: NO context guard here)
        if (! empty($content)) {
            $inline_code = str_replace('<pre class="wp-block-code"><code>', '',
                              str_replace('</code></pre>', '',
                                html_entity_decode(htmlspecialchars_decode($content))));
            return $this->get_eval_content($inline_code);
        }
        if (empty($attributes['code'])) return '';
        return $this->get_eval_content($attributes['code']);
    }
]);

get_eval_content() runs eval('?' . '>' . $inline_code . $ending) — i.e. it executes the block's innerHTML as PHP. Because there was no check on where the block was being rendered, the code ran in every rendering context, including the plain do_blocks() single-post rendering that an unauthenticated visitor triggers by requesting the content block's URL.

The fix (2.1.47, present in 2.1.48) inserts two guards at the top of the callback:

if (is_admin()) { return ''; }
if (empty($block->parsed_block['ct_allow_code_editor'])) { return ''; }

The ct_allow_code_editor flag is set only by CustomPostTypeRenderer::mark_code_editor_blocks() (in framework/premium/features/render-custom-post-type.php), which runs via the blocksy:block-parser:result filter during the legitimate Blocksy content-block renderer. The standard WordPress do_blocks() path used for a content block's own single-view URL does not apply that filter, so ct_allow_code_editor is absent there and the patched callback returns '' instead of eval()-ing. This matches the vendor changelog entries "Code editor block - restrict execution to explicit renderer context" and "Code Editor block - restrict post types for which it can be executed".

Why the REST block-renderer is NOT the vector

The WordPress core WP_REST_Block_Renderer_Controller::get_item_permissions_check() has required edit_posts (or edit_post for a supplied post_id) since WP 5.0; an unauthenticated caller receives HTTP 401 block_cannot_read. This was verified empirically on the deployed WordPress 7.0. Additionally the code-editor block registers no attributes schema, so the REST controller rejects a code attribute (rest_additional_properties_forbidden). The unauthenticated vector is therefore the do_blocks() single-view path, not the REST block-renderer.

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh (self-contained, idempotent).
2. What it does:
   1. Bundles the real Blocksy Companion Pro v2.1.48 plugin (GPL-mirror copy, pre-activated so the Premium/CodeEditor classes load without a license) and the free Blocksy theme.
   2. Builds two plugin zips from the same real code:
      • vulnerable — framework/premium/features/code-editor.php with the CVE-2026-57624 ct_allow_code_editor execution-context guard removed (restoring the <=2.1.46 render-callback state);
      • fixed — original 2.1.48 (guard present). A build-sanity grep confirms the guard is present in the fixed zip and absent in the vulnerable zip.
   3. Deploys a Docker stack: MariaDB + two wordpress:php8.2-apache (WordPress 7.0) instances — one with the vulnerable plugin, one with the fixed plugin — plus the Blocksy theme on each.
   4. Creates a published ct_content_block on each instance whose post_content is a blocksy-companion-pro/code-editor block whose PHP payload runs shell_exec("id; whoami; hostname; uname -a") and writes a marker file. (Setup step; in a real attack this block content is injected unauthenticated via the companion IDOR CVE-2026-57630.)
   5. Sends an unauthenticated HTTP GET (no cookies/credentials) to the content block's single-view URL on each instance.
   6. Verifies the marker file + command output on the vulnerable instance and confirms the fixed instance produces no marker and no code output.
   7. Writes bundle/repro/runtime_manifest.json.
3. Expected evidence of reproduction:
   • Vulnerable: marker file /tmp/rce_marker.txt written by www-data containing uid=33(www-data) ..., plus BLOCKSY_RCE_EXECUTED::uid=33(...) in the HTTP response body.
   • Fixed: NO_MARKER_FILE, zero BLOCKSY_RCE_EXECUTED occurrences in the response (the ct_allow_code_editor guard returns '').

Evidence

• bundle/logs/reproduction_steps.log — full run transcript (both passes).
• bundle/logs/vuln_marker.txt — command output captured from the vulnerable container:

  RCE_CONFIRMED
  CMD_OUTPUT:
  uid=33(www-data) gid=33(www-data) groups=33(www-data)
  www-data
  <container hostname>
  Linux <hostname> 7.0.14-arch1-1 ... x86_64 GNU/Linux
  

• bundle/logs/fixed_marker_check.txt — NO_MARKER_FILE (fixed build blocks).
• bundle/logs/code-editor-fix-diff.txt — unified diff of the exact guard reverted (if (empty($block->parsed_block['ct_allow_code_editor'])) { return ''; } removed).
• bundle/artifacts/http/vuln_response.html — HTTP body containing BLOCKSY_RCE_EXECUTED::uid=33(www-data) gid=33(www-data) groups=33(www-data).
• bundle/artifacts/http/fixed_response.html — HTTP body with zero BLOCKSY_RCE_EXECUTED occurrences.
• bundle/artifacts/code-editor.vuln.php / code-editor.fixed.php — the vulnerable and fixed CodeEditor source as deployed.
• bundle/repro/runtime_manifest.json — runtime evidence manifest (entrypoint_kind=api_remote, service_started=true, healthcheck_passed=true, target_path_reached=true).

Environment: Docker; mariadb:10.11; wordpress:php8.2-apache (WordPress 7.0); Blocksy theme 2.1.48; Blocksy Companion Pro 2.1.48 (vulnerable build = guard reverted; fixed build = original). The unauthenticated requests were issued from a separate container on the compose network (no WordPress auth cookies), i.e. a genuine logged-out HTTP client.

Recommendations / Next Steps

• Upgrade: Update Blocksy Companion Pro to 2.1.47 or later (the ct_allow_code_editor execution-context guard). The reproduction shows the patched build blocks the do_blocks execution path.
• Defense in depth: In addition to the context guard, treat the code-editor block as a high-risk primitive: restrict the ct_content_block post type to manage_options for create/edit (already the case), and consider disabling the code-editor block entirely on sites that do not need server-side PHP execution.
• WAF / mitigation: Block unauthenticated requests to /ct_content_block/<slug>/ and to admin-ajax.php actions blc_retrieve_popup_content / blc_retrieve_mega_menu_content when the content block contains a code-editor block, until all sites are patched.
• Companion IDOR: Also remediate CVE-2026-57630 (unauthenticated IDOR) which is the realistic unauthenticated injection path for the code-editor block content; the two CVEs combine into a single-request unauthenticated RCE on a vulnerable+unpatched-IDOR site.
• Testing: Add an automated test that renders a code-editor block via the standard do_blocks() path (not the ContentBlocksRenderer) and asserts the output is empty on patched builds.

Additional Notes

• Idempotency: The script tears down its compose stack (down -v) at start and rebuilds from the bundled artifacts, so it can be run repeatedly. It was executed twice consecutively; both runs ended with exit 0 and the same vulnerable/fixed differential.
• Vulnerable-source caveat: The vulnerable <=2.1.46 plugin build is not downloadable (the commercial Pro plugin is distributed only via freemius and GPL mirrors keep only the latest release). The reproduction therefore builds the vulnerable variant from the real 2.1.48 plugin by reverting the exact CVE-2026-57624 security guard (ct_allow_code_editor context check), which restores the pre-2.1.47 render-callback state. The eval() mechanism, block registration, attribute/innerHTML handling and get_eval_content() are all the unmodified vendor code; only the 2.1.47 guard is removed. The fixed variant (original 2.1.48) serves as the negative control.
• Licensing: The GPL-mirror 2.1.48 copy is pre-activated (Capabilities::get_plan() returns agency_v2 without a license), so the Premium/CodeEditor block registers and the blocksy-companion-pro/code-editor block is available without a valid freemius key — matching a real licensed deployment where an admin has activated Pro.
• Scope: The demonstrated surface is the unauthenticated do_blocks HTTP path (api_remote), matching the ticket's claimed_surface=api_remote. The attacker-controlled code injection itself is CVE-2026-57630 (separate), noted for completeness; the CVE-2026-57624 RCE primitive (unauthenticated eval execution) is fully reproduced and differentially validated against the patch.

A distinct alternate trigger for the CVE-2026-57624 eval() sink was found and empirically confirmed on the patched (fixed) build: an unauthenticated GET to a published page that embeds a Blocksy content block (via the [blocksy-content-block id=..] shortcode) — or any frontend render of a content block configured as a hook or inline popup — causes the blocksy-companion-pro/code-editor block's render_callback to execute eval() on the block content via get_eval_content(), with command execution as www-data. This path survives the 2.1.47+/2.1.48 fix because the fix's ct_allow_code_editor guard deliberately permits execution inside the legitimate ContentBlocksRenderer (the "explicit renderer context"), and is_admin() is false on a real frontend page load. This is intended post-fix behaviour per the vendor changelog ("restrict execution to explicit renderer context"), so it is NOT a standalone security bypass of CVE-2026-57624. It is, however, a residual unauthenticated eval-triggering surface that the fix does not cover; combined with the separate unauthenticated-injection CVE-2026-57630 (companion IDOR), unauthenticated RCE persists on patched builds. A second candidate — the unauthenticated, nonce-less AJAX endpoints blc_retrieve_popup_content / blc_retrieve_mega_menu_content — reaches the same sink via ContentBlocksRenderer but is blocked by the fix's is_admin() guard (admin-ajax ⇒ is_admin() true), so it is not a bypass. The original do_blocks single-view surface is correctly blocked by the fix (negative control re-confirmed).

Fix Coverage / Assumptions

• Invariant the fix relies on: the ct_allow_code_editor flag is set only inside CustomPostTypeRenderer::mark_code_editor_blocks() (via the self-removing blocksy:block-parser:result filter), which is reachable only through ContentBlocksRenderer (content-block rendering). Standard WP do_blocks() (e.g. a ct_content_block single-view) never sets the flag. The fix additionally assumes AJAX contexts are non-trusted and gates them with is_admin().
• Code paths the fix explicitly covers:
  1. do_blocks() single-view of a ct_content_block (the repro surface) → flag absent → guard B returns ''. Confirmed blocked (TEST2).
  2. AJAX-context rendering (admin-ajax.php nopriv popup/mega-menu endpoints) → is_admin() true → guard A returns ''. Confirmed blocked (TEST3).
  3. REST block renderer → already edit_posts-gated (not a vector).
• What the fix does NOT cover: frontend ContentBlocksRenderer rendering of content blocks (shortcode, hook, inline popup, inline mega-menu walker, single/archive templates). There is_admin() is false and the flag is set, so eval() runs. This is intended (the renderer is the explicit context the fix carves out as allowed) but it is an unauthenticated request path that reaches the sink.

Variant / Alternate Trigger

Primary alternate trigger (confirmed on FIXED): ContentBlocksRenderer frontend rendering of a content block containing a code-editor block.

• Entry point (unauthenticated): GET /<page-slug>/ where the page post_content contains [blocksy-content-block id=<CB>], or any frontend request that causes ContentBlocks::display_hooks() / render_popup() / the mega-menu walker to render a content block. No cookies/credentials.
• Code path: ContentBlocks shortcode (content-blocks.php) → is_hook_eligible_for_display($id, ['match_conditions'=>false]) → output_hook($id) → new ContentBlocksRenderer($id) → get_content() → CustomPostTypeRenderer::get_content() → parse_blocks_with_code_editor_mark() (sets ct_allow_code_editor=true on every blocksy-companion-pro/code-editor parsed block) → render_block($block) → CodeEditor render_callback → guard A (is_admin() false ⇒ pass) → guard B (flag set ⇒ pass) → get_eval_content($inline_code) → eval('?>'.$inline_code.$ending).
• Same sink as the parent CVE: Blocksy\CodeEditor::get_eval_content() in framework/premium/features/code-editor.php (line ~104/119).
• Equivalent frontend paths (same mechanism): inline popup (popups.php::render_popup → output_hook, load_content_with_ajax=no); hook content blocks (content-blocks.php::display_hooks → output_hook); inline mega-menu walker; single/archive content-block templates (templates.php line 169 new ContentBlocksRenderer).

Secondary candidate (blocked on FIXED — not a bypass): the unauthenticated nonce-less AJAX endpoints wp_ajax_nopriv_blc_retrieve_popup_content (popups.php:44) and wp_ajax_nopriv_blc_retrieve_mega_menu_content (mega-menu/includes/api.php:17). Both call ContentBlocksRenderer (flag set) but run under admin-ajax.php ⇒ is_admin() true ⇒ guard A blocks. Confirmed blocked on both builds (TEST3). On a hypothetical fully-vulnerable <=2.1.46 with both guards absent these would be additional unauthenticated alternate triggers; that older commercial build is not downloadable, so it could not be tested directly.

Negative control (re-confirmed): do_blocks single-view (GET /ct_content_block/<slug>/) — blocked on FIXED (guard B), executes on vuln (TEST2).

• Package/component affected: blocksy-companion-pro plugin, Blocksy\CodeEditor (framework/premium/features/code-editor.php), reachable via Blocksy\ContentBlocksRenderer (framework/premium/features/content-blocks/renderer.php + content-blocks.php + content-blocks/popups.php).
• Affected versions (as tested): Blocksy Companion Pro 2.1.48 (fixed build = original; vulnerable build = 2.1.48 with the ct_allow_code_editor guard reverted). Blocksy theme 2.1.48. WordPress 7.0. The alternate trigger reproduces on the fixed 2.1.48 build.
• Risk level: Critical when combined with CVE-2026-57630. In isolation the alternate trigger is intended behaviour (admin-authored code executed for visitors). The exploitable impact (unauthenticated attacker-controlled code) requires the separate IDOR for content injection.
• Consequences: unauthenticated remote PHP/command execution as www-data (demonstrated: uid=33(www-data)), when an attacker can place a code-editor block in a content block (via 57630) rendered as a popup/hook/shortcode.

Impact Parity

• Disclosed/claimed maximum impact (parent CVE): Unauthenticated Remote Code Execution (Patchstack: "Required privilege: Unauthenticated", CVSS 10.0, CWE-94).
• Reproduced impact from this variant run: Unauthenticated command execution (shell_exec("id; whoami; hostname") → uid=33(www-data), www-data, container hostname) on the fixed/patched build via an unauthenticated GET to a page embedding a content block (TEST1). The command output appears in the HTTP body (BLOCKSY_VARIANT_RCE::uid=33(...)) and is persisted to /tmp/rce_marker_variant.txt by www-data.
• Parity: partial. The unauthenticated eval-execution primitive is reproduced on the patched build via a different entry point, achieving the same code-execution impact. The attacker content control (placing the code-editor block) is not reproduced here in isolation — it depends on the separate CVE-2026-57630 IDOR, which is out of scope for this variant stage. Therefore parity is partial (execution primitive: full; end-to-end unauthenticated injection: not demonstrated, depends on 57630).
• Not demonstrated: unauthenticated injection of the code-editor block content (that is CVE-2026-57630). The variant stage demonstrates the execution surface that survives the 57624 fix.

Root Cause

The same underlying bug — get_eval_content() running eval() on the code-editor block's innerHTML/code attribute — is still reachable because the fix chose to allow execution inside ContentBlocksRenderer (the explicit renderer context). The fix's guard B (empty($block->parsed_block['ct_allow_code_editor'])) is satisfied on the frontend ContentBlocksRenderer path (the flag is set by mark_code_editor_blocks()), and guard A (is_admin()) is not satisfied (is_admin() is false for a real frontend page load). Consequently every frontend content-block render that flows through ContentBlocksRenderer executes any code-editor block it contains — including renders triggered by unauthenticated visitors. The fix closes the do_blocks single-view path (flag never set there) and the AJAX path (is_admin() true), but not the frontend ContentBlocksRenderer path, because closing it would disable the code-editor block's documented feature.

No fix commit SHA is available (the plugin is distributed as a commercial freemius/GPL-mirror zip, not a public VCS). The fixed reference is Blocksy Companion Pro 2.1.48 (blocksy-companion-pro-v2.1.48.zip, sha256 df44244019dcc7f0fd93ac039dacfc1b8caf821b8f8839b8efef94e47d34062a); in-container fixed code-editor.php sha256 7e5ccb97ab2559f8583cd97be5df1e87a64493f87a6a7e8822e54c9b3e0a8c2b.

Reproduction Steps

1. Script: bundle/vuln_variant/reproduction_steps.sh (self-contained, idempotent; reuses the running repro Docker stack if present, otherwise deploys its own blocksycvevar stack with vulnerable + fixed builds).
2. What it does:
   1. Ensures a vulnerable build (2.1.48 with guard B reverted) and a fixed build (original 2.1.48) of Blocksy Companion Pro are running on WordPress 7.0 + Blocksy theme 2.1.48, each in its own container.
   2. Runs bundle/vuln_variant/setup_variant.php (idempotent) in each container to create: a ct_content_block containing a code-editor block whose payload runs shell_exec("id; whoami; hostname") and writes /tmp/rce_marker_variant.txt; a published page embedding it via [blocksy-content-block id=..]; a popup content block (template_type=popup, load_content_with_ajax=yes); and a ct_content_block for the single-view test.
   3. Sends unauthenticated requests for three paths on both builds:
      • TEST1 GET /<shortcode-page>/ (ContentBlocksRenderer frontend)
      • TEST2 GET /ct_content_block/<slug>/ (do_blocks single-view)
      • TEST3 POST /wp-admin/admin-ajax.php action=blc_retrieve_popup_content (nopriv AJAX)
   4. Checks the marker file + BLOCKSY_VARIANT_RCE in each HTTP response and prints the differential matrix. Writes bundle/vuln_variant/runtime_manifest.json.
3. Expected evidence:
   • TEST1: marker written + BLOCKSY_VARIANT_RCE::uid=33(www-data)... in the response on both builds (alternate trigger survives the fix).
   • TEST2: marker on vuln only; no marker on fixed (fix blocks single-view).
   • TEST3: no marker on either build (is_admin() guard blocks AJAX).
   • Exit 0 when TEST1_fixed=executed ∧ TEST2_fixed=blocked ∧ TEST3_fixed=blocked (the fix boundary is characterised).

Evidence

• bundle/logs/vuln_variant/reproduction_steps.log — full transcript (both verification runs).
• bundle/logs/vuln_variant/t1_fixed_marker.txt — FIXED TEST1 marker:

  VARIANT_RCE_CONFIRMED
  CMD_OUTPUT:
  uid=33(www-data) gid=33(www-data) groups=33(www-data)
  www-data
  7737f7e10e48
  

  (proof: eval() executed on the patched build via an unauthenticated page load through ContentBlocksRenderer).
• bundle/logs/vuln_variant/t1_vuln_marker.txt — vuln TEST1 marker (same).
• bundle/logs/vuln_variant/t2_fixed_marker.txt — NO_MARKER (fix blocks single-view on FIXED).
• bundle/logs/vuln_variant/t2_vuln_marker.txt — marker present (vuln single-view executes).
• bundle/logs/vuln_variant/t3_fixed_marker.txt / t3_vuln_marker.txt — NO_MARKER on both (is_admin() guard blocks AJAX popup rendering).
• bundle/vuln_variant/http/fixed_shortcode_page.html — contains BLOCKSY_VARIANT_RCE::uid=33(www-data) gid=33(www-data) groups=33(www-data).
• bundle/vuln_variant/http/fixed_singleview.html — zero BLOCKSY_VARIANT_RCE occurrences.
• bundle/vuln_variant/http/fixed_popup_ajax.json / vuln_popup_ajax.json — zero BLOCKSY_VARIANT_RCE occurrences.
• bundle/vuln_variant/http/vuln_singleview.html / vuln_shortcode_page.html — contain BLOCKSY_VARIANT_RCE::....
• bundle/vuln_variant/runtime_manifest.json — structured runtime evidence (entrypoint_kind=api_remote, target_path_reached=true, full test matrix, fixed_version_alternate_trigger_confirmed=true, bypass_in_isolation=false, classification=alternate_trigger_on_fixed_intended_behaviour).

Environment: Docker; mariadb:10.11; wordpress:php8.2-apache (WordPress 7.0); Blocksy theme 2.1.48; Blocksy Companion Pro 2.1.48 (fixed = original; vulnerable = guard B reverted). Unauthenticated requests issued from the host to the container IPs (no WordPress auth cookies).

Recommendations / Next Steps

The 57624 fix is sound for its stated scope but does not, by itself, remediate the unauthenticated-RCE impact because the frontend ContentBlocksRenderer path remains an unauthenticated eval-triggering surface. To close the gap:

1. Remediate CVE-2026-57630 (companion IDOR) — the realistic unauthenticated injection path for code-editor block content. Without it, an attacker cannot place the code-editor block, so the residual surface is not attacker-reachable.
2. Defence-in-depth at the eval boundary: in addition to the context guard, re-check authoring capability at eval time — e.g. only execute a code-editor block when the owning content block was last edited by a user who still holds manage_options / the custom_post_type capability, or gate the whole ct_content_block post type's code-editor execution behind an explicit, audit-logged opt-in. This prevents an IDOR-injected (or formerly-privileged-then-revoked) code-editor block from executing even via the legitimate renderer.
3. Consider disabling the code-editor block in content blocks by default on sites that do not need server-side PHP execution, exposing it only as an explicit, high-privilege feature.
4. Add an automated test that asserts a code-editor block inside a content block rendered through ContentBlocksRenderer on the frontend executes only when the authoring capability check passes — and that an IDOR-equivalent injection (content block authored by a disallowed actor) does not execute.
5. WAF / interim mitigation: block unauthenticated requests to /ct_content_block/<slug>/ and to admin-ajax.php actions blc_retrieve_popup_content / blc_retrieve_mega_menu_content when the referenced content block contains a code-editor block, until both 57624 and 57630 are patched site-wide.

Additional Notes

• Idempotency: reproduction_steps.sh was executed twice consecutively; both runs ended with exit 0 and the identical differential matrix (TEST1: vuln=1 fixed=1, TEST2: vuln=1 fixed=0, TEST3: vuln=0 fixed=0). setup_variant.php deletes prior variant posts by title before recreating them, so the script can be re-run safely.
• Classification honesty: the fixed-version execution (TEST1) is intended behaviour per the vendor's documented fix design. It is recorded as a confirmed alternate trigger that survives the fix, not as a standalone security bypass of CVE-2026-57624. The exploitable residual risk is gated by the separate CVE-2026-57630 (IDOR), which is the realistic unauthenticated injection path and is out of scope for this variant stage.
• Limitation: the real <=2.1.46 commercial build is not downloadable, so the differential vulnerable build was constructed by reverting guard B from the real 2.1.48 (guard A retained). A fully-vulnerable build with both guards absent would additionally expose the popup/mega-menu nopriv AJAX endpoints as unauthenticated alternate triggers; this could not be tested directly.
• No other eval sinks: the only eval() of attacker-influenced block content is get_eval_content(). The qubely.php eval() is a fixed class string. The "Custom Code Snippets" extension is a separate admin-gated feature (out of 57624 scope). No register_rest_route renders content blocks.