EUVD-2026-83511
GHSA-6w7q-74cq-4m3f
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLoad public page with SCF form
-
ExploitIdentify target registered form binding
-
ExecutionForge submission referencing different form
-
ImpactOverwrite bound post title and content
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the site to actively deploy Secure Custom Fields front-end forms bound to posts and render them publicly - the vulnerable code path only exists when SCF's front-end form-submission feature is in use. The attacker must know or enumerate a second registered form and the post it is bound to in order to overwrite that post's title/content, which is what the AC:H (high complexity) rating captures. No authentication and no user interaction are required (PR:N/UI:N), but impact is limited to modifying the title and content of the specific post bound to the abused form; sites not using SCF front-end forms are unaffected. |
| Impact | The signals converge on a genuinely low-priority issue despite public exploit code. The CVSS 3.1 base score is 3.7 (LOW) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N - network-reachable and unauthenticated (PR:N), but high attack complexity (AC:H) and limited-integrity-only impact (I:L, with C:N/A:N). CWE-863 (improper authorization) is accurate: the flaw is that the plugin fails to bind a front-end submission to the form actually rendered, not a credential-based authentication bypass. A public PoC exists (WPScan), which raises the practical likelihood of opportunistic use, but there is NO CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation. The AC:H rating reflects that an attacker must target a specific registered form bound to a specific post - the impact is confined to overwriting the title/content of that bound post, not arbitrary site takeover. Net: publicly-known and unauthenticated, but low real-world severity and gated on the site actually deploying SCF front-end forms. |
| Exploit ScenarioDerived | A site uses a Secure Custom Fields front-end form (bound to a specific post) that is publicly rendered to visitors. An unauthenticated attacker crafts a submission that references a different registered form than the one rendered, causing the plugin to accept it and overwrite the title and content of the post bound to that other form. A public proof-of-concept is available via WPScan, lowering the effort to reproduce it. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 19, 2026
Unauthenticated visitors to WordPress sites running the Secure Custom Fields plugin before 6.9.4 can submit data against a registered form other than the one that was actually rendered to them, overwriting the title and content of the post that the abused form is bound to. The vulnerability is only reachable where SCF's front-end form-submission feature is actively deployed and rendered publicly, and successful exploitation requires the attacker to enumerate a second registered form plus its bound post, which is why the assessed CVSS is a modest 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N - integrity-only, low impact). Publicly available exploit code exists (the WPScan entry is tagged as an exploit reference), but there is no KEV confirmation of active exploitation; the vendor has released a fix in Secure Custom Fields 6.9.4, so the practical priority is patching sites that use front-end forms rather than emergency response.
RemediationAI
Vendor-released patch: upgrade Secure Custom Fields to 6.9.4 or later, which is the exact fixed version identified in the advisory data; the WPScan entry at https://wpscan.com/vulnerability/740341ca-6419-4980-8ee9-d9e5c0f8df92/ is the authoritative source to track for update confirmation, with additional detail at https://vuldb.com/vuln/407858. If an immediate upgrade is not possible, the most effective compensating control is to stop rendering SCF front-end forms that are bound to posts - unpublish or disable the front-end form-submission feature for anonymous visitors - since the vulnerable code path only exists while such forms are publicly served; the trade-off is the loss of any legitimate front-end post submission workflow, and the control must be re-verified after plugin updates restore the feature. As a lower-effort measure, audit and reduce the number of registered forms and their public visibility so an attacker has fewer candidate forms and bound posts to enumerate (this raises the already-high complexity of exploitation but does not remove the flaw), and monitor post titles/content for unexpected edits by unauthenticated requests. Note that a WordPress plugin update is required; because the CPE vendor field is recorded as unknown, do not rely on CPE-driven scanners alone to flag affected installs - verify the installed plugin version directly.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-863 (Incorrect Authorization): the plugin's front-end form handler does not verify that an incoming submission corresponds to the form instance that was rendered to the requesting visitor. In a correctly implemented flow, the submission should be bound to a specific registered form (and by extension to the post that form targets) so that a user can only affect the form they were shown. Here the handler accepts a form identifier from the submission data and acts on it without validating that the identifier matches the session-bound or rendered form, so a crafted request can point at a different, already registered form and write into the post that form is bound to - changing the post title and content. Because it is a WordPress plugin, the attack surface is HTTP-exposed (AV:N) and the endpoint is unauthenticated (PR:N) with no user interaction (UI:N); however, the attacker must discover a valid alternate form and the post it controls, which is what drives the high attack-complexity rating (AC:H) and keeps the issue low severity. The supplied CPE (cpe:2.3:a:unknown:secure_custom_fields:*:*:*:*:*:*:*:*) carries an unspecified vendor component with no version bounds, so automated CPE-based inventory matching will be unreliable and manual version checks against 6.9.4 are advisable. Impact is confined to integrity of the specific post bound to the abused form - there is no confidentiality or availability component in the assessed vector.
Know when Secure Custom Fields gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Unauthenticated network submission (PR:N/AV:N) but requires targeting a specific form/post binding (AC:H); impact limited to modifying post title/content so I:L, C:N/A:N.
Primary rating from Vendor (WPScan).
CVSS VectorVendor: WPScan
Lifecycle Timeline
3DescriptionCVE.org
The Secure Custom Fields WordPress plugin before 6.9.4 does not properly verify that a front-end form submission corresponds to the form that was rendered to the visitor, allowing unauthenticated users to submit against a different registered form and modify the title and content of the post that form is bound to.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB