Summary
HeyForm's upload and static-file serving behavior can allow active HTML to be stored and served from the application's origin. If a victim opens the returned file URL, its script may act with that victim's session and access data available to their account.
HeyForm's upload and static-file serving behavior can allow active HTML to be stored and served from the application's origin. If a victim opens the returned file URL, its script may act with that victim's session and access data available to their account.
Affected context
The issue occurs in HeyForm's /api/upload and static/upload paths. The upload handler relies on a client-controlled multipart MIME type while retaining an HTML filename, and the static serving configuration delivers the file as text/html without a content security policy. The advisory also describes uploads associated with active public forms, but does not fully verify that unauthenticated path end to end.
The issue occurs in HeyForm's /api/upload and static/upload paths. The upload handler relies on a client-controlled multipart MIME type while retaining an HTML filename, and the static serving configuration delivers the file as text/html without a content security policy. The advisory also describes uploads associated with active public forms, but does not fully verify that unauthenticated path end to end.
Exploit preconditions
- Attack surface: The file upload endpoint and the resulting static file URL
- Required access: An ordinary user can upload a file; an unauthenticated public-form route may also be possible, but was not fully verified
- Trigger point: A victim opens the uploaded file's URL in a browser
- Why exploitation is possible: The upload accepts a client-controlled MIME type, and the resulting HTML is served from the HeyForm origin without a content security policy
- Attack surface: The file upload endpoint and the resulting static file URL
- Required access: An ordinary user can upload a file; an unauthenticated public-form route may also be possible, but was not fully verified
- Trigger point: A victim opens the uploaded file's URL in a browser
- Why exploitation is possible: The upload accepts a client-controlled MIME type, and the resulting HTML is served from the HeyForm origin without a content security policy
Why this happens
The application relies on client-provided file metadata when accepting uploads and serves retained HTML filenames as active HTML from its own origin. This creates a stored cross-site scripting condition mapped to CWE-79: Improper Neutralization of Input During Web Page Generation. The unsafe pattern is allowing attacker-controlled content to become executable browser content in a trusted origin.
The application relies on client-provided file metadata when accepting uploads and serves retained HTML filenames as active HTML from its own origin. This creates a stored cross-site scripting condition mapped to CWE-79: Improper Neutralization of Input During Web Page Generation. The unsafe pattern is allowing attacker-controlled content to become executable browser content in a trusted origin.
Potential impact
- Same-origin script could act with the permissions of a victim who opens the file
- An attacker could potentially read or modify data accessible to that victim through
/graphql - Victim account information or actions could be exposed or abused within the account's authorization scope
- Same-origin script could act with the permissions of a victim who opens the file
- An attacker could potentially read or modify data accessible to that victim through
/graphql - Victim account information or actions could be exposed or abused within the account's authorization scope
General mitigation guidance
Defensive patterns include treating uploaded files as untrusted regardless of their declared MIME type, validating content and file types on the server, and avoiding serving user-controlled HTML as active content on the application origin. Consider storing uploads outside the application origin or serving them as downloads with safe content-disposition and content-type policies. Apply an appropriate content security policy as defense in depth, and ensure upload and form permissions follow least privilege.
Defensive patterns include treating uploaded files as untrusted regardless of their declared MIME type, validating content and file types on the server, and avoiding serving user-controlled HTML as active content on the application origin. Consider storing uploads outside the application origin or serving them as downloads with safe content-disposition and content-type policies. Apply an appropriate content security policy as defense in depth, and ensure upload and form permissions follow least privilege.
How teams detect issues like this
- Use static analysis and code review to identify upload decisions based on client-controlled MIME types or filenames.
- Review file-serving routes for user-controlled content served as active HTML on the application origin, especially where CSP is absent or disabled.
- Test upload and public-form authorization boundaries, and verify that uploaded content is delivered with safe browser-handling headers.
- Enforce policies requiring server-side file validation and isolation of untrusted uploads; automated code review tools may help surface risky patterns.
- Use static analysis and code review to identify upload decisions based on client-controlled MIME types or filenames.
- Review file-serving routes for user-controlled content served as active HTML on the application origin, especially where CSP is absent or disabled.
- Test upload and public-form authorization boundaries, and verify that uploaded content is delivered with safe browser-handling headers.
- Enforce policies requiring server-side file validation and isolation of untrusted uploads; automated code review tools may help surface risky patterns.
