Advanced Custom Fields EUVD-2026-33483

Exploitation is conditional on the WordPress site having at least one page where acf_form() is rendered and accessible to unauthenticated visitors - this requires a deliberate developer configuration choice and is not a default WordPress or ACF behavior. The attacker must be able to reach that specific page over the network and identify a post bound to the form instance. CVSS vector PR:N confirms no authentication is required once a qualifying public form exists. Exploitation is strictly limited to overwriting post_title and post_content of the bound post only; no other post metadata, database tables, filesystem paths, or site configuration are accessible through this vector. Sites using ACF exclusively in the WordPress admin dashboard (wp-admin) are entirely unaffected - the vulnerability exists solely in the front-end form submission path.

The CVSS 5.3 Medium score (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) accurately reflects the constrained impact - only post_title and post_content are modifiable, and only for posts explicitly bound to a public acf_form() instance. The network vector, low complexity, and no-privilege-required flags confirm this is trivially exploitable once a public form is identified. However, real-world risk is highly deployment-dependent: sites using ACF exclusively in the WordPress admin area are entirely unaffected, while sites with public-facing ACF forms face genuine content integrity risk with no meaningful exploitation barrier. No EPSS score was provided in the available data, preventing probabilistic exploitation likelihood assessment. The vulnerability is absent from the CISA KEV catalog and no POC code is referenced, suggesting no confirmed active exploitation at time of analysis. The overall risk profile is moderate-to-high for sites with public acf_form() deployments and low-to-negligible for admin-only ACF usage.

An attacker discovers a WordPress site with a publicly accessible page rendering acf_form() - detectable via page source inspection or automated WordPress scanner. The attacker submits a crafted HTTP POST request to that page, injecting arbitrary strings into the _post_title and _post_content form parameters, and the plugin writes those values directly to the bound post record. No exploit code has been publicly identified at time of analysis, but the attack requires only a basic HTTP client and knowledge of the target post's form binding.