Bricksforge CVE-2026-85097: exploit attempts began on disclosure day; the changelog has no 3.1.8.10 date

First attempt at 21:47 UTC on the day the flaw was published

Patchstack's telemetry recorded the first exploitation attempt against the Bricksforge plugin for WordPress at 21:47:17 UTC on 7 October 2026 (Patchstack's article). Patchstack's own database and Wordfence's database both date their entries for CVE-2026-85097 to the same day, 7 October, and neither prints a time of day. So the first attempt came no more than about 22 hours into the day on which the flaw was published (derived: 21 hours 47 minutes after midnight, with the time zone of the advisory dates unstated), and possibly much sooner. The National Vulnerability Database record was published at 07:16 UTC on 8 October, 9 hours 29 minutes after that first attempt (derived).

That timing does not establish the interval readers usually want: how long a fix had existed before the first attempt. Both advisories name 3.1.8.10 as the fixed version, yet the vendor's changelog, which both records cite as the vendor reference, does not list 3.1.8.10 at all. The only fix it dates that matches this flaw is 4.0.1, released on 8 October, the calendar day after the first attempt, and that entry names no CVE. For that release, exploitation came first, by between about 2 hours 13 minutes and 26 hours 13 minutes (derived, because the changelog gives a date and no time or time zone). For 3.1.8.10, no source read gives a release date, so the interval between fix and first attempt cannot be computed.

Five more things the record does not establish. How many sites run the plugin, and how many of those are on an affected version: there is no WordPress.org count, because the plugin is not hosted there. How many sites were compromised: Patchstack reports attempts, and says nothing about successes. Whether a firewall rule blocks the attack: Patchstack says it has one, which is a statement by a seller of such rules and, in any case, not a fix. Whether the 4.x line is affected: neither advisory says, and the vendor has not said either. The purpose of the two attack clusters Patchstack describes is not stated by anyone.

How this was read. The primary pages were fetched from 11:14 BST on Monday 12 October 2026, and the volatile ones (the CISA catalogue, the NVD record, the vendor changelog and the Patchstack plugin listing) were fetched again at 11:33 BST. Wordfence's page returns an empty response to a plain request and loaded in an ordinary browser tab without a login or any challenge to solve. VulnCheck's known-exploited catalogue is behind a free sign-in that was not used, so nothing here says whether it lists this CVE. The Hacker News (12 October) and Dr. Web (9 October) are secondary and were used as pointers only; where they differ from the primaries, the primaries are followed. Patchstack's article is dated 8 October, so the headline of 12 October is four days behind its primary. The flaw is described below as a class only: an unauthenticated upload path in a form handler that trusts client-supplied file metadata. No request, endpoint, parameter, file name pattern or address from the primary is reproduced.

Stated and not stated: the record, line by line

What the primary records state and do not state about CVE-2026-85097, read on 12 October 2026. Sources: Patchstack article and database, Wordfence entry, NVD record, CISA catalogue file, Bricksforge changelog, WordPress.org directory.

Item	Stated, and by whom	Not stated
The flaw	An unauthenticated upload path in a form handler that trusts client-supplied file metadata, ending in PHP code running on the server (Patchstack, Wordfence, NVD). Weakness class CWE-434 (Wordfence)	The vendor's own account: its changelog says only that a security issue in the Pro Forms file upload was fixed, and that details will follow
Affected versions	Up to and including 3.1.8.9 (Patchstack, Wordfence, NVD)	Whether 4.0.0, released 17 September, is affected. The vendor's 4.0.1 note implies the 4.x line needed a fix (inference)
Fix	3.1.8.10 (Patchstack, Wordfence). 4.0.1, dated 8 October, in the vendor changelog with no CVE and no version range	The release date of 3.1.8.10, and whether the vendor still supports the 3.x line
Who is exposed	Vendor: every site with Pro Forms active, including sites whose forms use no upload field	How many sites. The plugin is not in the WordPress.org directory, so no directory count exists
Attempts	First seen 7 October, 21:47:17 UTC. 63 source addresses. Two clusters: 44 addresses sending 56 requests, and three addresses trying 25 variations (Patchstack)	Whether any attempt worked, how many sites were compromised, the total request count, who is behind it and why
Firewall rule	Patchstack says it deployed a rule that was live before the first attack arrived	That the rule blocks every variant, or whether any other firewall has one. A rule is not a fix
CISA catalogue	Not listed in the Known Exploited Vulnerabilities catalogue, version 2026.10.08, released 8 October at 20:09 UTC	Whether CISA will add it. VulnCheck's catalogue could not be read without an account
Score	9.8 from Wordfence, the body that assigned the CVE, with a vector. 10.0 from Patchstack. The NVD has no score of its own (status Deferred)	The vector behind Patchstack's 10.0, which its pages do not show

One label deserves a caution. Patchstack's database page for this CVE carries a badge reading "Known to be exploited! (KEV)". The initials match CISA's catalogue, and CISA's file does not list the CVE. The badge is Patchstack's own flag, and what list it draws on is not stated, so it should not be read as a catalogue entry. The file read on 12 October was catalogue version 2026.10.08 with 1,739 entries, and its latest addition was dated 8 October (CISA file).

The clocks, computed from the records

Every interval below is derived by subtraction from timestamps printed in the sources. The first attempt is Patchstack's 7 October 21:47:17 UTC. The other end of each interval is named in the right-hand column.

Intervals from Patchstack's first observed attempt (7 October 2026, 21:47:17 UTC). All figures derived.

Interval	Value (derived)	Other end, and its source
First attempt to NVD record published	9 h 29 min 14 s	8 Oct 07:16:31 UTC, NVD published stamp (CNA: Wordfence)
First attempt to the CISA entry reading exploitation none	16 h 37 min 13 s	8 Oct 14:24:30 UTC, CISA coordinator data inside the NVD record
First attempt to catalogue release 2026.10.08	22 h 22 min 1 s	8 Oct 20:09:18 UTC, CISA catalogue file (no entry for this CVE)
First attempt to 4.0.1	2 h 13 min to 26 h 13 min after	8 October, vendor changelog (date only, no time or zone)
Release of 3.1.8.10 to first attempt	Cannot be computed	No release date in any source read
Cyber Essentials 14-day limit	22 October for 4.0.1; 21 October at the latest for 3.1.8.10	14 days from 8 October, and from 7 October if 3.1.8.10 shipped that day (earlier if it shipped before)

Two statements about the fix are supported by the record, and they should not be merged. First, for the only fix the vendor dates, 4.0.1, exploitation came first. Second, for 3.1.8.10, both advisories were published on 7 October and both already name it as the patched version, which suggests it existed when they were published (inference), but nobody says when it was released. If it was released on 7 October or earlier, the fix preceded the first attempt by an interval nobody has published. If it was released later, exploitation preceded it. The record cannot decide between those.

The CISA row needs care. The NVD record carries a coordinator entry from CISA, stamped 14:24 UTC on 8 October, with three fields: exploitation none, automatable yes, technical impact total. "None" describes what that entry recorded at its stamp, 16 hours 37 minutes after Patchstack's first attempt. It is not a finding that nothing was happening, and it is not a statement about what CISA knew. The contrast is useful for one reason: a coordinator field can read "none" at a time when a vendor's telemetry has already recorded attempts, which makes such fields lagging indicators and leaves the update as the control (inference). For a comparison where the interval could be computed, see an earlier briefing, in which Patchstack's first attempt on a Ninja Forms flaw came 14 days after the fix.

10.0 or 9.8: who set each number

The two scores are 10.0 and 9.8, a gap of 0.2 (derived). Wordfence set 9.8. Its entry shows the CVSS 3.1 vector, and the NVD record shows Wordfence as the source of the score, with the scope marked as unchanged. Patchstack set 10.0. Its article shows the number with the word Critical, and neither its article nor its database entry shows a vector. A CVSS 3.1 base score of 10.0 is what the same impact and exploitability ratings produce when the scope is marked as changed (derived from the published CVSS 3.1 equations), so the difference is probably a scope judgement, but that is inference: Patchstack has not published its vector on the pages read. The NVD itself has assigned no score. Its status for this CVE is Deferred.

The gap on this flaw is small. Across the plugin's other 2026 flaws the two databases disagree by more. CVE-2026-84814 is 9.8 on Patchstack and 6.3 on Wordfence, a gap of 3.5. CVE-2026-18030 is 9.8 on Wordfence and 8.1 on Patchstack, and also 8.1 in the NVD record, where the score comes from CISA's coordinator entry, a gap of 1.7. A score records one organisation's judgement of a flaw's technical severity. It does not record whether anyone is attacking it. Patchstack's observation of attempts does that, and it is a separate piece of evidence.

Each source has a commercial stake, stated plainly. Patchstack sells mitigation rules and says its rule was live first. Wordfence assigned the CVE and sells a WordPress firewall. Bricksforge sells the plugin and, on the record read here, has published the least detail. None of that makes any of the three wrong. It is the reason to read the numbers each of them chose to print against the numbers it did not.

Three flaws in five weeks is true on one database's dates

Dr. Web calls this the third serious flaw in the plugin in five weeks, and the count was checked against the listings, not taken on trust. Patchstack's plugin listing and its entries support it. They date CVE-2026-84814 to 2 September (9.8), CVE-2026-18030 to 18 September (8.1) and CVE-2026-85097 to 7 October (10.0). The gaps are 16 days and 19 days, and 35 days from first to last, which is exactly five weeks (derived).

The plugin's four 2026 flaws as dated by three databases, with scores. Sources: Wordfence and Patchstack vulnerability listings, the NVD records and the Bricksforge changelog, read on 12 October 2026. Spans are derived.

CVE and flaw	Wordfence	Patchstack	NVD published
CVE-2026-14956, unauthenticated privilege escalation in Pro Forms	16 July, 9.8	Not listed	17 July, 9.8
CVE-2026-18030, unauthenticated privilege escalation through password reset	4 August, 9.8	18 September, 8.1	10 August, 8.1
CVE-2026-84814, authenticated (Subscriber and above) privilege escalation	2 September, 6.3	2 September, 9.8	3 September, 9.8
CVE-2026-85097, unauthenticated file upload	7 October, 9.8	7 October, 10.0	8 October, no score (Deferred)
First to last	83 days, four flaws	35 days, three flaws	83 days, four flaws
Vendor releases in the period	3.1.8.9 on 28 August, 4.0.0 on 17 September, 4.0.1 on 8 October	Same	Same

The other records tell a different story. Wordfence's list for the plugin dates four 2026 flaws to 16 July, 4 August, 2 September and 7 October, gaps of 19, 29 and 35 days, which is four flaws in 83 days (derived). The NVD's published dates for the same four CVEs are 17 July, 10 August, 3 September and 8 October, gaps of 24, 24 and 35 days, also 83 days in all (derived). One CVE, CVE-2026-18030, carries three dates: 4 August on Wordfence, 10 August in the NVD and 18 September on Patchstack, which is 45 days from first to last (derived). Wordfence also scores CVE-2026-84814 at 6.3 and describes it as needing a Subscriber account, so on its list that flaw is not an unauthenticated critical one, and CVE-2026-18030 falls outside the five weeks altogether. Inside Patchstack's window, Wordfence's list holds two entries, not three.

What this establishes: at least four numbered flaws in this plugin between 16 July and 7 October, 83 days, on the Wordfence and NVD dates, with Patchstack listing three of the four and dating one of those 45 days later than the others. The vendor shipped three dated releases in the same stretch (28 August, 17 September and 8 October, gaps of 20 and 21 days, derived). What it does not establish: that the plugin is worse written than its peers, since a count of advisories also measures how many researchers are looking (inference). It does not establish that another flaw is coming. And "third in five weeks" is a count that needs its definition: whose dates, and which scores count as serious. Dr. Web's timeline also dates the report of CVE-2026-84814 to 16 August. No record read here carries that date, so it is not used.

56 requests from 44 addresses: what 1.3 per address shows

Patchstack describes two clusters. In the first, 44 addresses sent 56 requests with identical payloads within seconds of each other. In the second, three addresses tested 25 variations of a file-type evasion against one file. Across all the activity it counted 63 unique source addresses, and the six most active accounted for about 46 per cent of all requests. The total number of requests is not given, only shares.

The arithmetic: 56 requests across 44 addresses is about 1.3 requests per address (derived: 1.27). The second cluster is about 8.3 variations per address (derived: 25 divided by 3). The six busiest addresses averaged about 7.7 per cent of all requests each, against about 0.95 per cent each for the other 57 (both derived, assuming an even split inside each group).

What the cluster figures show and do not show. Figures from Patchstack's article; the reading in the right-hand column is this briefing's, labelled where it is inference.

Figure	What it shows	What it does not show
44 addresses, 56 requests, identical, within seconds	Automated sending of one fixed request from many sources, which Patchstack reads as rotating proxies or distributed infrastructure	That 44 addresses are 44 machines or 44 operators. An address is not an actor. Patchstack does not attribute the activity to a single actor either
About 1.3 requests per address	No address kept trying. The pattern describes how the requests were sent	Whom they were aimed at. The telemetry does not say whether the 56 requests reached 56 sites, five or one
Three addresses, 25 variations	Probing for a way past file-type filtering, in Patchstack's words	Whether the probes succeeded, or whether either cluster belongs to the same operator as the other
63 addresses, mixed infrastructure	Datacenter, cloud, VPN and proxy, and fixed-line sources all appear, so blocking addresses buys little	Where the sites that received the requests are, including in the UK

On the source side, then, this is a spray: a fixed request repeated from many addresses, about once each. The data does not show a targeted intrusion, and it does not show that the targets were chosen. A mass campaign of this kind needs no choosing (inference), which is the practical point for a small site owner: not being well known is not a reason for the attempts to miss a site that runs the plugin.

3.x or 4.x: what the vendor says and what it leaves out

The vendor's changelog is the reference both CVE records cite. It dates three releases in the period. 3.1.8.9 is dated 28 August 2026 and closes a security issue in how the Email Designer renders email templates. 4.0.0 is dated 17 September and says it "Includes all hardening and fixes from the 3.x line", alongside a rebuilt animation panel, email designer and settings backend. 4.0.1 is dated 8 October and is a security fix for the Pro Forms file upload. In the vendor's words it affects "every site with Pro Forms active", including sites whose forms use no upload fields, and full details will follow once the disclosure process is complete.

What it leaves out. The changelog lists no 3.1.8.10 and no 3.1.8.8, although Patchstack and Wordfence name both as fixed versions. It names no CVE and gives no affected range for 4.0.1. It does not say whether the 3.x line will receive further fixes. Patchstack tells users to update to at least 3.1.8.10, while The Hacker News and Dr. Web tell them to move to 4.0.1. Both can be right for different sites, but the vendor has not said which it prefers.

The 4.x question. The advisories give the affected range as up to and including 3.1.8.9, which says nothing either way about 4.0.0. The vendor's note that 4.0.1 fixes the Pro Forms upload suggests the 4.x line needed the fix too (inference), and no source confirms it. Until the vendor or an advisory says otherwise, a site on 4.0.0 should be treated as not confirmed safe and moved to 4.0.1 or later. A move from 3.x to 4.x is a major release with a rebuilt interface according to the vendor's own list, so it deserves testing on a copy first. The briefing cannot say whether either route breaks a given site.

Five labels that sound like controls

Each of these sounds like a control, and each is easy to say in good faith. None is one.

Labels that stand in for a control, what the record shows about each, and what would be a control. Sources: Bricksforge changelog and pricing page, Wordfence and Patchstack listings, Cyber Essentials v3.3, CISA catalogue file.

The label	What the record shows	What would be a control
It is a premium plugin	It is paid for: the vendor's pricing page lists Plugin Updates in every plan. Wordfence's list has five 2026 entries for it, four of them unauthenticated	An update applied and confirmed, under a licence that still delivers updates
It is only a form builder	The vendor says the flaw affects every site with Pro Forms active, including forms with no upload field. A form handler takes input from anonymous visitors by design	Knowing whether Pro Forms is active on each site, rather than whether a form takes uploads
The agency maintains it	No source says who maintains any site. Cyber Essentials v3.3 says the applicant is always responsible for controls on cloud services, and must be able to confirm that externally managed controls are met	A named person, a version list and a date, held by the site owner as well as the agency
We have a firewall	Patchstack says its rule was live before the first attack. For another flaw in the same plugin, its page says a rule cannot be created. A rule blocks requests it knows and does not change the code	The update. A rule is a stopgap, and helps only where that rule is switched on
The advisory says KEV	Patchstack's page shows a badge reading Known to be exploited (KEV). CISA's catalogue file does not list the CVE	Checking which list a badge draws on before treating it as a catalogue entry

The control is inventory plus update: a list of every site and the version of the plugin on it, checked against the fixed versions the advisories and the vendor name, with a named person who changes the version and a date when they did. Everything else in the table is a layer on top of that, or a way of discovering that it is missing. The fifth label is the easiest to misread, because a badge with three familiar initials looks like a government listing.

The UK: small organisations, agency-built sites and what the standards say

No source read gives a UK count of affected sites, or says where Patchstack's telemetry comes from. The UK exposure the record supports is structural rather than counted: the plugin is a paid add-on for a site builder, which is the kind of component a web agency installs and a small organisation's owner may never see in a plugin list (inference). Three UK sources bear on what those owners and their agencies owe each other, and the table sets out what each says as read. None of them mentions this plugin.

UK sources as read on 12 October 2026, and what each does and does not settle.

Source	What it says, as read	What it does not settle
Cyber Essentials, Requirements for IT Infrastructure v3.3 (April 2026)	Software in scope must be licensed and supported, and updated within 14 days of release where the update fixes flaws the vendor calls critical or high, or that score 7 or above on CVSS v3, or where the vendor gives no detail. It applies to servers, IaaS, PaaS and SaaS. Cloud services cannot be excluded from scope, and the applicant is always responsible for the controls even where the provider implements some	Both scores for this flaw are above 7, so the 14-day rule covers the update. Whether a given site and plugin sit inside an organisation's assessed scope depends on its scope statement, which was not read for any organisation
NCSC website guidance, 29 May 2024	If a site runs a content management system, security updates must be installed when the vendor releases them, including for themes and plugins. It also says to think about who will be responsible for maintaining the site before setting one up	It is written within the NCSC's guidance for high-risk individuals, and its CMS sentence is general. It does not mention this plugin or set a deadline
ICO breach guidance, and UK GDPR Article 33	A controller must notify the regulator "without undue delay and, where feasible, not later than 72 hours after having become aware" of a breach, unless it is unlikely to risk people's rights and freedoms. A processor must tell the controller without undue delay. The ICO page says it is under review because of the Data (Use and Access) Act	Whether this flaw exposed personal data on any given site. That is for the site's owner to establish from what the site stored or emailed

The Cyber Essentials clock is the most concrete UK fact here. It runs from release. For 4.0.1 the release is dated 8 October, so 14 days ends on 22 October. For 3.1.8.10 the vendor publishes no date, so the clock cannot be started from the vendor's record: if it shipped on 7 October, the limit is 21 October at the latest, and earlier if it shipped sooner (both derived). Today, 12 October, is at least 5 days into the 3.1.8.10 window and 4 days into the 4.0.1 window, and Patchstack's attempts began before the second of them opened. Fourteen days is a ceiling for passing an assessment, not a statement of how long a site can safely wait. The vendor's pricing page lists Plugin Updates as part of its plans (pricing). That matters because "licensed and supported" is also a Cyber Essentials requirement, and a lapsed licence may mean the update does not arrive (inference, since the page does not say what a lapse does).

For agency-built sites the responsibility is the owner's even when the work is the agency's. The Cyber Essentials text says an applicant that uses externally managed services must be able to confirm that the technical controls are met. Under UK GDPR, the site owner is typically the controller of what visitors typed into its forms, and the agency or host a processor, which makes the processor's duty to tell the controller without undue delay the sentence that matters in a contract (as the Article reads; whether a particular agency is a processor depends on the facts of the arrangement). If the forms collected names, email addresses or enquiries, and the server was reachable by an attacker, then a personal data breach may have occurred and the 72-hour clock runs from awareness. This briefing is not legal advice.

What to do, in the order worth doing

Defender level only. Work through the list in order for each site. The first two steps close the door. The rest decide whether anyone was already inside, and updating does not remove anything an attacker has already planted.

What could not be verified

Items that could not be verified from the sources read, and how this briefing handles each.

Not verified	How it is handled here
The release date of 3.1.8.10	Not on the vendor changelog or in either advisory. No interval is computed for it
How many sites run the plugin	No WordPress.org figure, and Patchstack's plugin listing shows Installations as N/A. Its article shows an unlabelled 6K beside a download icon, which Dr. Web reads as about 6,000 active installations. Its meaning is not stated, so no exposure figure is derived from it
How many sites were compromised	Patchstack reports attempts. None is counted as a breach
Whether 4.0.0 is affected	Neither advisory says. Treated as unconfirmed, with the reasoning marked as inference
Whether Patchstack's rule blocks every variant	Attributed to Patchstack as its statement. Not tested, and no other firewall's coverage is known
Whether VulnCheck lists the CVE	Its catalogue needs a free account that was not created. Nothing is said about it
Dr. Web's date of 16 August for the report of CVE-2026-84814	No record read carries it. Not used
The vector behind Patchstack's 10.0	Not shown on its pages. The scope explanation is marked as inference
The time of day of the advisories	Both give dates only. The first-attempt bounds are shown as bounds
The purpose and identity behind either cluster	Not stated by Patchstack. Not speculated about here

The question that exposes the gap

Can the person who maintains your website tell you, before the end of today, which of your sites run Bricksforge with Pro Forms switched on, which version each one is on, and when someone last looked for PHP files that should not be there? If the honest answer is that they would need to go and look, then the control was never the licence, the agency's name or the firewall. It was a list that did not exist.

Key facts