Blocksy Companion 2.1.46 Critical Code Execution Flaw — WordPress Detection and Remediation Guide

A critical code execution vulnerability has been disclosed in Blocksy Companion version 2.1.46, the companion plugin for the popular Blocksy WordPress theme. A public exploit has been published on Exploit-DB (exploit ID 52640), which means working attack code is now available to every opportunistic scanner on the internet. If you run Blocksy on any WordPress property — production blog, marketing site, e-commerce front end — treat this as an active emergency, not a backlog ticket.

In my experience responding to WordPress plugin compromises, the window between public exploit publication and mass automated scanning is measured in hours, not days. Attackers do not need to be sophisticated here: the exploit is published, the attack surface is enormous (Blocksy is one of the most widely deployed WordPress themes), and the payoff — arbitrary code execution in the web server context — is the worst-case outcome for a CMS vulnerability.

Why Defenders Must Act Immediately

Three factors make this urgent:

1. Public exploit code exists. This is not a theoretical CVE with a proof-of-concept locked behind a researcher embargo. Attack tooling is in the wild.
2. Code execution in the PHP/web server context means an attacker can drop webshells, read wp-config.php (which contains your database credentials), pivot to the database, and establish persistence that survives a plugin update.
3. WordPress sites are frequently under-monitored. Many organizations treat their CMS as a marketing asset, not a production system. There is often no EDR on the web server, no file integrity monitoring on the webroot, and no centralized web access log collection. That is exactly the blind spot attackers count on.

Technical Analysis

Affected Product and Versions

How the Attack Works (Defender's View)

Based on the public exploit disclosure, the attack chain follows the classic WordPress plugin RCE pattern:

1. Reconnaissance: The attacker enumerates the plugin, typically by requesting /wp-content/plugins/blocksy-companion/readme.txt or fingerprinting Blocksy theme assets in page source.
2. Trigger: A crafted HTTP request is sent to a vulnerable plugin endpoint — commonly an AJAX action (/wp-admin/admin-ajax.php), a REST API route under /wp-json/, or a directly accessible PHP file within the plugin directory. The vulnerable code path fails to properly validate or sanitize attacker-controlled input before it reaches a dangerous sink (file write, eval-adjacent behavior, unsafe include, or unprotected callable).
3. Execution: The attacker achieves PHP code execution as the web server user (www-data, apache, or nginx depending on the stack). Typical follow-on actions include:
   • Writing a webshell into the webroot or uploads directory (e.g., /wp-content/uploads/<random>.php)
   • Reading wp-config.php to harvest database credentials
   • Creating a rogue administrator account in wp_users
   • Injecting malicious PHP into legitimate theme or plugin files for persistence
4. Persistence: Webshells and modified core files survive the plugin patch. Updating the plugin does not evict an attacker who has already landed.

Observable Indicators

The behaviors that matter for detection, regardless of the exact exploit payload:

• HTTP POST/GET requests to Blocksy Companion plugin paths (/wp-content/plugins/blocksy-companion/) with unusual parameters or encoded payloads
• New or modified .php files appearing in /wp-content/uploads/ — a directory that should never legitimately contain executable PHP
• The web server process (php-fpm, apache2, nginx worker children) spawning shell processes (/bin/sh, /bin/bash, curl, wget, base64)
• Outbound connections from the web server to unfamiliar hosts (webshell command-and-control or payload staging)
• Unexpected administrator accounts or modified functions.php files in the active theme

Detection & Hunting

The following detections are built around the concrete post-exploitation behaviors of a WordPress plugin RCE. Tune the paths to your document root before deployment.

Sigma Rules

---
title: Web Server Process Spawning Shell - Possible WordPress Plugin RCE
id: 3f8c1a2e-9b4d-4e7a-b2c1-5d6e7f8a9b0c
status: experimental
description: Detects the PHP-FPM, Apache, or Nginx process spawning a shell or command interpreter, consistent with post-exploitation of a web application RCE such as the Blocksy Companion 2.1.46 code execution flaw.
references:
  - https://www.exploit-db.com/exploits/52640
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php8.1-fpm'
      - '/php8.2-fpm'
      - '/php8.3-fpm'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/base64'
      - '/python'
      - '/python3'
      - '/perl'
  condition: selection_parent and selection_child
falsepositives:
  - WordPress plugins invoking system commands for image processing or backups (review command lines)
level: high
---
title: PHP File Written to WordPress Uploads Directory
id: 8a2d4f6b-1c3e-4a5b-9d7c-2e4f6a8b0c1d
status: experimental
description: Detects creation of PHP files in the WordPress uploads directory, a classic webshell staging location following plugin exploitation such as Blocksy Companion RCE. The uploads directory should never contain executable PHP.
references:
  - https://www.exploit-db.com/exploits/52640
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains: '/wp-content/uploads/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.php5'
      - '.php7'
      - '.phar'
  condition: selection_path and selection_ext
falsepositives:
  - Rare legitimate plugin behavior; any hit should be investigated
level: critical
---
title: Suspicious Requests to Blocksy Companion Plugin Endpoints
id: 5c7e9a1b-3d5f-4b6a-8c0d-1e3f5a7b9c2e
status: experimental
description: Detects HTTP requests containing encoded or suspicious payloads directed at Blocksy Companion plugin paths or WordPress AJAX endpoints, indicating exploitation attempts against the Blocksy Companion code execution flaw.
references:
  - https://www.exploit-db.com/exploits/52640
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/wp-content/plugins/blocksy-companion/'
      - 'admin-ajax.php'
  selection_payload:
    cs-uri-query|contains:
      - 'base64_decode'
      - 'eval('
      - 'system('
      - 'shell_exec'
      - 'passthru'
      - 'cmd='
      - '%3C%3Fphp'
  condition: selection_uri and selection_payload
falsepositives:
  - None expected in production; encoded PHP function names in query strings are highly anomalous
level: high

KQL — Microsoft Sentinel / Defender

This query hunts web access logs (ingested via IIS, Apache/Nginx syslog, or a WAF connector) for exploitation attempts against the Blocksy Companion plugin, plus post-exploitation process execution from web server workers if your Linux hosts forward auditd/Sysmon-for-Linux telemetry.

// Hunt 1: Exploitation attempts against Blocksy Companion plugin endpoints
let lookback = 14d;
union isfuzzy=true
    (CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where RequestURL has_any ("blocksy-companion", "admin-ajax.php")
    | where RequestURL has_any ("base64", "eval(", "system(", "shell_exec", "passthru", "cmd=", "%3C%3Fphp")
    | project TimeGenerated, SourceIP, RequestURL, RequestMethod, DeviceAction, SentBytes, ReceivedBytes),
    (Syslog
    | where TimeGenerated > ago(lookback)
    | where SyslogMessage has "blocksy-companion"
    | where SyslogMessage has_any ("base64", "eval(", "system(", "cmd=", "<?php")
    | project TimeGenerated, HostIP, SyslogMessage)
);
// Hunt 2: Web server worker spawning a shell (post-exploitation behavior)
// Requires Sysmon for Linux, auditd, or Defender for Endpoint on the web host
DeviceProcessEvents
| where TimeGenerated > ago(lookback)
| where InitiatingProcessFileName has_any ("php-fpm", "apache2", "httpd", "nginx")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "base64", "python3", "perl")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

Velociraptor VQL — Endpoint Hunt

Deploy this hunt across your WordPress web hosts to surface webshells in the uploads tree and suspicious child processes of the web server.

-- Blocksy Companion RCE post-exploitation hunt
-- 1) Find PHP files in the WordPress uploads directory (webshell staging)
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs='/var/www/**/wp-content/uploads/**/*.php')
ORDER BY Mtime DESC

-- 2) Identify shells spawned by the web server process
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(/bin/sh|/bin/bash|base64|curl |wget )'
  AND Username =~ '(?i)(www-data|apache|nginx)'

-- 3) Check listening connections established by web server processes
SELECT Pid, Name, RemoteAddr, RemotePort, Status
FROM netstat()
WHERE Name =~ '(?i)(php|apache|httpd|nginx|sh|bash)'
  AND RemoteAddr !~ '^(127\\.|10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)'

Remediation and Verification Script

Run this on each WordPress host to identify the installed Blocksy Companion version, scan for webshell indicators, and check for rogue administrator accounts (the WP-CLI portions require WP-CLI installed and run as the site owner).

#!/bin/bash
# Blocksy Companion 2.1.46 RCE - Triage and Verification Script
# Run as root or with sudo on the WordPress host.

WEBROOT="/var/www/html"   # Adjust to your document root

echo "=== [1] Blocksy Companion installed version ==="
find "$WEBROOT" -type d -name "blocksy-companion" 2>/dev/null | while read -r dir; do
  echo "Found plugin: $dir"
  grep -i "Version:" "$dir/blocksy-companion.php" 2>/dev/null
done

echo "=== [2] PHP files in uploads directory (webshell check) ==="
find "$WEBROOT" -path "*/wp-content/uploads/*" -name "*.php" -mtime -30 -ls 2>/dev/null

echo "=== [3] Recently modified PHP files across the webroot (last 7 days) ==="
find "$WEBROOT" -name "*.php" -mtime -7 -type f -ls 2>/dev/null | sort -k11

echo "=== [4] Common webshell signatures in recently changed files ==="
grep -rlE "(eval\s*\(\s*base64_decode|shell_exec|passthru|assert\s*\(\s*\$_|preg_replace\s*\(.*/e)" \
  "$WEBROOT" --include="*.php" -m1 2>/dev/null | head -50

echo "=== [5] Access log hits against blocksy-companion paths (last 1000 lines) ==="
tail -1000 /var/log/apache2/access.log /var/log/nginx/access.log 2>/dev/null | \
  grep -iE "blocksy-companion|admin-ajax" | grep -iE "base64|eval|system\(|cmd=|%3C%3Fphp"

echo "=== [6] WordPress administrator accounts (verify all are known) ==="
cd "$WEBROOT" && sudo -u www-data wp user list --role=administrator --fields=user_login,user_email,user_registered 2>/dev/null

echo "=== [7] Shell processes spawned by web server user (current) ==="
ps -eo user,pid,ppid,cmd | grep -E "^www-data|^_www|^apache|^nginx" | grep -E "sh|bash|curl|wget|python|perl"

echo "=== Triage complete. Review output before updating. ==="

Remediation Steps

1. Patch Immediately — and Verify the Patch Actually Applied

• Update Blocksy Companion to the latest release via Dashboard → Updates or WP-CLI: wp plugin update blocksy-companion. Check the vendor changelog and the WordPress.org plugin page for the fixed version number — if no patched release exists yet, deactivate the plugin until one ships. A broken layout is cheaper than a compromised server.
• Do not trust the version string in the dashboard alone if the site may already be compromised — an attacker with code execution can falsify it. Verify plugin file integrity against a clean copy: wp plugin verify-checksums blocksy-companion (where supported) or diff against a fresh download.

2. Assume Compromise if You Were Exposed

If version 2.1.46 was installed and internet-reachable after the exploit publication date, run the triage script above and treat any positive finding as an incident:

• Audit wp_users for unauthorized administrator accounts.
• Rotate all credentials in wp-config.php (database password, auth keys/salts) and any API keys stored in the database or plugin settings.
• Review outbound firewall logs from the web host for the exposure window.
• If a webshell is confirmed, rebuild from a known-clean backup rather than attempting surgical cleanup — persistence mechanisms in WordPress (modified functions.php, malicious cron entries in wp_options, mu-plugins) are easy to miss.

3. Harden the WordPress Attack Surface

• Block PHP execution in uploads. Add to the uploads .htaccess or Nginx config: deny execution of *.php under /wp-content/uploads/.
• Deploy or tune a WAF (ModSecurity with OWASP CRS, Cloudflare, or equivalent) with rules blocking PHP function names and encoded payloads in request parameters.
• Enforce least privilege on the web server user — www-data should have read-only access to core/theme/plugin files, with write access limited to uploads.
• Restrict admin-ajax.php and REST API exposure where business logic allows, and put /wp-admin behind IP allowlisting or SSO.
• Centralize web access logs into your SIEM. If your WordPress logs live only on the box, you are blind.

4. Fix the Process Problem

This disclosure is a symptom of the recurring WordPress plugin risk pattern: third-party code with full PHP privileges, auto-installed by marketing teams, rarely inventoried, and inconsistently patched. Every CMS plugin belongs in your vulnerability management program with a defined patch SLA — critical plugin vulnerabilities with public exploits warrant a 24-hour patch window, not a monthly cycle.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub