CVE-2026-14956: Bricksforge WordPress Plugin Vulnerability
TL;DR - Critical unauthenticated privilege escalation in Bricksforge for WordPress. - Affected sites can allow attacker-created admin accounts if public Pro Forms registration is enabled. - Upgrade immediately to a Bricksforge release newer than 3.1.8.6 and audit for rogue admins.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-14956 |
| CVSS score | 9.8 (Critical) |
| Attack vector | Network |
| Auth required | No, if a public Bricksforge Pro Forms registration form is exposed |
| Patch available | Yes, vendor changelog confirms a fix in a release newer than 3.1.8.6 |
CVE-2026-14956 is a high-impact WordPress plugin vulnerability because it can turn a publicly reachable registration workflow into full administrator account creation. In WordPress terms, that is often equivalent to total site compromise: an attacker who gets admin access can modify content, change users, install plugins, and potentially establish persistence.
The practical exposure is narrower than “all Bricksforge sites” but still serious. Exploitation requires a public Bricksforge Pro Forms element configured with the User Registration action. If that condition is met and the plugin is running version 3.1.8.6 or earlier, the issue is remotely reachable by an unauthenticated attacker.
What Is This Vulnerability?
According to the NVD description, the root cause is improper validation of the fieldIds parameter in Bricksforge’s Pro Forms registration action. That validation failure allows attacker-controlled field identifiers to be added to a trusted form-field whitelist. In other words, the application trusts field definitions that should have been constrained to a safe set.
That trust boundary failure matters because registration workflows often map submitted form data to privileged account properties. If an attacker can influence which fields are treated as trusted during registration, they may be able to inject values that should never be user-controllable in a public signup flow. In this case, the result is the ability to create a new administrator account.
From a defender’s perspective, this is not just “another WordPress bug.” It is an unauthenticated privilege escalation issue with a business impact profile much closer to account takeover or application compromise than a normal content-management flaw. If exploited successfully, the attacker bypasses the intended access control model entirely by using the site’s own registration mechanism against it.
Technical Notes
The public description does not include a full request sample from the vendor or NVD, so defenders should avoid assuming exact parameter names beyond the documented fieldIds. What is known is the abuse path:
- A public Bricksforge Pro Forms element is accessible.
- That form uses the User Registration action.
- A crafted submission manipulates
fieldIdsso attacker-supplied fields are treated as trusted. - The registration flow creates an account with administrator privileges.
Because the exact fixed release number was not exposed in the collected changelog snippet, the safest guidance is to move to the latest Bricksforge release newer than 3.1.8.6.
Who Is Affected?
The affected product is the Bricksforge plugin for WordPress. Based on the NVD description, all versions up to and including 3.1.8.6 are vulnerable. The issue is tied specifically to Pro Forms submission handling and, more narrowly, to the registration action in forms exposed to unauthenticated users.
Not every site running Bricksforge is equally exploitable. The documented exploitation condition is critical: there must be a publicly accessible Bricksforge Pro Forms element configured with the User Registration action. If the plugin is installed but that feature is not used, public exposure may be reduced or absent for this specific bug. Even so, defenders should not rely on configuration assumptions alone; they should patch first and verify deployment details second.
For managed WordPress hosting providers, agencies, and SMB operators, the highest-risk population includes marketing or membership sites that intentionally allow user registration through custom frontend forms. Those deployments often prioritize frictionless signup flows, which makes a public registration form normal and expected. In that environment, a bug like this can become reachable without any login barrier.
Technical Notes
You can quickly inventory plugin versions on a host with WP-CLI:
wp plugin list --format=table | grep -i bricksforge
If you manage many sites, collect plugin versions centrally:
for site in $(cat sites.txt); do
echo "== $site =="
ssh "$site" 'wp plugin list --format=csv | grep -i bricksforge'
done
To identify whether WordPress registration or form-driven onboarding is in use, review site configuration and frontend pages for Bricksforge-powered signup flows. In the absence of authoritative automated detection for this exact condition, assume internet-facing forms that create users are high risk until proven otherwise.
CVSS Score Breakdown
The listed severity is CVSS 9.8, which places CVE-2026-14956 in the Critical range. Although the NVD output provided here does not include the full vector string, a 9.8 score commonly aligns with remotely exploitable flaws that require no privileges and can lead to severe integrity and confidentiality impact.
That score is consistent with the described behavior. An unauthenticated attacker can exploit the bug over the network when a vulnerable public registration form exists. The resulting impact is the creation of an administrator account, which substantially affects the integrity and availability of the site and usually exposes all sensitive data handled by the application. In practical terms, defenders should treat this as a likely full application compromise event.
Because the exact vector string was not returned in the provided NVD tool output, avoid overstating components such as attack complexity or user interaction beyond what the evidence supports. Still, the documented prerequisites are minimal enough that the operational priority should remain high.
Technical Notes
Use the score operationally, not just descriptively:
- 9.8 Critical means emergency patch cadence is justified.
- No authentication required means perimeter controls alone are not sufficient.
- Admin account creation means post-exploitation review must include user audits, content integrity checks, and plugin/theme review.
If your vulnerability management platform allows temporary custom enrichment, annotate the finding with: - internet exposure status - whether Bricksforge Pro Forms is enabled - whether User Registration is configured - whether unapproved admin users appeared after form submissions
Exploitation Status
At the time of this write-up, CISA KEV does not list CVE-2026-14956. That means there is no KEV date, no federal remediation deadline, and no official CISA indication of known exploitation in the wild from that catalog entry. The absence of a KEV listing should not be read as proof that the bug is safe to defer; it only means KEV confirmation is not present in the data collected here.
There is also no verified primary-source public proof of concept in the evidence provided. A general search result suggesting GitHub PoC activity is not enough to claim a real exploit exists, so the defensible statement is: no verified public PoC is currently known from the collected sources. Likewise, no primary-source confirmation of active in-the-wild exploitation was identified in the gathered materials.
For defenders, the practical stance should be cautious: assume exploit development is straightforward enough for capable attackers once the root cause is understood. Bugs that allow unauthenticated admin creation on widely deployed CMS platforms often attract rapid attacker attention, especially when the vulnerable condition is a public registration workflow.
Technical Notes
Current known status from collected evidence:
- Public PoC: Not verified
- Active exploitation in the wild: Not confirmed
- CISA KEV: No
In the absence of confirmed exploitation telemetry, prioritize based on: 1. internet exposure, 2. presence of public registration forms, 3. time-to-patch, 4. signs of unexpected administrator creation.
How to Detect It
Detection should focus on two questions: Is the vulnerable feature exposed? and Has someone already abused it? Because the issue leads to admin account creation, start by reviewing newly created WordPress users, especially administrators, around the disclosure window and any period of unexplained form submissions.
Also inspect web server and application logs for suspicious POST requests to pages hosting Bricksforge Pro Forms. The exact endpoint and field names may vary by site implementation, so a generic detection strategy is more reliable than a brittle single-signature approach. Correlate anonymous form submissions with immediate user creation events, role assignment changes, or email notifications related to new administrators.
Technical Notes
Audit administrator accounts with WP-CLI:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered,roles --format=table
Review recently created users across all roles:
wp user list --fields=ID,user_login,user_email,user_registered,roles --format=csv | sort -t, -k4
Example web log hunting pattern for suspicious POSTs to registration or form pages:
grep -E '"POST .* (register|signup|account|form)' /var/log/nginx/access.log
If you know the relevant page slug for the Bricksforge form, narrow it further:
grep '"POST /your-registration-page' /var/log/nginx/access.log
Look for spikes in anonymous requests followed by admin creation. In SQL-backed investigations, check recent user and capability records:
SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC
LIMIT 20;
SELECT user_id, meta_key, meta_value
FROM wp_usermeta
WHERE meta_key LIKE '%capabilities%'
AND meta_value LIKE '%administrator%';
For SIEM-style detection, a useful generic query pattern is:
web_requests
| where method == "POST"
| where url contains "/register" or url contains "/signup"
| join kind=inner (
wordpress_user_events
| where action == "user_created" or action == "role_changed"
) on host
| where timestamp_diff("minute", web_requests.timestamp, wordpress_user_events.timestamp) between (0 .. 10)
If your logging does not capture WordPress application events, assume a gap and compensate with user table audits and server log correlation.
Mitigation and Patching
The vendor changelog confirms a security fix for CVE-2026-14956. The vulnerable range is clearly stated as all versions up to and including 3.1.8.6. The safe remediation guidance, based on the evidence collected, is to upgrade immediately to the latest Bricksforge release newer than 3.1.8.6. Because the exact first fixed version number was not visible in the retrieved changelog snippet, defenders should consult the changelog directly for release details and upgrade to the latest available build newer than 3.1.8.6. The Wordfence entry is also relevant as ecosystem intelligence, and CISA KEV is useful for checking whether exploitation is officially cataloged.
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-14956
- Bricksforge changelog: https://bricksforge.io/version-changelog/
- Wordfence threat intel entry: https://www.wordfence.com/threat-intel/vulnerabilities/id/d0538778-5ba4-4bec-a89d-ef90a9ba8375?source=cve
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
For additional context on access control and best practices, check out our articles on Access Control and CVE-2026-41940.
If you cannot confirm whether a site uses Bricksforge Pro Forms for public registration, the safest assumption is that any internet-facing WordPress deployment running Bricksforge 3.1.8.6 or earlier warrants immediate review and patching.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.