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.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| woylie | doggo | unaffected |
|
||||||
| woylie | doggo | unaffected |
|
No data.
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
No data.
No advisories yet.
Solution
No solution given by the vendor.
Workaround
Either of these closes the hole without upgrading. Use type="text" instead of type="date" for fields whose value can come from user-submitted params. The text branch delegates to Phoenix.HTML.Form.normalize_value/2, which returns a bare string that HEEx then escapes. Alternatively, pass an explicit value already validated as an ISO 8601 date rather than letting the component read it from the form field, so the value reaching the unescaped branch contains no metacharacters.
Thu, 27 Aug 2026 18:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Doggo vulnerable to cross-site scripting via unescaped date field values | |
| First Time appeared |
Woylie
Woylie doggo |
|
| Weaknesses | CWE-79 | |
| CPEs | cpe:2.3:a:woylie:doggo:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Woylie
Woylie doggo |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-08-27T16:44:59.553Z
Reserved: 2026-08-25T10:30:01.736Z
Link: CVE-2026-66353
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-08-27T20:18:27.967
Modified: 2026-08-27T20:18:27.967
Link: CVE-2026-66353
Redhat
No data.
OpenCVE Enrichment
Updated: 2026-08-28T07:30:07Z