Loading vulnerability…
CVE-2026-85097 is an unauthenticated arbitrary file upload vulnerability in the Pro Forms module of the Bricksforge WordPress plugin through version 3.1.8.9. During form submission, insufficient validation of the attacker-controlled url field in temporaryFileUploads allows previously validated image content to be saved as executable PHP. An attacker can obtain a valid nonce through the publicly accessible bricksforge_regenerate_nonce AJAX action, upload a GIF/PHP polyglot that passes initial MIME-type validation, and submit metadata pairing the validated image's server-side path with a PHP destination URL. Requesting the resulting file executes the embedded PHP code. Exploitation attempts have been observed since October 7, 2026.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
5 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
The repository contains README.md (58 bytes) and poc.py (33,472 bytes). The README provides a FOFA plugin fingerprint. The standalone Python script includes an embedded PHP web shell, PNG/GIF polyglot construction, a command-line entry point, and concurrent multi-target scheduling using ThreadPoolExecutor. It uses requests and disables urllib3 insecure-request warnings; the visible excerpt does not establish whether all requests disable TLS verification. The script claims CVE-2026-85097 affects Bricksforge <= 3.1.8.9 and is fixed in 4.0.0. Its documented chain obtains a nonce through an unauthenticated AJAX action, uploads an image/PHP polyglot, then submits a temporaryFileUploads object containing the uploaded server path and a chosen .php filename. The alleged flaw is trusting client-supplied file metadata and deriving the destination filename from the supplied URL without adequate path/name validation. If the uploads directory executes PHP, the resulting shell provides command execution through the c parameter. The visible ending supports single-target command execution and multi-target result reporting. Comments also mention remote-payload verification through HTML titles, but that implementation is not available. No fixed attacker-controlled host, callback IP, or exfiltration destination appears in the excerpt. This is an active exploitation tool rather than a passive detector, and successful runs may leave a server-side shell. The source is substantially truncated, so request handling, identifier discovery, output writers, and end-to-end reliability cannot be fully assessed. No obvious fake-exploit behavior appears in the visible code, but the vulnerability claims are unverified. Repository URL, git reference, and archive size were not supplied; empty strings and zero represent unavailable metadata, not a measured empty archive.
The supplied repository contains six files: exploit.py, safechecker.py, requirements.txt, README.md, an MIT LICENSE, and .gitignore. The listed file sizes total 92,584 bytes; the repository URL, Git reference, archive location, and archive size were not supplied. Both Python scripts expose main entry points and depend on requests and urllib3. PHP appears as an embedded payload rather than a separate source file. The README attributes an unauthenticated arbitrary-file-upload chain to CVE-2026-85097: retrieve a nonce through bricksforge_regenerate_nonce, upload an image/PHP polyglot through form_file_upload, manipulate temporaryFileUploads metadata so the validated source is copied to an attacker-selected .php filename, and access the resulting file under the WordPress uploads directory. Visible code supports this intent through PNG/GIF carrier constants, a PNG text-chunk helper, randomized bf85097_*.php filenames, and a PHP shell that prints BF85097X and executes the c query parameter with system(). The full upload, submission, and verification implementations are truncated, so successful exploitation cannot be established from this excerpt. Visible exploit call sites support optional administrator creation, reverse-shell initiation to a user-supplied host and port, and commands against an existing shell. The README additionally advertises file looting, but its implementation is not visible. Concurrent processing uses a queue and ThreadPoolExecutor, with result summaries and save_results calls. Rotating browser user agents and optional localhost-valued forwarding headers are present; these demonstrate header spoofing, not a proven WAF bypass. urllib3 certificate-warning suppression is visible, but actual TLS verification settings are omitted. safechecker.py is a separate intended detection utility. Visible components include WordPress HTML fingerprints, a four-component version comparator treating 3.1.8.10 and newer as patched, a rate limiter, proxy-rotation infrastructure, concurrent target processing, and VULN/LIKELY/SAFE result reporting. Its central checks are truncated, so the claim that it is non-intrusive cannot be independently confirmed. The repository as a whole is not detection-only and is not tied to an identifiable external exploit framework. Useful defensive fingerprints include BF85097X, bf85097_<six-character suffix>.php, the c command parameter, the documented nonce action and upload endpoint name, and PHP files in dated uploads directories. Google URLs are only spoofed Origin/Referer values, 127.0.0.1 is a spoofed forwarding-header value, and poc.local supplies an administrator email domain; none is shown as an external command-and-control destination. No fixed reverse-shell destination is visible. No evidence in the excerpt establishes a fake exploit, but the CVE's validity, affected-version claims, severity, and asserted active exploitation remain unverified.
The supplied repository listing contains one 48,850-byte Python script with an embedded PHP web shell. It claims to exploit CVE-2026-85097 in Bricksforge <= 3.1.8.9, with a fix in 3.1.8.10. Neither the CVE attribution nor affected/fixed versions are independently verified by the supplied evidence. The documented chain obtains an unauthenticated WordPress REST nonce, uploads an image/PHP polyglot, then abuses temporaryFileUploads metadata to copy the uploaded file into the public uploads directory under an attacker-selected .php filename. PHP execution at that location would yield unauthenticated command execution and further file uploads. Visible payload-building code constructs PNG variants using a tEXt chunk or appended PHP and references GIF variants using comment extensions or appended PHP. The script uses requests, disables urllib3 certificate-warning messages, and includes marker/title-based verification concepts. Its visible tail implements single-target result handling and a bounded ThreadPoolExecutor for multi-target processing, reporting RCE, failure, blocked, missing-file, non-WordPress, and error categories. Proxy and externally supplied payload support are suggested by visible references, but their implementations are omitted. The content is explicitly truncated: request construction, argument parsing, identifier discovery, verification, and several helper functions cannot be fully assessed, so successful execution is not established. The usage examples also name a different script from the listed file. No obvious destructive local command or evidence of a fake exploit appears in the visible portions. No repository URL, git reference, archive location, or archive size was supplied; empty metadata and size 0 indicate unavailable values, not an empty repository.
The seven-file repository is a standalone research lab with a Bash payload generator, Docker Compose configuration, README, license, notices, security policy, and ignore rules. Its documented exploit chain obtains an unauthenticated nonce, uploads a GIF/PHP artifact, then abuses client-controlled temporaryFileUploads.url metadata to copy the file into the uploads directory with a .php basename. A subsequent HTTP request would execute the embedded PHP. The supplied payload is a hardcoded execution marker, not a web shell, and the generator makes no network requests. There is no automated upload or form-submission exploit script in the supplied files. Compose defines WordPress with PHP 8.2/Apache and MariaDB 11.4, persistent volumes, an internal network, and a loopback-only HTTP binding. It uses stock images and does not provision the required Bricks theme or Bricksforge plugin. The README claims reproduction on Bricksforge 3.1.8.9 and fixes in 3.1.8.10 / 4.0.1, but the README is truncated and neither vulnerable plugin source nor complete request examples are available for verification. The generator emits only a GIF89a signature followed by PHP, not a structurally complete GIF; acceptance by the actual MIME-validation path is therefore not independently established. The supplied CVE attribution and execution claims are repository assertions, not independently verified findings. Repository URL, git reference, and archive size were not provided; empty strings and zero represent unavailable metadata.
The repository contains README.md (1,665 bytes) and a standalone Python 3 exploit.py (9,878 bytes). The README attributes an unrestricted-upload-to-PHP-execution vulnerability to CVE-2026-85097, claims Bricksforge versions <= 3.1.8.9 are affected, and lists 3.1.8.10 and 4.0.1 as fixes. These attribution and version claims cannot be independently verified from the supplied files. The script uses requests to obtain a public WordPress nonce, upload a small GIF containing PHP, discover a live Pro Form or accept explicit identifiers, and submit mismatched temporary upload metadata. The actual source remains the uploaded GIF, while the client-controlled URL ends in a randomized PHP filename. The intended vulnerability is that server-side copying uses that URL's basename without revalidating the extension. It supports REST query-route and AJAX fallbacks, optional TLS verification bypass, and several candidate output locations. All runtime network destinations derive from the supplied target; there is no hardcoded external callback or exfiltration endpoint. This is an active exploitation attempt, not merely passive detection, but its hardcoded PHP only prints a marker. Despite functions and messages referring to a shell, no command-execution interface is implemented. Verification accepts any HTTP 200 body containing the marker, so serving the PHP source as text could produce a false positive without PHP execution. The code also treats any 2xx form response as submission success, performs no plugin-version check, and does not clean up uploaded files. Several root-relative URLs can make WordPress installations under subdirectories unreliable. No original repository URL, git reference, or archive size was supplied; empty metadata strings and a zero size represent unavailable values, not a measured empty archive.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
65 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
An unauthenticated arbitrary file upload vulnerability affecting the Bricksforge WordPress plugin through version 3.1.8.9. The reference provides no technical exploitation details or evidence of active exploitation.
An unauthenticated file-upload vulnerability described as enabling remote code execution in Bricksforge WordPress Plugin versions through 3.1.8.9. A Nuclei template is shown passing template validation; the excerpt does not demonstrate successful exploitation.
A critical unauthenticated arbitrary file upload and remote code execution vulnerability affecting Bricksforge WordPress plugin versions through 3.1.8.9. Attackers upload an image containing PHP code, then manipulate visitor-supplied temporaryFileUploads details to write its contents to a PHP destination. Requesting the resulting file executes the code. A publicly accessible nonce-generation AJAX action supplies the required request token. The article reports distributed exploitation attempts from 63 source IP addresses, but does not confirm successful compromises or identify an attacker. Version 3.1.8.10 fixes the flaw; the vendor also lists a Pro Forms upload security fix in version 4.0.1.
An unauthenticated remote code execution vulnerability in the Bricksforge WordPress plugin’s Pro Forms module, affecting versions through 3.1.8.9. An attacker can upload a file that passes image inspection, then manipulate a later form submission so its contents are saved as executable PHP. Successful exploitation allows website modification, access to data available to WordPress, and potentially persistent backdoor access. The article recommends upgrading immediately to version 3.1.8.10 or 4.0.1 and checking wp-content/uploads/bricksforge/tmp for unexpected PHP files, alongside reviewing form-submission logs.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.