Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 6.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An XSS vulnerability was discovered in the python lxml clean module versions before 4.6.3. When disabling the safeattrsonly and forms arguments, the Cleaner class does not remove the formaction attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. This issue is patched in lxml 4.6.3.
Recommended action: Upgrade to 4.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
Recommended action: Upgrade to 4.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.