CVE-2026-66353 in doggo
Summary
by MITRE • 08/27/2026
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in woylie doggo allows Reflected XSS.
Doggo.normalize_value/2 in lib/doggo.ex returned date field values wrapped in {:safe, ...}, the Phoenix.HTML marker meaning "already escaped, emit verbatim", without escaping them, so the value reached the value attribute of the <input> rendered by the field component unchanged. Any application rendering <.field type="date"> over user-controlled params is affected through the ordinary Phoenix form round-trip, where a failed validation re-renders the submitted value. The pattern kept exactly the first ten bytes and discarded shorter values, capping a payload at ten bytes: enough to terminate the attribute and open an element or attach a short event handler, not enough to place attacker-chosen script inline. Only type="date" is affected.
This issue affects doggo: from 0.1.0 before 0.14.8.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified as Improper Neutralization of Input During Web Page Generation, commonly known as Cross-site Scripting or XSS, specifically manifests as a Reflected XSS flaw within the woylie doggo library for Elixir applications utilizing Phoenix HTML. This security defect originates in the Doggo.normalize_value/2 function located in lib/doggo.ex. The core technical failure lies in how this function handles date field values during data normalization processes. Specifically, when processing these fields, the function wraps returned values with the {:safe, ...} tuple marker from Phoenix.HTML. In the context of the Phoenix framework, this marker explicitly instructs the view layer to treat the content as already escaped and safe for direct rendering without applying further HTML escaping mechanisms. Consequently, any user-controlled input provided via form parameters that fails validation is re-rendered by the field component with its original value intact in the value attribute of an HTML element, bypassing standard security sanitization protocols designed to neutralize malicious scripts or event handlers embedded within form inputs.
The operational impact of this vulnerability is constrained by specific technical limitations inherent to the affected implementation pattern. The normalization logic retains only the first ten bytes of the input string while discarding any longer values. This strict length capping significantly restricts the complexity and scope of potential attacks. While an attacker can utilize these ten bytes to terminate the value attribute using a quote character, thereby opening up the HTML tag structure or attaching short event handlers such as onerror or onload, they cannot inject arbitrary inline script content like <script> tags due to the insufficient payload length. This limitation means that while the vulnerability technically allows for DOM manipulation and potential cookie theft via simple event-based triggers if combined with other vectors, it does not permit full-scale remote code execution through direct script injection within this specific field type alone. The flaw exclusively affects inputs of type="date", limiting the attack surface to forms utilizing date pickers or similar HTML5 date input elements where user-submitted data is reflected back into the page structure upon validation failure.
From a classification perspective, this issue aligns with CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). The specific behavior reflects a failure to properly sanitize untrusted data before including it in web pages, leading to reflective XSS where the malicious payload is sent via HTTP request and immediately reflected back by the server. In terms of adversary tactics, this vulnerability can be leveraged within the MITRE ATT&CK framework under techniques related to Client-side Execution or potentially Data Injection depending on how the attacker chains this with other vulnerabilities to achieve broader impact. The persistence of such a flaw in widely used libraries like doggo underscores the importance of rigorous input validation and output encoding practices, particularly when dealing with form data that undergoes round-trip processing where failed validations result in re-rendering user-supplied values without adequate sanitization checks against HTML context boundaries.
Mitigation strategies for this vulnerability require immediate updates to the affected software components. Organizations utilizing doggo versions from 0.1.0 up to but not including 0.14.8 must upgrade to version 0.14.8 or later, where the normalization logic has been corrected to ensure that date field values are properly escaped before being marked as safe for rendering. For applications unable to update immediately due to dependency constraints, developers should implement manual input validation and output encoding layers within their Phoenix controllers or views specifically targeting date fields. This involves ensuring that any user-supplied data intended for form value attributes is explicitly HTML-escaped using standard library functions like Phoenix.HTML.raw/1 with caution or by avoiding the {:safe} wrapper unless absolute certainty of content safety exists. Additionally, implementing Content Security Policy headers can provide a layer of defense-in-depth by restricting the sources from which scripts and other dynamic content are loaded, thereby mitigating the impact if an XSS payload is successfully injected into the DOM through this vector.