CVE-2026-11357: Kadence Blocks Information Disclosure Flaw

CVE-2026-11357 Overview

The Kadence Blocks — Page Builder Toolkit for Gutenberg Editor plugin for WordPress contains a sensitive information exposure flaw in all versions up to and including 3.7.5. The vulnerability resides in the editor_assets_variables function, which exposes connected Kadence account credentials through the window.kadence_blocks_params.proData object in the block editor client context. Authenticated users with Contributor-level access or above can read the license key, license owner email, api_key, api_email, and license domain directly from the browser console. The flaw is categorized under [CWE-200] Information Exposure.

Critical Impact
Contributor-level users can harvest Kadence account API credentials and license data without any server-side request manipulation, enabling lateral abuse of the connected Kadence account.

Affected Products

Kadence Blocks — Page Builder Toolkit for Gutenberg Editor plugin for WordPress
All versions up to and including 3.7.5
WordPress installations with a connected Kadence Pro license

Discovery Timeline

2026-06-18 - CVE-2026-11357 published to NVD
2026-06-18 - Last updated in NVD database

Technical Details for CVE-2026-11357

Vulnerability Analysis

The vulnerability stems from how Kadence Blocks injects editor configuration data into the block editor client. The plugin localizes a JavaScript object named kadence_blocks_params for use by the Gutenberg editor. Within this object, the proData property carries the full credential bundle associated with the site's connected Kadence Pro account.

WordPress localized script variables are emitted inline into the page HTML and become accessible to any user whose role can load the block editor. Contributor accounts in WordPress can access the editor to draft posts, so they receive the same proData payload as administrators. The data is rendered server-side and delivered without role-based filtering.

The affected code paths are visible in class-kadence-blocks-editor-assets.php line 291, line 337, and helper-functions.php line 286. Additional details are documented in the Wordfence Vulnerability Report.

Root Cause

The root cause is missing authorization separation between editor asset bootstrapping and credential exposure. The plugin attaches sensitive license metadata to a script handle that loads for every editor-capable user. No capability check (such as current_user_can('manage_options')) gates the inclusion of proData in the localized parameters.

Attack Vector

An attacker first obtains Contributor-level credentials through legitimate registration, social engineering, or compromise of an existing low-privilege account. The attacker then opens the WordPress block editor and inspects window.kadence_blocks_params.proData from the browser developer console. The license key, api_key, api_email, license owner email, and license domain are returned in clear text. Exploitation requires that an administrator previously connected a valid Kadence license to the site.

The vulnerability is described in prose because no public proof-of-concept code is required — retrieval is a single property read from a JavaScript object that the plugin places into the DOM context.

Detection Methods for CVE-2026-11357

Indicators of Compromise

Unexpected logins from Contributor or Author accounts followed by visits to /wp-admin/post-new.php or /wp-admin/post.php
API activity against the Kadence licensing endpoints originating from IP addresses not associated with the site administrator
New devices or domains registered against the same Kadence license without administrator action
Browser developer tool usage recorded in client-side telemetry for low-privilege WordPress users

Detection Strategies

Audit WordPress access logs for Contributor and Author role accounts loading block editor pages outside normal authoring windows
Search HTML responses for the string kadence_blocks_params and confirm whether proData is delivered to non-administrator roles
Correlate Kadence account-side activity logs with site-side administrative actions to detect credential reuse from unexpected origins

Monitoring Recommendations

Enable WordPress audit logging for role assignment, user registration, and editor access events
Monitor for self-registration spikes on sites where users_can_register is enabled
Track changes to license-bound domains or API key usage in the Kadence account dashboard

How to Mitigate CVE-2026-11357

Immediate Actions Required

Update the Kadence Blocks plugin to a version above 3.7.5 that removes proData exposure for non-administrator roles
Rotate the Kadence license key, api_key, and associated API credentials after upgrading
Review all Contributor, Author, and Editor accounts and remove any that are unrecognized or inactive
Disable open user registration unless required, and require administrator approval for new accounts

Patch Information

The vendor addressed the issue in a release published through the WordPress plugin repository. Refer to the Kadence Blocks change log for the exact changeset that restricts proData distribution to privileged users. Apply the fixed version through the WordPress plugin updater or via WP-CLI.

Workarounds

Temporarily disconnect the Kadence Pro license from the WordPress site until the patch is applied
Restrict block editor access for Contributor accounts by removing the edit_posts capability through a role management plugin
Filter the localized script output using a mu-plugin that strips proData from kadence_blocks_params before it is sent to non-admin users

bash

# Update Kadence Blocks to the fixed version via WP-CLI
wp plugin update kadence-blocks
wp plugin get kadence-blocks --field=version

# Rotate license after upgrade by deactivating and reconnecting
wp option delete kadence_blocks_activation