Patchstack has disclosed that a maximum-severity vulnerability in the Bricksforge plugin for WordPress is being actively exploited in the wild. CVE-2026-85097 carries a CVSS score of 10.0 — the highest possible rating — because it requires no authentication, no user interaction, and no special conditions: any remote attacker who can reach a vulnerable WordPress site can upload and execute arbitrary PHP code on it.
Let me be blunt, because I've worked enough WordPress IR engagements to know how this plays out: an unauthenticated remote code execution flaw in a WordPress plugin is not a "patch when convenient" problem. It is a "patch tonight or rebuild the server next week" problem. The gap between public disclosure and mass exploitation of WordPress plugin bugs is now measured in hours, and Patchstack confirms exploitation is already underway. If you run Bricks Builder with the Bricksforge addon, you should treat your site as potentially compromised until you have patched AND hunted for webshells.
Technical Analysis
Affected Component
- Product: Bricksforge plugin for WordPress (an addon extending the Bricks Builder theme/page builder)
- Platform: Any WordPress installation with the vulnerable Bricksforge plugin version active
- CVE: CVE-2026-85097
- CVSS Score: 10.0 (Critical) — network-exploitable, unauthenticated, no user interaction
- Disclosure source: Patchstack
Bricksforge is a popular addon in the Bricks Builder ecosystem, used by agencies and freelancers to extend Bricks with additional elements, form handlers, and backend tooling. Its position in the stack matters: Bricks-based sites are frequently marketing sites and client portals sitting on shared or lightly-managed hosting, which means weak segmentation, no EDR on the host, and often nobody watching logs at all. That is precisely the population attackers target first.
How the Vulnerability Works
From a defender's perspective, the attack chain for this class of flaw is well understood:
- Unauthenticated request to an exposed endpoint. The plugin exposes a handler (typically via
admin-ajax.php, the REST API at/wp-json/, or a direct plugin file under/wp-content/plugins/bricksforge/) that fails to properly authenticate the caller or validate the requested action. - Arbitrary file upload. The endpoint accepts an attacker-controlled file upload without enforcing extension, MIME-type, or content validation — allowing a
.phpfile (or a polyglot disguised as an image) to be written to a web-accessible directory, commonly under/wp-content/uploads/. - Webshell execution. The attacker then issues an HTTP request directly to the uploaded PHP file, achieving arbitrary code execution as the web server user (
www-data,apache, or nginx worker). From there: credential theft fromwp-config.php, database dumping, lateral movement into the hosting account, SEO spam injection, and staging for follow-on payloads.
The exploitation requirements are zero. No valid WordPress account, no nonce, no prior access. This is why CVSS 10.0 is appropriate and why the exploitation timeline is so compressed.
Exploitation Status
- Active in-the-wild exploitation: Confirmed by Patchstack.
- Attacker tradecraft to expect: Mass scanning for sites with the plugin fingerprinted, automated upload of webshells (often randomized filenames in uploads directories), followed by batch credential harvesting and, in monetized campaigns, resale of access to ransomware affiliates. On WordPress hosts I've investigated, initial webshell placement frequently precedes visible impact by days or weeks — access brokers sit on the foothold.
Assume scanning is global and automated. Being a small site provides no protection; the scanners do not discriminate.
Detection & Response
The highest-fidelity detection surface for this threat is the gap between what a web server should do (serve PHP from plugin/theme directories) and what exploitation looks like (a PHP file appearing in an uploads directory and then being executed, or php-fpm/apache spawning shell commands). Hunt on both.
---
title: PHP File Written to WordPress Uploads Directory
id: 1c9a4f27-8b3e-4d5a-9f12-7e6c0a1b2d34
status: experimental
description: Detects creation of PHP files in WordPress uploads directories, a hallmark of webshell deployment via arbitrary file upload flaws such as CVE-2026-85097 (Bricksforge).
references:
- https://thehackernews.com/2026/10/attackers-exploit-cvss-100-bricksforge.html
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/10/09
tags:
- attack.persistence
- attack.t1505.003
logsource:
product: linux
service: auditd
detection:
selection_path:
- '/wp-content/uploads/'
selection_ext:
- '.php'
- '.phtml'
- '.phar'
- '.php5'
- '.php7'
condition: selection_path and selection_ext
falsepositives:
- Rare legitimate plugin operations that cache compiled templates in uploads (verify against known plugin behavior)
level: critical
---
title: Web Server Process Spawning Shell or Command Tools
id: 4e7d2b91-6f38-4c1a-b824-9d3f5e6a7c08
status: experimental
description: Detects PHP-FPM, Apache, or Nginx worker processes spawning interactive shells or command execution tools, consistent with post-exploitation activity following webshell deployment via CVE-2026-85097.
references:
- https://thehackernews.com/2026/10/attackers-exploit-cvss-100-bricksforge.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/09
tags:
- attack.execution
- attack.t1059.004
- attack.t1505.003
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/php-fpm'
- '/php-fpm8.1'
- '/php-fpm8.2'
- '/php-fpm8.3'
- '/apache2'
- '/httpd'
- '/nginx'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/python'
- '/python3'
- '/perl'
- '/base64'
condition: selection_parent and selection_child
falsepositives:
- Legitimate WordPress plugins invoking system commands (image processing, backups) — baseline your environment and allowlist known plugin wrappers
level: high
---
title: Suspicious Unauthenticated Requests to Bricksforge Plugin Endpoints
id: 8a2c6e14-3d91-4b7f-a653-1f9e2c5b8d46
status: experimental
description: Detects inbound HTTP requests directly targeting Bricksforge plugin paths or WordPress AJAX handlers with upload-like parameters, indicative of exploitation attempts against CVE-2026-85097.
references:
- https://thehackernews.com/2026/10/attackers-exploit-cvss-100-bricksforge.html
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/10/09
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_uri:
cs-uri|contains:
- '/wp-content/plugins/bricksforge/'
- 'admin-ajax.php'
- '/wp-json/bricksforge'
selection_method:
cs-method: 'POST'
filter_known:
cs-referer|contains:
- '/wp-admin/'
condition: selection_uri and selection_method and not filter_known
falsepositives:
- Legitimate front-end AJAX actions from the plugin; tune by correlating with file creation events and uploaded content-type headers
level: high
// Hunt for webshell placement and web server command execution following
// CVE-2026-85097 exploitation. Assumes Syslog/CEF ingestion from web hosts
// and/or Defender for Endpoint on Linux servers into Sentinel.
// 1) PHP files created under WordPress uploads directories (Syslog file events / auditd)
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_all ("wp-content/uploads", ".php")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;
// 2) Web server processes spawning shells or downloaders (Defender for Endpoint on Linux)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ ("php-fpm", "apache2", "httpd", "nginx", "php-fpm8.2", "php-fpm8.3")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python3", "perl", "base64")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;
// 3) Inbound POST requests to Bricksforge plugin paths (WAF/IIS/nginx logs via CEF)
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where RequestMethod == "POST"
| where RequestURL has_any ("bricksforge", "admin-ajax.php")
| summarize RequestCount = count(), DistinctSources = dcount(SourceIP) by RequestURL, DestinationHostName, bin(TimeGenerated, 1h)
| where RequestCount > 50
| order by RequestCount desc
-- Hunt for webshells and post-exploitation artifacts on WordPress hosts
-- suspected of CVE-2026-85097 compromise.
-- 1) Recently created PHP files in uploads directories (last 30 days)
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs='/var/www/**/wp-content/uploads/**/*.php')
WHERE Mtime > now() - (30 * 24 * 3600)
ORDER BY Mtime DESC
-- 2) Web server user processes running shells or network tools
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Username =~ 'www-data|apache|nginx'
AND CommandLine =~ 'bash|/bin/sh|curl |wget |nc |python|perl |base64'
-- 3) Established outbound connections from web server processes (C2 or payload fetch)
SELECT Pid, Name, Status, Family, LocalAddr, LocalPort, RemoteAddr, RemotePort
FROM netstat()
WHERE Status =~ 'ESTAB'
AND Name =~ 'php-fpm|apache2|httpd|nginx|bash|sh$|curl|wget'
AND RemoteAddr !~ '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|127\.)'
Remediation
Immediate actions (do these today, in this order):
- Update Bricksforge to the patched version released by the vendor. Check the Patchstack advisory and the Bricksforge changelog for the fixed release number, and update via the WordPress admin dashboard or WP-CLI. If auto-updates are not enabled for this plugin, enable them now.
- If you cannot patch immediately, deactivate and disable the Bricksforge plugin entirely. For an unauthenticated CVSS 10.0 under active exploitation, a disabled plugin is the only reliable workaround. WAF rules reduce but do not eliminate risk against an incompletely understood endpoint surface.
- Hunt before you trust. Patching does not remove webshells that were dropped pre-patch. Run the VQL artifact above (or the manual bash checks below) against every host that ran a vulnerable version, and review access logs for POSTs to plugin endpoints in the days preceding disclosure.
- Rotate credentials on any host where a webshell is found: WordPress salts and keys in
wp-config.php, the database password, admin accounts, FTP/SFTP credentials, and any API keys stored in the database or plugin settings. Webshell access equalswp-config.phpaccess equals your database. - Block PHP execution in uploads directories at the web server level as a durable hardening measure (this breaks webshell deployment via this entire class of plugin bug, not just this CVE).
#!/bin/bash
# CVE-2026-85097 — Bricksforge verify/harden script for Linux WordPress hosts
# Run as root or with sudo on each affected host.
WP_ROOT="/var/www/html" # adjust per site; loop if multi-site hosting
# 1) Check Bricksforge version and deactivate if unpatched
sudo -u www-data wp plugin list --path="$WP_ROOT" --format=table | grep -i bricksforge
# If the installed version predates the patched release from the Patchstack advisory:
# sudo -u www-data wp plugin update bricksforge --path="$WP_ROOT"
# Emergency only, if no patch is available:
# sudo -u www-data wp plugin deactivate bricksforge --path="$WP_ROOT"
# 2) Hunt for PHP files dropped into uploads (webshell indicator)
find "$WP_ROOT/wp-content/uploads" -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) \
-mtime -30 -printf '%T@ %Tc %p\n' | sort -nr
# 3) Grep access logs for suspicious POSTs to plugin endpoints
grep -hE 'POST .*(bricksforge|admin-ajax\.php)' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
| awk '{print $1}' | sort | uniq -c | sort -nr | head -20
# 4) Harden: deny PHP execution in uploads (nginx)
cat > /etc/nginx/conf.d/wp-uploads-hardening.conf <<'EOF'
location ~* /wp-content/uploads/.*\.php$ {
deny all;
return 403;
}
EOF
nginx -t && systemctl reload nginx
# 4-alt) Harden for Apache: drop this into wp-content/uploads/.htaccess
cat > "$WP_ROOT/wp-content/uploads/.htaccess" <<'EOF'
<FilesMatch "\.(php|phtml|phar|php5|php7)$">
Require all denied
</FilesMatch>
EOF
# 5) Audit admin users and recently modified core files
sudo -u www-data wp user list --role=administrator --path="$WP_ROOT"
find "$WP_ROOT" -maxdepth 2 -name "*.php" -mtime -14 -printf '%Tc %p\n' | sort -r | head -40
Strategic hardening: Enroll all WordPress properties in a managed WAF/virtual patching service (Patchstack, Wordfence, or your CDN's managed ruleset), enforce automatic plugin updates, restrict write permissions on plugin directories, segment hosting accounts so one compromised site cannot reach others, and forward web/auth/audit logs to your SIEM so the KQL hunts above actually have telemetry to work with. The pattern of critical WordPress plugin RCEs in 2025–2026 is not slowing down — treat plugin inventory and patch latency as board-level vulnerability management metrics, not an afterthought for the web team.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.