Phoenix.HTML vulnerable to attribute injection via unvalidated attribute names in attributes_escape/1
Affects phoenix_html from 1.0.0 before 3.3.5 and from 4.0.0 before 4.4.0. Fixed in 3.3.5 and 4.4.0.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 3.3.5, 4.4.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Phoenix.HTML library (phoenix_html, used by the Phoenix web framework for Elixir) is affected when applications build HTML attribute names from untrusted input and render them through functions like attributes_escape/1, content_tag/3, or HEEx attribute interpolation. Successful exploitation can let an attacker inject extra attributes and script into generated web pages, enabling cross-site scripting.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in phoenixframework phoenix_html allows an attacker who controls attribute names to inject attributes and script into rendered HTML via Phoenix.HTML.attributes_escape/1. attributes_escape/1 in lib/phoenix_html.ex escapes attribute values but not attribute names. key_escape/1 passes a binary key through html_escape, which neutralizes quotes and angle brackets but not whitespace, so a key such as x onmouseover ends the attribute and starts a new one. An atom key is only dasherized, so any character passes, including quotes and >. Nested data, aria and phx keys take the same paths. An application is affected when it builds attribute keys from untrusted input and renders them through HEEx <tag {@attrs}>, content_tag/3, or a direct call. Before 3.0.0 the same code lived in Phoenix.HTML.Tag. This issue affects phoenix_html: from 1.0.0 before 3.3.5 and from 4.0.0 before 4.4.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- phoenix_html
From 1.0.0 · fixed in 3.3.5; From 4.0.0 · fixed in 4.4.0
- phoenixframework/phoenix_html
Version range not reported
References 5
cna.erlef.org
GitHub · phoenixframework/phoenix_html
Questions about CVE-2026-117645
What does this mean?
The bug lets an attacker who controls attribute names in rendered output add event-handler attributes or close the tag and run script in the browser of users who view the page. The fix is needed because attribute names passed to attributes_escape/1 are not validated.Source: cna.erlef.org
Am I affected, and how do I check?
phoenix_html versions from 1.0.0 before 3.3.5 and from 4.0.0 before 4.4.0. To check a project, look at the phoenix_html version it pins in its dependency lock or dependency list.Source: cna.erlef.org
What should I do about it?
Upgrade phoenix_html to 3.3.5 or later on the 3.x line, or to 4.4.0 or later on the 4.x line. Until then, do not derive attribute names from untrusted input.Source: cna.erlef.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data