Everest Forms EUVD-2026-112691

The target site must have at least one Everest Forms form embedded and reachable; no authentication is required (PR:N), because the submission nonce is publicly rendered in every embedded form and can additionally be minted anonymously through the nopriv everest_forms_get_form_update_nonce action. The attacker supplies a hidden form field whose submitted value contains a smart tag such as {post_meta key="..."}; in versions ≤3.6.2 this request-body value is passed through everest_forms_process_smart_tags in class-evf-form-task.php (do_task/entry_save), causing resolution against arbitrary WordPress post meta on any post type. Exploitation requires that the targeted secrets are actually stored in post meta, and the practical limiting factor is the output channel: the resolved value lands in a form notification email or a stored entry, so the attacker must be able to observe or control that destination to complete exfiltration - a detail not specified in the available sources. The patched behavior resolves smart tags strictly from the field's admin-configured default_value, so a crafted request body can no longer inject the tag.

This is a fully unauthenticated, network, low-complexity flaw (CVSS:3.1 AV:N/AC:L/PR:N/UI:N) in a popular WordPress form plugin, which normally argues for elevated priority. However, the confidentiality impact is rated only Low (C:L) with no integrity or availability impact, producing a medium 5.3 base score. There is clear tension between the C:L rating and the description's claim that highly sensitive post meta - license keys, API tokens, SMTP credentials, Stripe/AWS secrets - can be extracted; the most likely reason for C:L rather than C:H is that the resolved secrets surface in form notification emails or stored entries, so the attacker's ability to actually receive the data depends on whether they can observe or control that output channel, which the sources do not fully describe. No EPSS score is provided in the input, so probabilistic exploitation likelihood cannot be weighed. The CVE is not in CISA KEV and no confirmed public exploit code is present (the references are vendor advisory, source-code lines and the patch PR, not weaponized exploit code), so this is 'no public exploit identified at time of analysis'. The vuln.today decision label is 'this_month', consistent with a real but non-emergency priority: trivial exploitability and sensitive data at stake justify prompt patching, but there is no active-exploitation or high-EPSS signal that would make it an emergency.

An unauthenticated attacker locates any embedded Everest Forms form and obtains a valid submission nonce - either the one publicly rendered in the form markup or one freshly minted anonymously via the nopriv everest_forms_get_form_update_nonce AJAX action - then submits the form with a hidden field value containing a crafted smart tag such as {post_meta key="..."}. In versions up to and including 3.6.2 the plugin processes that attacker-submitted value as a smart tag and resolves it against arbitrary WordPress post meta, placing the retrieved secret into the notification email or stored entry. No public exploit code is identified at time of analysis, though the trigger and fix are documented in vendor PR #1669.