Skip to main content

HeyForm CVE-2026-63428

| EUVDEUVD-2026-45985 MEDIUM
Improper Input Validation (CWE-20)
2026-07-20 GitHub_M
5.8
CVSS 3.1 · Vendor: GitHub_M
Share

Severity by source

Vendor (GitHub_M) PRIMARY
5.8 MEDIUM
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N
vuln.today AI
7.2 HIGH

PR:N and UI:N for the core injection; S:C for webhook downstream impact; C:L added over the vendor score to reflect stored XSS credential exfiltration potential.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
None
Integrity
Low
Availability
None

Lifecycle Timeline

3
Source Code Evidence Fetched
Jul 20, 2026 - 18:14 vuln.today
Analysis Generated
Jul 20, 2026 - 18:14 vuln.today
Patch available
Jul 20, 2026 - 17:02 EUVD

DescriptionCVE.org

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.

AnalysisAI

Hidden field injection in HeyForm's form submission API allows anonymous submitters to bypass server-side schema validation and store arbitrary key/value pairs - including XSS payloads and forged authorization metadata - directly into submission records. All HeyForm deployments prior to version 3.0.0-rc.9 are affected. The injected data is subsequently forwarded verbatim to every registered webhook integration, enabling downstream system poisoning and stored XSS against any admin interface that renders submission data. SSVC rates this as automatable with a POC exploit available; no KEV listing at time of analysis.

Technical ContextAI

HeyForm is an open-source TypeScript/Node.js form builder (CPE: cpe:2.3:a:heyform:heyform:*:*:*:*:*:*:*:*). The root cause is CWE-20 (Improper Input Validation): the completeSubmission endpoint accepts a client-supplied hiddenFields: [{id, name, value}] array and persists it directly to submission.hiddenFields without cross-referencing supplied IDs or names against the form's server-authoritative form.hiddenFields schema. The patch commit (092e255e) also reveals a secondary XSS bypass: the previous unsafe-URL regex ^\s*(?:javascript|vbscript|data):/i could be defeated by inserting Unicode control characters (e.g., java\tscript:) within protocol strings. The fix introduces isUnsafeUrlProtocol(), which strips control characters (U+0000-U+001F, U+007F, whitespace) before protocol matching, and updates both answer-utils/html-utils.ts and form-renderer/Block.tsx to use the hardened function. The webhook forwarding pipeline (packages/server/src/apps/webhook.ts) also migrated from assertSafeOutboundUrl to assertSafeOutboundRequest as part of the same security hardening pass.

RemediationAI

Upgrade to HeyForm version 3.0.0-rc.9 or later, which validates client-supplied hiddenFields IDs and names against the form's declared schema before persistence. The patch is available via the upstream commit at https://github.com/heyform/heyform/commit/092e255e9e02565de1b3c057f3dad849160952d2 and documented in the security advisory at https://github.com/heyform/heyform/security/advisories/GHSA-r7vg-xh87-v4w3. For organizations unable to upgrade immediately, disabling all webhook integrations prevents injected field data from reaching downstream systems, though this eliminates integration functionality entirely. Restricting submission endpoints to authenticated users via a reverse proxy (e.g., requiring session cookies before the /api/submit path is reachable) would eliminate the PR:N attack surface, at the cost of blocking public form submissions. Output-encoding all stored hidden field values in admin submission views would mitigate the stored XSS consequence independently of the injection root cause, but would not prevent webhook poisoning.

Share

CVE-2026-63428 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy