-Infinity
0

Vendor Risk Score

See how lxml compares to other vendors in security performance

View Risk Score →
Severity
8.8
XSS, Command Injection
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:L

Impact The HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs.

Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5.

Patches The issue has been resolved in lxml 4.6.5.

Workarounds None.

References The issues are tracked under the report IDs GHSL-2021-1037 and GHSL-2021-1038.

1 / 5
Source: GitHub

Remedy

Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
First published (updated )
Severity
7.5
Null Pointer Dereference
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.

First published (updated )
Severity
7.5
XEE
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

The HTMLSectionSplitter class in langchain-text-splitters is vulnerable to XML External Entity (XXE) attacks due to unsafe XSLT parsing. This vulnerability arises because the class allows the use of arbitrary XSLT stylesheets, which are parsed using lxml.etree.parse() and lxml.etree.XSLT() without any hardening measures. In lxml versions up to 4.9.x, external entities are resolved by default, allowing attackers to read arbitrary local files or perform outbound HTTP(S) fetches. In lxml versions 5.0 and above, while entity expansion is disabled, the XSLT document() function can still read any URI unless XSLTAccessControl is applied. This vulnerability allows remote attackers to gain read-only access to any file the LangChain process can reach, including sensitive files such as SSH keys, environment files, source code, or cloud metadata. No authentication, special privileges, or user interaction are required, and the issue is exploitable in default deployments that enable custom XSLT.

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
XEE
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Impact Using either of the two parsers in the default configuration (with resolveentities=True) allows untrusted XML input to read local files.

Patches lxml 6.1.0 changes the default to resolveentities='internal', thus disallowing local file access by default.

Workarounds Setting the resolveentities option explicitly to resolveentities='internal' or resolveentities=False disables the local file access.

Resources Original report: https://bugs.launchpad.net/lxml/+bug/2146291

The default option was changed to resolveentities='internal' for the normal XML and HTML parsers in lxml 5.0. The default was not changed for iterparse() and ETCompatXMLParser() at the time. lxml 6.1 makes the safe option the default for all parsers.

1 / 3
Source: GitHub
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

A flaw was found in python-lxml. The HTML5 formaction attribute is not input sanitized like the HTML action attribute is which can lead to a Cross-Site Scripting attack (XSS) when an application uses python-lxml to sanitize user inputs. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

1 / 4
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

A Cross-site Scripting (XSS) vulnerability was found in the python-lxml's clean module. The module's parser did not properly imitate browsers, causing different behaviors between the sanitizer and the user's page. This flaw allows a remote attacker to run arbitrary HTML/JS code. The highest threat from this vulnerability is to confidentiality and integrity.

1 / 4
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

An issue was discovered in lxml before 4.2.5. lxml/html/clean.py in the lxml.html.clean module does not remove javascript: URLs that use escaping, allowing a remote attacker to conduct XSS attacks, as demonstrated by "j a v a s c r i p t:" in Internet Explorer. This is a similar issue to CVE-2014-3146.

1 / 3
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Incomplete blacklist vulnerability in the lxml.html.clean module in lxml before 3.3.5 allows remote attackers to conduct cross-site scripting (XSS) attacks via control characters in the link scheme to the cleanhtml function.

1 / 3
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203