EUVD-2026-51697
GHSA-q7qm-9x83-phwf
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Network-reachable OAuth endpoint, no auth required, but AC:H reflects paid-account precondition; impact is token overwrite only, so I:L and C:N/A:N.
Primary rating from Vendor (WPScan).
CVSS VectorVendor: WPScan
Lifecycle Timeline
5DescriptionCVE.org
The Builderall for WordPress plugin before 3.0.2 does not bind the state value of its public OAuth authentication routes to the initiating user session, allowing unauthenticated attackers to complete the connection flow and overwrite the stored third-party integration access token. A durable overwrite requires the site to already be connected to a paid account.
AnalysisAI
Unauthenticated OAuth state hijacking in Builderall for WordPress (versions before 3.0.2) enables remote attackers to overwrite the plugin's stored third-party integration access token by completing an OAuth authorization flow that is never bound to the initiating user session. Practical impact is constrained to sites already connected to a paid Builderall account - without that precondition, the overwrite is transient rather than durable. No confirmed active exploitation exists in CISA KEV, but WPScan has published a public proof-of-concept, making this accessible beyond sophisticated attackers despite an EPSS of 0.18% (7th percentile).
Technical ContextAI
The vulnerability is rooted in CWE-284 (Improper Access Control) specifically in the implementation of OAuth 2.0's state parameter. Per RFC 6749, the state value must be bound to the client's user-agent session to prevent cross-site request forgery on the redirect callback. Builderall for WordPress exposes public OAuth routes that accept and complete the authorization code exchange without verifying that the incoming state value matches a value previously issued to the same browser session. This allows an attacker to craft or race their own OAuth callback against any site running the plugin. The affected product is identified via CPE as cpe:2.3:a:unknown:builderall_for_wordpress:*:*:*:*:*:*:*:* covering all versions below 3.0.2. The Builderall plugin integrates WordPress sites with the Builderall SaaS marketing platform, making stored OAuth tokens the bridge between site content management and external account services.
RemediationAI
The primary fix is upgrading Builderall for WordPress to version 3.0.2 or later, which binds the OAuth state parameter to the initiating user session, eliminating the vulnerability. The patch is confirmed available per the vendor and documented in the WPScan advisory at https://wpscan.com/vulnerability/23e0eb03-ec19-4cec-8127-cb6c2c2f4d7b/. Sites that cannot immediately update should consider temporarily disconnecting the Builderall integration from the WordPress admin panel, which eliminates the attack surface at the cost of disabling platform connectivity. Web Application Firewall rules targeting unexpected or out-of-context OAuth callback requests to the affected plugin routes may provide partial mitigation but are not a substitute for patching, as OAuth redirect URLs are difficult to discriminate without session context at the WAF layer.
More in Builderall For Wordpress
View allStored cross-site scripting in the Builderall for WordPress plugin (versions ≤3.0.2) allows authenticated contributors t
Stored XSS in the Builderall for WordPress plugin (all versions through 3.0.2) enables authenticated contributors to inj
Unauthorized post-layout tampering in the Builderall Cheetah For WP WordPress plugin (≤3.0.2) allows any authenticated S
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today