CVE-2026-63428 in HeyForm
Summary
by MITRE • 07/20/2026
HeyForm is an open-source form builder. Prior to version 3.0.0-rc.9, `completeSubmission` accepts a `hiddenFields: [{id, name, value}]` array from the submitter and stores it verbatim in `submission.hiddenFields`, without validating the supplied `id`/`name` against the form's declared `form.hiddenFields` schema. An anonymous form submitter can therefore inject arbitrary key/value pairs (including XSS payloads, fake authorization metadata, integration-relevant values) into the stored submission. These fields are subsequently forwarded as-is to every webhook integration registered on the form. Version 3.0.0-rc.9 contains a patch for the issue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
The vulnerability in HeyForm prior to version 3.0.0-rc.9 represents a critical security flaw that enables arbitrary data injection during form submission processes. This issue stems from insufficient input validation within the `completeSubmission` function which accepts a `hiddenFields` array containing key-value pairs from form submitters. The system fails to validate whether the submitted field identifiers and names conform to the predefined schema established by the form's declared `form.hiddenFields` configuration, creating an attack vector where malicious actors can inject unauthorized data fields into the submission record.
The technical implementation of this vulnerability allows for a complete bypass of access controls and data validation mechanisms that should normally restrict what data can be submitted through hidden form fields. When an anonymous user submits a form, they can include arbitrary key-value pairs in the `hiddenFields` array regardless of whether those fields are declared in the form schema. This flaw directly violates security principles of input sanitization and access control enforcement, as the system accepts potentially malicious or unauthorized data without proper verification against established field definitions.
The operational impact of this vulnerability is significant and multifaceted across multiple attack vectors. An attacker can inject XSS payloads through the hidden fields, potentially compromising other users who view the submission data in the admin interface. The vulnerability also enables attackers to inject fake authorization metadata that could bypass access controls or manipulate system behavior. Additionally, the maliciously injected fields are automatically forwarded to all webhook integrations configured on the form, potentially exposing sensitive data or enabling further attacks against integrated systems. This creates a chain reaction where compromised submissions can affect multiple downstream services and applications.
The vulnerability aligns with CWE-20 (Improper Input Validation) and CWE-79 (Cross-Site Scripting) categories, representing a classic case of insufficient validation and sanitization of user-supplied data. From an ATT&CK framework perspective, this issue maps to T1059.008 (Scripting) through potential XSS exploitation and T1078.004 (Valid Accounts) through unauthorized data injection that could manipulate system behavior. The vulnerability also demonstrates characteristics of T1566 (Phishing) as attackers can craft submissions that appear legitimate while containing malicious payloads.
Mitigation strategies should focus on implementing strict input validation before data persistence, ensuring all submitted hidden field identifiers and names match the form's declared schema. The patch in version 3.0.0-rc.9 addresses this by enforcing schema validation against the `form.hiddenFields` configuration. Organizations should also implement proper output encoding for all submission data displayed in web interfaces to prevent XSS exploitation, and consider implementing webhook payload validation to filter out suspicious data before processing. Regular security audits of input handling mechanisms and implementation of automated testing for field validation should be part of ongoing security maintenance practices to prevent similar vulnerabilities from emerging in future releases.