CVE-2026-28348
Received Received - Intake
CSS Injection in lxml_html_clean Allows External CSS Loading

Publication date: 2026-03-05

Last updated on: 2026-03-09

Assigner: GitHub, Inc.

Description
lxml_html_clean is a project for HTML cleaning functionalities copied from `lxml.html.clean`. Prior to version 0.4.4, the _has_sneaky_javascript() method strips backslashes before checking for dangerous CSS keywords. This causes CSS Unicode escape sequences to bypass the @import and expression() filters, allowing external CSS loading or XSS in older browsers. This issue has been patched in version 0.4.4.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-05
Last Modified
2026-03-09
Generated
2026-05-27
AI Q&A
2026-03-05
EPSS Evaluated
2026-05-25
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
fedoralovespython lxml_html_clean to 0.4.4 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-116 The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

The vulnerability exists in the lxml_html_clean Python library prior to version 0.4.4, specifically in the _has_sneaky_javascript() method. This method attempts to detect dangerous CSS keywords like @import and expression() by stripping backslashes from CSS strings before checking. However, this approach fails to properly decode CSS Unicode escape sequences, which are sequences starting with a backslash followed by hexadecimal digits representing characters.

Because the method removes backslashes without decoding these sequences, attackers can encode malicious CSS content using Unicode escapes to bypass the filters. For example, an escaped @import statement like `@\69mport` is transformed incorrectly and not detected as dangerous, allowing external CSS loading or cross-site scripting (XSS) in older browsers.

The issue was fixed by implementing a decoding function that converts CSS Unicode escape sequences into their actual characters before performing security checks, ensuring that obfuscated malicious content is detected and blocked.


How can this vulnerability impact me? :

This vulnerability allows attackers to bypass CSS filters by encoding malicious content using Unicode escape sequences. The impact includes:

  • Loading of external CSS files despite filtering, which can be used for data exfiltration such as reading CSRF tokens via CSS attribute selectors.
  • UI redressing and phishing attacks by manipulating the appearance of web pages.
  • In older browsers like Internet Explorer, full cross-site scripting (XSS) attacks are possible through the expression() CSS function bypass.

Overall, the vulnerability can compromise confidentiality and integrity of web applications by allowing malicious CSS injection and script execution.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability involves CSS Unicode escape sequences bypassing filters in the lxml_html_clean library, allowing malicious CSS such as @import or expression() to load external resources or execute scripts.'}, {'type': 'paragraph', 'content': 'To detect exploitation attempts on your system or network, you can monitor for CSS content containing suspicious Unicode escape sequences that represent dangerous keywords like @import or expression().'}, {'type': 'paragraph', 'content': 'Example detection commands could include searching logs or files for CSS strings with backslash escapes followed by hexadecimal digits, such as:'}, {'type': 'list_item', 'content': 'grep -P "\\\\\\\\[0-9a-fA-F]{1,6}" /path/to/css_or_logs'}, {'type': 'list_item', 'content': 'grep -i -P "\\\\\\\\(69|0069|49)mport" /path/to/css_or_logs # Detects Unicode-escaped \'@import\''}, {'type': 'list_item', 'content': 'grep -i -P "\\\\\\\\65xpression" /path/to/css_or_logs # Detects Unicode-escaped \'expression\''}, {'type': 'paragraph', 'content': 'Additionally, monitoring network traffic for unexpected external CSS loads or unusual CSS content with escape sequences may help identify exploitation attempts.'}] [1, 2]


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to upgrade the lxml_html_clean library to version 0.4.4 or later, where the vulnerability has been patched by properly decoding CSS Unicode escape sequences before filtering.

If upgrading immediately is not possible, consider applying the patch that implements the _decode_css_unicode_escapes function to correctly handle Unicode escapes in CSS before security checks.

As a temporary measure, you can also implement additional filtering or validation on CSS inputs to detect and block Unicode-escaped dangerous keywords such as @import and expression().

Finally, monitor your systems and network for suspicious CSS content or external CSS loads that could indicate exploitation attempts.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart