Is there a patch available for EUVD-2026-54080?

Yes, a patch is available for EUVD-2026-54080. Update the affected software to the latest version immediately.

html_sanitize_ex EUVD-2026-54080

Q: What is the CVSS score of EUVD-2026-54080?

EUVD-2026-54080 has a CVSS 4.0 base score of 2.3 (Low). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.5%.

| CVE-2026-66843 LOW

Inclusion of Functionality from Untrusted Control Sphere (CWE-829)

2026-08-06 EEF

GHSA-6g7x-33rf-28v3

XSS Html Sanitize Ex Rrrene

2.3

CVSS 4.0 · Vendor: EEF

Severity by source

Vendor (EEF) PRIMARY

2.3 LOW

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

4.7 MEDIUM

AC:H reflects the additional same-origin file-serving precondition for meaningful impact; S:C captures embedded foreign document loading into trusted page scope; no availability impact applies.

3.1 AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 06, 2026 - 16:18 vuln.today

Analysis Generated

Aug 06, 2026 - 16:18 vuln.today

DescriptionCVE.org

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.5.3.

AnalysisAI

html_sanitize_ex's HTML5 scrubber (versions 0.3.1 through before 1.5.3) passes attacker-controlled URIs through the data attribute of <object> elements after a trivially bypassed case-sensitive prefix check, allowing remote attackers to embed arbitrary external or same-origin documents into sanitized pages viewed by victims. The <object> tag was never registered through the library's allow_tag_with_uri_attributes/3 URI-validation mechanism, and its sole guard - a literal lowercase javascript: prefix match - is defeated by mixed-case variants, data: URIs, protocol-relative URLs, and same-origin relative paths. No public exploit has been identified at time of analysis, and no active exploitation (CISA KEV) has been confirmed; the CVSS 4.0 score of 2.3 correctly reflects constrained real-world impact due to browser-enforced origin isolation on embedded <object> content.

Technical ContextAI

The vulnerability originates in lib/html_sanitize_ex/scrubber/html5.ex within the html_sanitize_ex Elixir library (CPE: cpe:2.3:a:rrrene:html_sanitize_ex). The library's HTML5 scrubber allowlists tags and attributes; URI-carrying attributes on elements such as <a>, <img>, and <source> are validated through allow_tag_with_uri_attributes/3, which enforces comprehensive URI scheme allowlisting. The <object> element was never registered through this mechanism. Its data attribute instead relied on a single Elixir pattern match: {"data", "javascript:" <> _} -> nil, which is both case-sensitive and scheme-incomplete. CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) is the root cause class: the scrubber allows the page to incorporate content from an untrusted URI because the guard does not normalize case, does not enumerate all dangerous schemes (e.g., data:), and does not block protocol-relative (//) or relative (/) paths resolvable to the same origin. The patch (commit bec27fec4de99e40c68c4285a610e09e791a3eaf) replaces the literal match with a case-insensitive regex check that rejects values starting with / and any value containing the substrings javascript or data, closing all documented bypass variants confirmed by six new regression tests.

RemediationAI

Upgrade html_sanitize_ex to version 1.5.3 or later; this is the vendor-confirmed fix version per the GitHub advisory GHSA-xmm9-jc22-rcgj and is delivered by the patch commit at https://github.com/rrrene/html_sanitize_ex/commit/bec27fec4de99e40c68c4285a610e09e791a3eaf. In mix.exs, update the dependency to {:html_sanitize_ex, "~> 1.5.3"} and run mix deps.update html_sanitize_ex. If an immediate upgrade is not feasible, a targeted compensating control is to post-process sanitized output to strip all remaining <object> elements (e.g., via a secondary regex or DOM traversal) before rendering - this eliminates the attack surface entirely but also removes any legitimate <object> usage from user content, which may be an acceptable trade-off in most applications. A softer control - allowlisting only https: URIs in the data attribute via application-layer validation after sanitization - is narrower but more error-prone to implement correctly given the bypass class being exploited.