CVE-2026-19872: HTML::FormHandler versions before 0.410000 for Perl allow cross-site scripting via a submitted value rendered unescaped in an error message
HTML::FormHandler versions before 0.410000 for Perl allow cross-site scripting via a submitted value rendered unescaped in an error message.
The wrappers and renderers that emit a form's errors interpolate the error string straight into HTML with no escaping. Two of the library's own messages, nomatch and notallowed, splice the submitted value into that string, and a failing type constraint puts the rejected value into the message it builds, which applyactions hands to adderror.
A field declared with a check regexp, a check list or a type constraint reaches those messages, with no custom validator and no non-default configuration. Errors rendered through an application's own escaping template layer rather than the library's rendering roles are not affected.
A request over the network that submits markup to such a field gets it back live inside the error span, running script in the victim's origin. Re-rendering a rejected value later gives the stored variant.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
HTML::FormHandlerto a version that resolves this vulnerability.Fixed in 0.410000
Event History
Frequently Asked Questions
Which applications are exposed?
Applications using HTML::FormHandler versions before 0.410000 are exposed when they render form errors through the library's wrappers or rendering roles. A field using a check regexp, check list, or type constraint can trigger the vulnerable messages without a custom validator or non-default configuration.
What does an attacker need to do to exploit this?
An attacker needs to submit markup in a network request to a field that produces one of the affected validation errors. When the application re-renders that error through the library renderer, the submitted value is inserted into the error span as live HTML and can execute in the victim's origin.
Are applications using their own templates affected?
Applications whose own template layer escapes error strings are not affected by this rendering issue. The vulnerable behavior is specifically in the library wrappers and renderers that interpolate error text directly into HTML.
What can be done before upgrading?
Render errors through an application template layer that escapes the error string rather than using the affected library rendering roles. Ensure rejected submitted values are HTML-escaped before they are included in rendered error output.
How can I identify stored exposure?
Review whether rejected values are retained and later re-rendered in validation errors, since this produces the stored variant. Also identify fields with check regexps, check lists, or type constraints whose errors are emitted by HTML::FormHandler's rendering roles.