CVE-2026-14956: Bricksforge Pro Forms privilege escalation

CVE-2026-14956 is a critical privilege-escalation vulnerability in the Bricksforge plugin for WordPress. Wordfence, acting as the CVE Numbering Authority, reports that an unauthenticated attacker can submit attacker-chosen field identifiers to a public Bricksforge Pro Forms registration form and cause the registration action to create a WordPress administrator account.

The disclosed attack path exists only when both conditions are true:

1. Bricksforge is running version 3.1.8.6 or earlier.
2. A publicly accessible Pro Forms element uses the User Registration action.

Bricksforge identifies version 3.1.8.7 as the release that fixed the Pro Forms privilege-escalation issue. Upgrade to 3.1.8.7 or a later vendor-supported release. Do not use a third-party package or infer that a later unrelated version is the first fixed release.

Evidence basis and limits

This recipe is based on the Wordfence CNA record, the Bricksforge version changelog, Bricksforge Pro Forms documentation, official WP-CLI command documentation, live GHAD GHSA-3h83-c8w5-cccx, and NVD. Live GHAD has vulnerabilities empty. NVD is Deferred with empty CPE. 3.1.8.7 is not an NVD exclude. Do not invent a later 3.1.8.8 floor.

The CNA record defines the affected semver range as 0 through 3.1.8.6 inclusive, with other versions unaffected by default. It assigns CVSS 3.1 score 9.8 and CWE-269, Improper Privilege Management. The Bricksforge changelog for 3.1.8.7, dated 2026-07-14, explicitly names CVE-2026-14956 and says that the release fixed the Pro Forms submission-handling privilege escalation.

The public sources do not expose the commercial plugin's private patch or prove the state of any particular WordPress site. This recipe therefore does not invent vulnerable PHP code, a patch diff, or an exploit payload. Confirm the installed package, form configuration, and live deployment through approved read-only evidence.

When to use this recipe

Use it when a repository, scanner result, asset inventory, or incident ticket identifies Bricksforge on a WordPress site and the task is scoped to CVE-2026-14956. The repository may own Composer or deployment artifacts, plugin-package checksums, container images, WordPress configuration, form templates, release runbooks, inventory policy, or regression tests.

Do not use it to send a crafted fieldIds request, create a test administrator through the vulnerable route, download Bricksforge from an unofficial source, or make an unapproved production change.

Inputs

• The site owner, environment, change window, and exact authorized boundary.
• The installed Bricksforge version from WP-CLI, the WordPress administration interface, a signed inventory, or a package manifest.
• A list of published pages and templates containing a Bricksforge Pro Forms element, including the configured action list and public reachability.
• The approved Bricksforge Customer Dashboard package or vendor-supported updater and its integrity evidence.
• Repository-controlled deployment definitions, plugin checksums, image pins, release notes, smoke tests, backups, and rollback procedure.
• An approved administrator-account inventory and incident-response owner if the affected configuration was publicly reachable.

Do not commit customer data, credentials, license keys, database dumps, raw access logs, or private plugin packages to the repository.

Affected and fixed versions

Bricksforge version	CVE-2026-14956 status	Required action
0 through 3.1.8.6, inclusive	Affected when a public Pro Forms element uses User Registration	Upgrade and assess exposure
3.1.8.7 or later vendor-supported release	Contains the vendor-documented fix	Verify the deployed package and form behavior

There is no GHAD first_patched and no NVD CPE floor. Use the vendor-named 3.1.8.7 only. Version alone does not prove that the disclosed route was reachable. A site on an affected version still requires the public Pro Forms User Registration configuration for the exact CNA-described exploitation condition. Conversely, removing that configuration does not make vulnerable software fixed.

How to check exposure for CVE-2026-14956

1. Identify the installed plugin directory name from approved inventory. Do not assume it when the deployment renames or vendors plugins.
2. For a standard bricksforge installation, collect the version read-only:

bash wp plugin get bricksforge --field=version

1. Inspect published Bricks templates and pages for enabled Pro Forms elements. Bricksforge documents form actions in the Pro Forms element's Actions settings.
2. Record whether User Registration is configured and whether an unauthenticated visitor can reach the page containing that form.
3. Classify the exact disclosed exposure as confirmed only when the deployed version is 3.1.8.6 or earlier and that public configuration is present.
4. If version or configuration evidence is missing, stop with a triage record; do not prove exposure by submitting attacker-controlled field identifiers.

Temporary containment

If an approved upgrade cannot be completed immediately, prepare a time-bounded change to unpublish the affected registration page or disable the User Registration action on publicly reachable Pro Forms elements. This is a conservative inference from the CNA's required exposure condition, not a vendor-published mitigation and not a substitute for upgrading.

Record the service impact, owner approval, exact configuration diff, expiry, and restoration plan. Do not silently disable a business-critical registration workflow.

How to remediate CVE-2026-14956

1. Obtain Bricksforge 3.1.8.7 or later from the licensed vendor updater or Bricksforge Customer Dashboard.
2. Preserve the approved package checksum, source, version, and acquisition time in the change evidence without committing the commercial package.
3. Update every repository-controlled plugin pin, checksum, container layer, deployment manifest, inventory policy, and runbook that can reinstall the affected release.
4. Back up the site and database through the existing recovery process. Confirm that the backup is restorable and protected from public access.
5. Deploy through the site's normal staged release path. Keep cache purge, maintenance mode, database operations, and production rollout under the responsible owner's authority.
6. Re-check every site or tenant independently; one updated environment is not evidence that the fleet is remediated.

How to verify the remediation

• Confirm the deployed version is 3.1.8.7 or later using approved inventory and, where available, wp plugin get bricksforge --field=version.
• Confirm the package came from the vendor-supported source and matches the reviewed release artifact.
• Exercise legitimate Pro Forms registration behavior with an ordinary least-privileged test account. Do not add unexpected field identifiers or attempt administrator creation.
• Run the existing WordPress, form, authentication, authorization, and deployment smoke tests.
• Confirm the desired plugin version is present in the built artifact and every deployed site after caches and immutable images are refreshed.
• Record the version, artifact identity, environment, verifier, timestamp, and test results in the review evidence.

When the affected form was publicly reachable, review administrator accounts through an approved channel. WP-CLI supports a read-only inventory such as:

wp user list --role=administrator \
  --fields=ID,user_login,user_email,user_registered \
  --format=csv

This administrator review is prudent post-exposure hygiene inferred from the documented impact; it is not a vendor-prescribed remediation step. Treat an unexpected administrator as an incident-response signal. Patching the plugin does not remove an account that may already have been created.

Rollback and stop conditions

Rollback means restoring the recorded prior deployment artifact and configuration through the site's approved recovery path if the vendor-fixed release causes an operational regression. Because rollback may restore a vulnerable plugin, reapply the approved temporary containment and escalate the blocked upgrade immediately.

Stop and write TRIAGE.md when:

• the installed version, plugin identity, or public form configuration cannot be established;
• the vendor package or integrity evidence is unavailable;
• repository ownership differs from live-site authority;
• the upgrade requires an unapproved production, database, or availability change;
• an unexpected administrator, suspicious registration, or other compromise indicator is found; or
• verification would require an exploit-like request.

The triage record must name CVE-2026-14956, the inspected scope, confirmed facts, missing evidence, containment state, responsible owner, and safest next action.

Output contract

Return exactly one reviewer-ready change set scoped to CVE-2026-14956, or a TRIAGE.md blocker record. A change set must include:

• affected-site and public-form exposure evidence;
• vendor-source and fixed-version evidence;
• the minimal repository diff;
• safe functional and security regression results;
• deployed-version and artifact verification;
• administrator-review disposition when the exact exposure was public;
• rollback steps and temporary-containment expiry; and
• residual risk and authoritative source links.

Do not claim remediation from a desired-state version alone. Do not suppress the finding until the fixed package is verified in every affected deployment.

Primary references

• CVE Program CNA record for CVE-2026-14956
• GitHub Advisory GHSA-3h83-c8w5-cccx
• Bricksforge version changelog
• Bricksforge getting-started and Customer Dashboard guidance
• Bricksforge Pro Forms actions documentation
• WP-CLI plugin get documentation
• WP-CLI user list documentation
• NVD record for CVE-2026-14956

Related recipes

• CVE intelligence intake gate
• Vulnerable Dependency Remediation
• How to remediate vulnerabilities with AI agents