Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-49825 (GCVE-0-2026-49825)
Vulnerability from cvelistv5 – Published: 2026-08-20 14:42 – Updated: 2026-08-21 16:41| URL | Tags |
|---|---|
| https://github.com/fedora-python/lxml_html_clean/… | x_refsource_CONFIRM |
| https://github.com/fedora-python/lxml_html_clean/… | x_refsource_MISC |
| https://github.com/lxml/lxml/commit/5927a6d5e8518… | x_refsource_MISC |
| https://github.com/fedora-python/lxml_html_clean/… | x_refsource_MISC |
| https://github.com/lxml/lxml/releases/tag/lxml-6.1.1 | x_refsource_MISC |
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| lxml | lxml |
Affected:
< 6.1.1
|
guessed | |
| fedora-python | lxml_html_clean |
Affected:
< 0.4.5
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-49825",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-21T16:41:32.043801Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-21T16:41:54.849Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "lxml",
"vendor": "lxml",
"versions": [
{
"status": "affected",
"version": "\u003c 6.1.1"
}
]
},
{
"product": "lxml_html_clean",
"vendor": "fedora-python",
"versions": [
{
"status": "affected",
"version": "\u003c 0.4.5"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.1, link attributes in ``lxml.html.defs.link_attrs`` were missing ``xlink:href``, which can be used for URL bypass attacks in embedded SVG/MathML/etc. content. This vulnerability was fixed in lxml 6.1.1 and lxml_html_clean 0.4.5."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-79",
"description": "CWE-79: Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-184",
"description": "CWE-184: Incomplete List of Disallowed Inputs",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-20T14:42:30.748Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"name": "https://github.com/fedora-python/lxml_html_clean/commit/322357ac61c6cf80fcbaba53b4e92e31f3ded9f2",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/fedora-python/lxml_html_clean/commit/322357ac61c6cf80fcbaba53b4e92e31f3ded9f2"
},
{
"name": "https://github.com/lxml/lxml/commit/5927a6d5e851845140975d99b65461e255caaab0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/lxml/lxml/commit/5927a6d5e851845140975d99b65461e255caaab0"
},
{
"name": "https://github.com/fedora-python/lxml_html_clean/releases/tag/0.4.5",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/fedora-python/lxml_html_clean/releases/tag/0.4.5"
},
{
"name": "https://github.com/lxml/lxml/releases/tag/lxml-6.1.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/lxml/lxml/releases/tag/lxml-6.1.1"
}
],
"source": {
"advisory": "GHSA-4jhm-jv67-739f",
"discovery": "UNKNOWN"
},
"title": "lxml: javascript: URL bypass in Cleaner via xlink:href"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-49825",
"datePublished": "2026-08-20T14:42:30.748Z",
"dateReserved": "2026-06-01T18:50:36.055Z",
"dateUpdated": "2026-08-21T16:41:54.849Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-49825",
"date": "2026-10-16",
"epss": "0.00297",
"percentile": "0.20925"
},
"microsoft_vex": {
"current_release_date": "2026-08-21T14:02:34.000Z",
"cve": "CVE-2026-49825",
"id": "msrc_CVE-2026-49825",
"initial_release_date": "2026-08-21T14:02:34.000Z",
"product_status:known_affected": "1",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "lxml: javascript: URL bypass in Cleaner via xlink:href",
"url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-49825.json",
"version": "1"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"product": "lxml",
"vendor": "lxml",
"versions": [
{
"status": "affected",
"version": "\u003c 6.1.1"
}
]
},
{
"product": "lxml_html_clean",
"vendor": "fedora-python",
"versions": [
{
"status": "affected",
"version": "\u003c 0.4.5"
}
]
}
],
"source": "security-advisories@github.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.1, link attributes in ``lxml.html.defs.link_attrs`` were missing ``xlink:href``, which can be used for URL bypass attacks in embedded SVG/MathML/etc. content. This vulnerability was fixed in lxml 6.1.1 and lxml_html_clean 0.4.5."
}
],
"id": "CVE-2026-49825",
"lastModified": "2026-09-18T20:05:53.723",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 4.7,
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-49825",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-21T16:41:32.043801Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-08-20T15:17:30.707",
"references": [
{
"source": "security-advisories@github.com",
"url": "https://github.com/fedora-python/lxml_html_clean/commit/322357ac61c6cf80fcbaba53b4e92e31f3ded9f2"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/fedora-python/lxml_html_clean/releases/tag/0.4.5"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/lxml/lxml/commit/5927a6d5e851845140975d99b65461e255caaab0"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/lxml/lxml/releases/tag/lxml-6.1.1"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Awaiting Analysis",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-79"
},
{
"lang": "en",
"value": "CWE-184"
}
],
"source": "security-advisories@github.com",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Important",
"current_release_date": "2026-10-15T16:08:14+00:00",
"cve": "CVE-2026-49825",
"id": "CVE-2026-49825",
"initial_release_date": "2026-08-20T14:42:30.748000+00:00",
"product_status:fixed": "181",
"product_status:known_affected": "174",
"product_status:known_not_affected": "653",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "lxml: lxml-html-clean: lxml: URL bypass vulnerability in Cleaner via missing xlink:href",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-49825.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-49825",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-21T16:41:32.043801Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-21T16:41:48.876Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "lxml",
"vendor": "lxml",
"versions": [
{
"status": "affected",
"version": "\u003c 6.1.1"
}
]
},
{
"product": "lxml_html_clean",
"vendor": "fedora-python",
"versions": [
{
"status": "affected",
"version": "\u003c 0.4.5"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.1, link attributes in ``lxml.html.defs.link_attrs`` were missing ``xlink:href``, which can be used for URL bypass attacks in embedded SVG/MathML/etc. content. This vulnerability was fixed in lxml 6.1.1 and lxml_html_clean 0.4.5."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-79",
"description": "CWE-79: Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-184",
"description": "CWE-184: Incomplete List of Disallowed Inputs",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-20T14:42:30.748Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"name": "https://github.com/fedora-python/lxml_html_clean/commit/322357ac61c6cf80fcbaba53b4e92e31f3ded9f2",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/fedora-python/lxml_html_clean/commit/322357ac61c6cf80fcbaba53b4e92e31f3ded9f2"
},
{
"name": "https://github.com/lxml/lxml/commit/5927a6d5e851845140975d99b65461e255caaab0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/lxml/lxml/commit/5927a6d5e851845140975d99b65461e255caaab0"
},
{
"name": "https://github.com/fedora-python/lxml_html_clean/releases/tag/0.4.5",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/fedora-python/lxml_html_clean/releases/tag/0.4.5"
},
{
"name": "https://github.com/lxml/lxml/releases/tag/lxml-6.1.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/lxml/lxml/releases/tag/lxml-6.1.1"
}
],
"source": {
"advisory": "GHSA-4jhm-jv67-739f",
"discovery": "UNKNOWN"
},
"title": "lxml: javascript: URL bypass in Cleaner via xlink:href"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-49825",
"datePublished": "2026-08-20T14:42:30.748Z",
"dateReserved": "2026-06-01T18:50:36.055Z",
"dateUpdated": "2026-08-21T16:41:54.849Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
ALSA-2026:66203
Vulnerability from osv_almalinux – Published: 2026-09-09 00:00 – Updated: 2026-09-10 09:13 – Source websitePython is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems.
Security Fix(es):
- lxml: lxml-html-clean: lxml: URL bypass vulnerability in Cleaner via missing xlink:href (CVE-2026-49825)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
{
"affected": [
{
"package": {
"ecosystem": "AlmaLinux:9",
"name": "python3.12-lxml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.9.3-2.el9_8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"details": "Python is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems. \n\nSecurity Fix(es): \n\n * lxml: lxml-html-clean: lxml: URL bypass vulnerability in Cleaner via missing xlink:href (CVE-2026-49825)\n\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.\n",
"id": "ALSA-2026:66203",
"modified": "2026-09-10T09:13:44Z",
"published": "2026-09-09T00:00:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://access.redhat.com/errata/RHSA-2026:66203"
},
{
"type": "REPORT",
"url": "https://access.redhat.com/security/cve/CVE-2026-49825"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/2520368"
},
{
"type": "ADVISORY",
"url": "https://errata.almalinux.org/9/ALSA-2026-66203.html"
}
],
"related": [
"CVE-2026-49825"
],
"summary": "Important: python3.12-lxml security update"
}
ALSA-2026:66204
Vulnerability from osv_almalinux – Published: 2026-09-09 00:00 – Updated: 2026-09-10 09:13 – Source websitePython is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems.
Security Fix(es):
- lxml: lxml-html-clean: lxml: URL bypass vulnerability in Cleaner via missing xlink:href (CVE-2026-49825)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
{
"affected": [
{
"package": {
"ecosystem": "AlmaLinux:9",
"name": "python3-lxml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.6.5-3.el9_8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"details": "Python is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems. \n\nSecurity Fix(es): \n\n * lxml: lxml-html-clean: lxml: URL bypass vulnerability in Cleaner via missing xlink:href (CVE-2026-49825)\n\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.\n",
"id": "ALSA-2026:66204",
"modified": "2026-09-10T09:13:43Z",
"published": "2026-09-09T00:00:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://access.redhat.com/errata/RHSA-2026:66204"
},
{
"type": "REPORT",
"url": "https://access.redhat.com/security/cve/CVE-2026-49825"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/2520368"
},
{
"type": "ADVISORY",
"url": "https://errata.almalinux.org/9/ALSA-2026-66204.html"
}
],
"related": [
"CVE-2026-49825"
],
"summary": "Important: python-lxml security update"
}
ALSA-2026:67943
Vulnerability from osv_almalinux – Published: 2026-09-16 00:00 – Updated: 2026-09-16 13:25 – Source websitePython is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems.
Security Fix(es):
- lxml: lxml-html-clean: lxml: URL bypass vulnerability in Cleaner via missing xlink:href (CVE-2026-49825)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
{
"affected": [
{
"package": {
"ecosystem": "AlmaLinux:8",
"name": "python3-lxml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.3-5.el8_10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"details": "Python is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems. \n\nSecurity Fix(es): \n\n * lxml: lxml-html-clean: lxml: URL bypass vulnerability in Cleaner via missing xlink:href (CVE-2026-49825)\n\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.\n",
"id": "ALSA-2026:67943",
"modified": "2026-09-16T13:25:38Z",
"published": "2026-09-16T00:00:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://access.redhat.com/errata/RHSA-2026:67943"
},
{
"type": "REPORT",
"url": "https://access.redhat.com/security/cve/CVE-2026-49825"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/2520368"
},
{
"type": "ADVISORY",
"url": "https://errata.almalinux.org/8/ALSA-2026-67943.html"
}
],
"related": [
"CVE-2026-49825"
],
"summary": "Important: python-lxml security update"
}
BREW-GPTLINE-CVE-2026-49825 (GHSA-4JHM-JV67-739F)
Vulnerability from osv_homebrew – Published: 2026-08-13 16:54 – Updated: 2026-10-08 00:55 – Source websitelxml_html_clean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href)
Reporter: Guillem Lefait guillem@datamq.com · Date: 2026-05-10
Affected: lxml ≤ 6.1.0 and lxml_html_clean ≤ 0.4.4 (latest stable)
Confirmed against: lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 — bug is in pure-Python sanitizer logic, independent of the libxml2 backend)
Root-cause class: same as CVE-2021-28957 (formaction missing from link_attrs)
Summary
Cleaner filters URL schemes (javascript:, vbscript:, …) by walking links via rewrite_links(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.link_attrs. That allow-list contains no prefixed names (xlink:href) and no srcset. As a result, when Cleaner is configured with safe_attrs_only=False — a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing — <a xlink:href="javascript:…"> survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.
CWE: CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.
Affected components
| Package | Versions tested | File / line |
|---|---|---|
lxml |
4.9.x, 5.2.1, 6.1.0 | src/lxml/html/defs.py:20 |
lxml |
" | src/lxml/html/__init__.py:485-528 |
lxml_html_clean |
0.4.0 – 0.4.4 | lxml_html_clean/clean.py:348,576 |
The legacy lxml.html.clean module — bundled in lxml < 5.2.0 and still installable on newer versions via the lxml[html_clean] extra — shares the same bug.
Root cause
defs.link_attrs is a flat string set; the literal xlink:href is absent:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
])
HtmlMixin.iterlinks() (lxml/html/__init__.py:526-528) only yields attributes whose key is in that set:
for attrib in link_attrs:
if attrib in attribs:
yield (el, attrib, attribs[attrib], 0)
Cleaner.__call__ registers the URL-scheme filter via rewrite_links (lxml_html_clean/clean.py:348), which is a thin wrapper around iterlinks(). Because xlink:href is never yielded, _remove_javascript_link (clean.py:576) is never invoked for it.
Minimal reproducer
from lxml import html
from lxml_html_clean import Cleaner
for payload in (
'<svg><a xlink:href="javascript:alert(1)">x</a></svg>',
'<math><a xlink:href="javascript:alert(2)">y</a></math>',
):
tree = html.fromstring(payload)
Cleaner(safe_attrs_only=False)(tree)
print(html.tostring(tree).decode())
print(' iterlinks:', list(html.fromstring(payload).iterlinks()))
# <svg><a xlink:href="javascript:alert(1)">x</a></svg> ← unchanged
# iterlinks: [] ← link rewriter blind
# <math><a xlink:href="javascript:alert(2)">y</a></math> ← unchanged
# iterlinks: [] ← link rewriter blind
Both SVG and MathML scopes are vulnerable — same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (JaVaScRiPt:), HTML-entity (javascript:), embedded tab (java\tscript:).
Impact
A caller that uses Cleaner to neutralise untrusted HTML and chooses safe_attrs_only=False — typically because the application wants to allow custom data-/aria-/vendor attributes — will silently pass javascript: payloads carried on xlink:href through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the safe_attrs_only=False toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.
Suggested fix
Extend link_attrs to include xlink:href. In HTML mode, lxml.html keeps prefixed attribute names verbatim — the parsed key is the literal string xlink:href, not a Clark-notation form — so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
+ 'xlink:href',
])
This single change closes the reported XSS for both SVG <a xlink:href> and MathML <a xlink:href>. lxml_html_clean is the canonical home of the Cleaner code (881 lines); lxml.html.clean is a 21-line backward-compat shim (from lxml_html_clean import *) that picks up the fix automatically once link_attrs is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in lxml_html_clean is preferred.
Alternative (in-package fix, no lxml coordination needed): add a namespaced-URL-attribute walk inside Cleaner.__call__ so the URL-scheme filter doesn't depend on link_attrs. Sketch:
# lxml_html_clean/clean.py — supplements rewrite_links() in __call__
_NS_URL_ATTRS = ('xlink:href',) # extend as needed
_BAD_SCHEME = re.compile(r'^\s*(javascript|vbscript|data):', re.I)
for el in doc.iter():
for attr in _NS_URL_ATTRS:
if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):
del el.attrib[attr]
This decouples the cleaner from the upstream link_attrs set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.
Defense in depth (optional, regardless of which fix path is taken):
- Also handle srcset: the value is a url 1x, url 2x, … descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.
- Also accept Clark-notation forms ({http://www.w3.org/1999/xlink}href) so XML-mode callers using lxml.etree get the same protection. HTML mode never produces this form, so not needed for the reported bug.
Severity
CVSS 3.1 base score: 8.2 / High — AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (→ 7.6).
Severity is CONDITIONAL on the caller passing safe_attrs_only=False. With the class default (True), attribute allow-listing strips xlink:href before scheme scrubbing runs, and the bug does not fire — verified at HEAD: default-config Cleaner()(<svg><a xlink:href="javascript:…">x</a></svg>) → <svg><a>x</a></svg>.
Prior art / novelty
- CVE-2021-28957 (lxml 4.6.3) — same root cause, different attribute (
formaction). Fix was a one-line extension oflink_attrs. Direct precedent. - CVE-2022-34473 (Mozilla Sanitizer API) —
xlink:hrefURL bypass primitive in a different sanitizer. - Bleach (Mozilla, Python) explicitly handles the
xlinknamespace;enshrined/svg-sanitize(PHP) shipscleanXlinkHrefs(); DOMPurify scrubsxlink:hrefviaALLOWED_URI_REGEXP. nh3(the alternative recommended inlxml_html_clean's own README for security-sensitive use) is not vulnerable to this primitive — verified 2026-05-10 onnh3==0.3.5: with<svg>/<math>/<a>andxlink:hrefexplicitly added totags/attributes, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g.<svg><a rel="noopener noreferrer">x</a></svg>).
Coordination
Filing as a private GHSA at fedora-python/lxml_html_clean — lxml_html_clean is the canonical maintainer of the Cleaner code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (https://github.com/lxml/lxml/security/advisories/new returns 404 — private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream defs.link_attrs patch path. You're welcome to coordinate with them directly if you'd prefer the upstream fix over the in-package alternative above.
Happy to provide a draft patch or PR on either path. No bounty expected.
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "lxml-html-clean",
"resource_purl": "pkg:pypi/lxml-html-clean@0.4.5",
"upstream_fixed_in": "0.4.5"
},
"package": {
"ecosystem": "Homebrew",
"name": "gptline",
"purl": "pkg:brew/gptline"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.8_4"
},
{
"fixed": "1.0.8_22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/lxml-html-clean@0.4.5",
"name": "lxml-html-clean",
"resource": "lxml-html-clean",
"strategy": "registry",
"subject_version": "0.4.5"
}
]
},
"details": "# `lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes (`xlink:href`)\n\n**Reporter:** Guillem Lefait \u003cguillem@datamq.com\u003e \u00b7 **Date:** 2026-05-10\n**Affected:** `lxml` \u2264 6.1.0 and `lxml_html_clean` \u2264 0.4.4 (latest stable)\n**Confirmed against:** lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 \u2014 bug is in pure-Python sanitizer logic, independent of the libxml2 backend)\n**Root-cause class:** same as CVE-2021-28957 (`formaction` missing from `link_attrs`)\n\n## Summary\n\n`Cleaner` filters URL schemes (`javascript:`, `vbscript:`, \u2026) by walking links via `rewrite_links()`, which delegates to `iterlinks()`, which only yields attributes named in `lxml.html.defs.link_attrs`. That allow-list contains no prefixed names (`xlink:href`) and no `srcset`. As a result, when `Cleaner` is configured with `safe_attrs_only=False` \u2014 a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing \u2014 `\u003ca xlink:href=\"javascript:\u2026\"\u003e` survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.\n\n**CWE:** CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.\n\n## Affected components\n\n| Package | Versions tested | File / line |\n|--------------------|------------------------|----------------------------------|\n| `lxml` | 4.9.x, 5.2.1, 6.1.0 | `src/lxml/html/defs.py:20` |\n| `lxml` | \" | `src/lxml/html/__init__.py:485-528` |\n| `lxml_html_clean` | 0.4.0 \u2013 0.4.4 | `lxml_html_clean/clean.py:348,576` |\n\nThe legacy `lxml.html.clean` module \u2014 bundled in `lxml \u003c 5.2.0` and still installable on newer versions via the `lxml[html_clean]` extra \u2014 shares the same bug.\n\n## Root cause\n\n`defs.link_attrs` is a flat string set; the literal `xlink:href` is absent:\n\n```python\n# lxml/html/defs.py\nlink_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n])\n```\n\n`HtmlMixin.iterlinks()` (`lxml/html/__init__.py:526-528`) only yields attributes whose key is in that set:\n\n```python\nfor attrib in link_attrs:\n if attrib in attribs:\n yield (el, attrib, attribs[attrib], 0)\n```\n\n`Cleaner.__call__` registers the URL-scheme filter via `rewrite_links` (`lxml_html_clean/clean.py:348`), which is a thin wrapper around `iterlinks()`. Because `xlink:href` is never yielded, `_remove_javascript_link` (`clean.py:576`) is never invoked for it.\n\n## Minimal reproducer\n\n```python\nfrom lxml import html\nfrom lxml_html_clean import Cleaner\n\nfor payload in (\n \u0027\u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e\u0027,\n \u0027\u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e\u0027,\n):\n tree = html.fromstring(payload)\n Cleaner(safe_attrs_only=False)(tree)\n print(html.tostring(tree).decode())\n print(\u0027 iterlinks:\u0027, list(html.fromstring(payload).iterlinks()))\n# \u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n# \u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n```\n\nBoth SVG and MathML scopes are vulnerable \u2014 same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (`JaVaScRiPt:`), HTML-entity (`java\u0026#x73;cript:`), embedded tab (`java\\tscript:`).\n\n## Impact\n\nA caller that uses `Cleaner` to neutralise untrusted HTML and chooses `safe_attrs_only=False` \u2014 typically because the application wants to allow custom data-/aria-/vendor attributes \u2014 will silently pass `javascript:` payloads carried on `xlink:href` through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the `safe_attrs_only=False` toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.\n\n## Suggested fix\n\n**Extend `link_attrs`** to include `xlink:href`. In HTML mode, `lxml.html` keeps prefixed attribute names verbatim \u2014 the parsed key is the literal string `xlink:href`, not a Clark-notation form \u2014 so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:\n\n```diff\n # lxml/html/defs.py\n link_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n+ \u0027xlink:href\u0027,\n ])\n```\n\nThis single change closes the reported XSS for both SVG `\u003ca xlink:href\u003e` and MathML `\u003ca xlink:href\u003e`. `lxml_html_clean` is the canonical home of the `Cleaner` code (881 lines); `lxml.html.clean` is a 21-line backward-compat shim (`from lxml_html_clean import *`) that picks up the fix automatically once `link_attrs` is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in `lxml_html_clean` is preferred.\n\n**Alternative (in-package fix, no lxml coordination needed):** add a namespaced-URL-attribute walk inside `Cleaner.__call__` so the URL-scheme filter doesn\u0027t depend on `link_attrs`. Sketch:\n\n```python\n# lxml_html_clean/clean.py \u2014 supplements rewrite_links() in __call__\n_NS_URL_ATTRS = (\u0027xlink:href\u0027,) # extend as needed\n_BAD_SCHEME = re.compile(r\u0027^\\s*(javascript|vbscript|data):\u0027, re.I)\n\nfor el in doc.iter():\n for attr in _NS_URL_ATTRS:\n if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):\n del el.attrib[attr]\n```\n\nThis decouples the cleaner from the upstream `link_attrs` set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.\n\n**Defense in depth (optional, regardless of which fix path is taken):**\n- Also handle `srcset`: the value is a `url 1x, url 2x, \u2026` descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.\n- Also accept Clark-notation forms (`{http://www.w3.org/1999/xlink}href`) so XML-mode callers using `lxml.etree` get the same protection. HTML mode never produces this form, so not needed for the reported bug.\n\n## Severity\n\nCVSS 3.1 base score: **8.2 / High** \u2014 `AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N` (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (\u2192 7.6).\n\nSeverity is **CONDITIONAL** on the caller passing `safe_attrs_only=False`. With the class default (`True`), attribute allow-listing strips `xlink:href` before scheme scrubbing runs, and the bug does not fire \u2014 verified at HEAD: default-config `Cleaner()(\u003csvg\u003e\u003ca xlink:href=\"javascript:\u2026\"\u003ex\u003c/a\u003e\u003c/svg\u003e)` \u2192 `\u003csvg\u003e\u003ca\u003ex\u003c/a\u003e\u003c/svg\u003e`.\n\n## Prior art / novelty\n\n- **CVE-2021-28957 (lxml 4.6.3)** \u2014 same root cause, different attribute (`formaction`). Fix was a one-line extension of `link_attrs`. Direct precedent.\n- **CVE-2022-34473** (Mozilla Sanitizer API) \u2014 `xlink:href` URL bypass primitive in a different sanitizer.\n- **Bleach (Mozilla, Python)** explicitly handles the `xlink` namespace; `enshrined/svg-sanitize` (PHP) ships `cleanXlinkHrefs()`; DOMPurify scrubs `xlink:href` via `ALLOWED_URI_REGEXP`.\n- **`nh3`** (the alternative recommended in `lxml_html_clean`\u0027s own README for security-sensitive use) is **not vulnerable** to this primitive \u2014 verified 2026-05-10 on `nh3==0.3.5`: with `\u003csvg\u003e`/`\u003cmath\u003e`/`\u003ca\u003e` and `xlink:href` explicitly added to `tags`/`attributes`, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g. `\u003csvg\u003e\u003ca rel=\"noopener noreferrer\"\u003ex\u003c/a\u003e\u003c/svg\u003e`).\n\n\n## Coordination\n\nFiling as a private GHSA at `fedora-python/lxml_html_clean` \u2014 `lxml_html_clean` is the canonical maintainer of the `Cleaner` code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (`https://github.com/lxml/lxml/security/advisories/new` returns 404 \u2014 private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream `defs.link_attrs` patch path. You\u0027re welcome to coordinate with them directly if you\u0027d prefer the upstream fix over the in-package alternative above.\n\nHappy to provide a draft patch or PR on either path. No bounty expected.",
"id": "BREW-gptline-CVE-2026-49825",
"modified": "2026-10-08T00:55:33Z",
"published": "2026-08-13T16:54:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"type": "PACKAGE",
"url": "https://github.com/fedora-python/lxml_html_clean"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "`lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes",
"upstream": [
"GHSA-4jhm-jv67-739f",
"CVE-2026-49825",
"PYSEC-2026-2614"
]
}
BREW-KIMI-CLI-CVE-2026-49825 (GHSA-4JHM-JV67-739F)
Vulnerability from osv_homebrew – Published: 2026-08-13 17:01 – Updated: 2026-10-08 01:19 – Source websitelxml_html_clean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href)
Reporter: Guillem Lefait guillem@datamq.com · Date: 2026-05-10
Affected: lxml ≤ 6.1.0 and lxml_html_clean ≤ 0.4.4 (latest stable)
Confirmed against: lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 — bug is in pure-Python sanitizer logic, independent of the libxml2 backend)
Root-cause class: same as CVE-2021-28957 (formaction missing from link_attrs)
Summary
Cleaner filters URL schemes (javascript:, vbscript:, …) by walking links via rewrite_links(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.link_attrs. That allow-list contains no prefixed names (xlink:href) and no srcset. As a result, when Cleaner is configured with safe_attrs_only=False — a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing — <a xlink:href="javascript:…"> survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.
CWE: CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.
Affected components
| Package | Versions tested | File / line |
|---|---|---|
lxml |
4.9.x, 5.2.1, 6.1.0 | src/lxml/html/defs.py:20 |
lxml |
" | src/lxml/html/__init__.py:485-528 |
lxml_html_clean |
0.4.0 – 0.4.4 | lxml_html_clean/clean.py:348,576 |
The legacy lxml.html.clean module — bundled in lxml < 5.2.0 and still installable on newer versions via the lxml[html_clean] extra — shares the same bug.
Root cause
defs.link_attrs is a flat string set; the literal xlink:href is absent:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
])
HtmlMixin.iterlinks() (lxml/html/__init__.py:526-528) only yields attributes whose key is in that set:
for attrib in link_attrs:
if attrib in attribs:
yield (el, attrib, attribs[attrib], 0)
Cleaner.__call__ registers the URL-scheme filter via rewrite_links (lxml_html_clean/clean.py:348), which is a thin wrapper around iterlinks(). Because xlink:href is never yielded, _remove_javascript_link (clean.py:576) is never invoked for it.
Minimal reproducer
from lxml import html
from lxml_html_clean import Cleaner
for payload in (
'<svg><a xlink:href="javascript:alert(1)">x</a></svg>',
'<math><a xlink:href="javascript:alert(2)">y</a></math>',
):
tree = html.fromstring(payload)
Cleaner(safe_attrs_only=False)(tree)
print(html.tostring(tree).decode())
print(' iterlinks:', list(html.fromstring(payload).iterlinks()))
# <svg><a xlink:href="javascript:alert(1)">x</a></svg> ← unchanged
# iterlinks: [] ← link rewriter blind
# <math><a xlink:href="javascript:alert(2)">y</a></math> ← unchanged
# iterlinks: [] ← link rewriter blind
Both SVG and MathML scopes are vulnerable — same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (JaVaScRiPt:), HTML-entity (javascript:), embedded tab (java\tscript:).
Impact
A caller that uses Cleaner to neutralise untrusted HTML and chooses safe_attrs_only=False — typically because the application wants to allow custom data-/aria-/vendor attributes — will silently pass javascript: payloads carried on xlink:href through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the safe_attrs_only=False toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.
Suggested fix
Extend link_attrs to include xlink:href. In HTML mode, lxml.html keeps prefixed attribute names verbatim — the parsed key is the literal string xlink:href, not a Clark-notation form — so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
+ 'xlink:href',
])
This single change closes the reported XSS for both SVG <a xlink:href> and MathML <a xlink:href>. lxml_html_clean is the canonical home of the Cleaner code (881 lines); lxml.html.clean is a 21-line backward-compat shim (from lxml_html_clean import *) that picks up the fix automatically once link_attrs is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in lxml_html_clean is preferred.
Alternative (in-package fix, no lxml coordination needed): add a namespaced-URL-attribute walk inside Cleaner.__call__ so the URL-scheme filter doesn't depend on link_attrs. Sketch:
# lxml_html_clean/clean.py — supplements rewrite_links() in __call__
_NS_URL_ATTRS = ('xlink:href',) # extend as needed
_BAD_SCHEME = re.compile(r'^\s*(javascript|vbscript|data):', re.I)
for el in doc.iter():
for attr in _NS_URL_ATTRS:
if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):
del el.attrib[attr]
This decouples the cleaner from the upstream link_attrs set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.
Defense in depth (optional, regardless of which fix path is taken):
- Also handle srcset: the value is a url 1x, url 2x, … descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.
- Also accept Clark-notation forms ({http://www.w3.org/1999/xlink}href) so XML-mode callers using lxml.etree get the same protection. HTML mode never produces this form, so not needed for the reported bug.
Severity
CVSS 3.1 base score: 8.2 / High — AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (→ 7.6).
Severity is CONDITIONAL on the caller passing safe_attrs_only=False. With the class default (True), attribute allow-listing strips xlink:href before scheme scrubbing runs, and the bug does not fire — verified at HEAD: default-config Cleaner()(<svg><a xlink:href="javascript:…">x</a></svg>) → <svg><a>x</a></svg>.
Prior art / novelty
- CVE-2021-28957 (lxml 4.6.3) — same root cause, different attribute (
formaction). Fix was a one-line extension oflink_attrs. Direct precedent. - CVE-2022-34473 (Mozilla Sanitizer API) —
xlink:hrefURL bypass primitive in a different sanitizer. - Bleach (Mozilla, Python) explicitly handles the
xlinknamespace;enshrined/svg-sanitize(PHP) shipscleanXlinkHrefs(); DOMPurify scrubsxlink:hrefviaALLOWED_URI_REGEXP. nh3(the alternative recommended inlxml_html_clean's own README for security-sensitive use) is not vulnerable to this primitive — verified 2026-05-10 onnh3==0.3.5: with<svg>/<math>/<a>andxlink:hrefexplicitly added totags/attributes, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g.<svg><a rel="noopener noreferrer">x</a></svg>).
Coordination
Filing as a private GHSA at fedora-python/lxml_html_clean — lxml_html_clean is the canonical maintainer of the Cleaner code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (https://github.com/lxml/lxml/security/advisories/new returns 404 — private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream defs.link_attrs patch path. You're welcome to coordinate with them directly if you'd prefer the upstream fix over the in-package alternative above.
Happy to provide a draft patch or PR on either path. No bounty expected.
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "lxml-html-clean",
"resource_purl": "pkg:pypi/lxml-html-clean@0.4.4",
"upstream_fixed_in": "0.4.5"
},
"package": {
"ecosystem": "Homebrew",
"name": "kimi-cli",
"purl": "pkg:brew/kimi-cli"
},
"ranges": [
{
"events": [
{
"introduced": "0.40"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/lxml-html-clean@0.4.4",
"name": "lxml-html-clean",
"resource": "lxml-html-clean",
"strategy": "registry",
"subject_version": "0.4.4"
}
]
},
"details": "# `lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes (`xlink:href`)\n\n**Reporter:** Guillem Lefait \u003cguillem@datamq.com\u003e \u00b7 **Date:** 2026-05-10\n**Affected:** `lxml` \u2264 6.1.0 and `lxml_html_clean` \u2264 0.4.4 (latest stable)\n**Confirmed against:** lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 \u2014 bug is in pure-Python sanitizer logic, independent of the libxml2 backend)\n**Root-cause class:** same as CVE-2021-28957 (`formaction` missing from `link_attrs`)\n\n## Summary\n\n`Cleaner` filters URL schemes (`javascript:`, `vbscript:`, \u2026) by walking links via `rewrite_links()`, which delegates to `iterlinks()`, which only yields attributes named in `lxml.html.defs.link_attrs`. That allow-list contains no prefixed names (`xlink:href`) and no `srcset`. As a result, when `Cleaner` is configured with `safe_attrs_only=False` \u2014 a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing \u2014 `\u003ca xlink:href=\"javascript:\u2026\"\u003e` survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.\n\n**CWE:** CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.\n\n## Affected components\n\n| Package | Versions tested | File / line |\n|--------------------|------------------------|----------------------------------|\n| `lxml` | 4.9.x, 5.2.1, 6.1.0 | `src/lxml/html/defs.py:20` |\n| `lxml` | \" | `src/lxml/html/__init__.py:485-528` |\n| `lxml_html_clean` | 0.4.0 \u2013 0.4.4 | `lxml_html_clean/clean.py:348,576` |\n\nThe legacy `lxml.html.clean` module \u2014 bundled in `lxml \u003c 5.2.0` and still installable on newer versions via the `lxml[html_clean]` extra \u2014 shares the same bug.\n\n## Root cause\n\n`defs.link_attrs` is a flat string set; the literal `xlink:href` is absent:\n\n```python\n# lxml/html/defs.py\nlink_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n])\n```\n\n`HtmlMixin.iterlinks()` (`lxml/html/__init__.py:526-528`) only yields attributes whose key is in that set:\n\n```python\nfor attrib in link_attrs:\n if attrib in attribs:\n yield (el, attrib, attribs[attrib], 0)\n```\n\n`Cleaner.__call__` registers the URL-scheme filter via `rewrite_links` (`lxml_html_clean/clean.py:348`), which is a thin wrapper around `iterlinks()`. Because `xlink:href` is never yielded, `_remove_javascript_link` (`clean.py:576`) is never invoked for it.\n\n## Minimal reproducer\n\n```python\nfrom lxml import html\nfrom lxml_html_clean import Cleaner\n\nfor payload in (\n \u0027\u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e\u0027,\n \u0027\u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e\u0027,\n):\n tree = html.fromstring(payload)\n Cleaner(safe_attrs_only=False)(tree)\n print(html.tostring(tree).decode())\n print(\u0027 iterlinks:\u0027, list(html.fromstring(payload).iterlinks()))\n# \u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n# \u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n```\n\nBoth SVG and MathML scopes are vulnerable \u2014 same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (`JaVaScRiPt:`), HTML-entity (`java\u0026#x73;cript:`), embedded tab (`java\\tscript:`).\n\n## Impact\n\nA caller that uses `Cleaner` to neutralise untrusted HTML and chooses `safe_attrs_only=False` \u2014 typically because the application wants to allow custom data-/aria-/vendor attributes \u2014 will silently pass `javascript:` payloads carried on `xlink:href` through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the `safe_attrs_only=False` toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.\n\n## Suggested fix\n\n**Extend `link_attrs`** to include `xlink:href`. In HTML mode, `lxml.html` keeps prefixed attribute names verbatim \u2014 the parsed key is the literal string `xlink:href`, not a Clark-notation form \u2014 so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:\n\n```diff\n # lxml/html/defs.py\n link_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n+ \u0027xlink:href\u0027,\n ])\n```\n\nThis single change closes the reported XSS for both SVG `\u003ca xlink:href\u003e` and MathML `\u003ca xlink:href\u003e`. `lxml_html_clean` is the canonical home of the `Cleaner` code (881 lines); `lxml.html.clean` is a 21-line backward-compat shim (`from lxml_html_clean import *`) that picks up the fix automatically once `link_attrs` is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in `lxml_html_clean` is preferred.\n\n**Alternative (in-package fix, no lxml coordination needed):** add a namespaced-URL-attribute walk inside `Cleaner.__call__` so the URL-scheme filter doesn\u0027t depend on `link_attrs`. Sketch:\n\n```python\n# lxml_html_clean/clean.py \u2014 supplements rewrite_links() in __call__\n_NS_URL_ATTRS = (\u0027xlink:href\u0027,) # extend as needed\n_BAD_SCHEME = re.compile(r\u0027^\\s*(javascript|vbscript|data):\u0027, re.I)\n\nfor el in doc.iter():\n for attr in _NS_URL_ATTRS:\n if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):\n del el.attrib[attr]\n```\n\nThis decouples the cleaner from the upstream `link_attrs` set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.\n\n**Defense in depth (optional, regardless of which fix path is taken):**\n- Also handle `srcset`: the value is a `url 1x, url 2x, \u2026` descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.\n- Also accept Clark-notation forms (`{http://www.w3.org/1999/xlink}href`) so XML-mode callers using `lxml.etree` get the same protection. HTML mode never produces this form, so not needed for the reported bug.\n\n## Severity\n\nCVSS 3.1 base score: **8.2 / High** \u2014 `AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N` (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (\u2192 7.6).\n\nSeverity is **CONDITIONAL** on the caller passing `safe_attrs_only=False`. With the class default (`True`), attribute allow-listing strips `xlink:href` before scheme scrubbing runs, and the bug does not fire \u2014 verified at HEAD: default-config `Cleaner()(\u003csvg\u003e\u003ca xlink:href=\"javascript:\u2026\"\u003ex\u003c/a\u003e\u003c/svg\u003e)` \u2192 `\u003csvg\u003e\u003ca\u003ex\u003c/a\u003e\u003c/svg\u003e`.\n\n## Prior art / novelty\n\n- **CVE-2021-28957 (lxml 4.6.3)** \u2014 same root cause, different attribute (`formaction`). Fix was a one-line extension of `link_attrs`. Direct precedent.\n- **CVE-2022-34473** (Mozilla Sanitizer API) \u2014 `xlink:href` URL bypass primitive in a different sanitizer.\n- **Bleach (Mozilla, Python)** explicitly handles the `xlink` namespace; `enshrined/svg-sanitize` (PHP) ships `cleanXlinkHrefs()`; DOMPurify scrubs `xlink:href` via `ALLOWED_URI_REGEXP`.\n- **`nh3`** (the alternative recommended in `lxml_html_clean`\u0027s own README for security-sensitive use) is **not vulnerable** to this primitive \u2014 verified 2026-05-10 on `nh3==0.3.5`: with `\u003csvg\u003e`/`\u003cmath\u003e`/`\u003ca\u003e` and `xlink:href` explicitly added to `tags`/`attributes`, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g. `\u003csvg\u003e\u003ca rel=\"noopener noreferrer\"\u003ex\u003c/a\u003e\u003c/svg\u003e`).\n\n\n## Coordination\n\nFiling as a private GHSA at `fedora-python/lxml_html_clean` \u2014 `lxml_html_clean` is the canonical maintainer of the `Cleaner` code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (`https://github.com/lxml/lxml/security/advisories/new` returns 404 \u2014 private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream `defs.link_attrs` patch path. You\u0027re welcome to coordinate with them directly if you\u0027d prefer the upstream fix over the in-package alternative above.\n\nHappy to provide a draft patch or PR on either path. No bounty expected.",
"id": "BREW-kimi-cli-CVE-2026-49825",
"modified": "2026-10-08T01:19:49Z",
"published": "2026-08-13T17:01:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"type": "PACKAGE",
"url": "https://github.com/fedora-python/lxml_html_clean"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "`lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes",
"upstream": [
"GHSA-4jhm-jv67-739f",
"CVE-2026-49825",
"PYSEC-2026-2614"
]
}
BREW-TRAFILATURA-CVE-202… (GHSA-4JHM-JV67-739F)
Vulnerability from osv_homebrew – Published: 2026-08-13 17:44 – Updated: 2026-09-17 18:25 – Source websitelxml_html_clean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href)
Reporter: Guillem Lefait guillem@datamq.com · Date: 2026-05-10
Affected: lxml ≤ 6.1.0 and lxml_html_clean ≤ 0.4.4 (latest stable)
Confirmed against: lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 — bug is in pure-Python sanitizer logic, independent of the libxml2 backend)
Root-cause class: same as CVE-2021-28957 (formaction missing from link_attrs)
Summary
Cleaner filters URL schemes (javascript:, vbscript:, …) by walking links via rewrite_links(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.link_attrs. That allow-list contains no prefixed names (xlink:href) and no srcset. As a result, when Cleaner is configured with safe_attrs_only=False — a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing — <a xlink:href="javascript:…"> survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.
CWE: CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.
Affected components
| Package | Versions tested | File / line |
|---|---|---|
lxml |
4.9.x, 5.2.1, 6.1.0 | src/lxml/html/defs.py:20 |
lxml |
" | src/lxml/html/__init__.py:485-528 |
lxml_html_clean |
0.4.0 – 0.4.4 | lxml_html_clean/clean.py:348,576 |
The legacy lxml.html.clean module — bundled in lxml < 5.2.0 and still installable on newer versions via the lxml[html_clean] extra — shares the same bug.
Root cause
defs.link_attrs is a flat string set; the literal xlink:href is absent:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
])
HtmlMixin.iterlinks() (lxml/html/__init__.py:526-528) only yields attributes whose key is in that set:
for attrib in link_attrs:
if attrib in attribs:
yield (el, attrib, attribs[attrib], 0)
Cleaner.__call__ registers the URL-scheme filter via rewrite_links (lxml_html_clean/clean.py:348), which is a thin wrapper around iterlinks(). Because xlink:href is never yielded, _remove_javascript_link (clean.py:576) is never invoked for it.
Minimal reproducer
from lxml import html
from lxml_html_clean import Cleaner
for payload in (
'<svg><a xlink:href="javascript:alert(1)">x</a></svg>',
'<math><a xlink:href="javascript:alert(2)">y</a></math>',
):
tree = html.fromstring(payload)
Cleaner(safe_attrs_only=False)(tree)
print(html.tostring(tree).decode())
print(' iterlinks:', list(html.fromstring(payload).iterlinks()))
# <svg><a xlink:href="javascript:alert(1)">x</a></svg> ← unchanged
# iterlinks: [] ← link rewriter blind
# <math><a xlink:href="javascript:alert(2)">y</a></math> ← unchanged
# iterlinks: [] ← link rewriter blind
Both SVG and MathML scopes are vulnerable — same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (JaVaScRiPt:), HTML-entity (javascript:), embedded tab (java\tscript:).
Impact
A caller that uses Cleaner to neutralise untrusted HTML and chooses safe_attrs_only=False — typically because the application wants to allow custom data-/aria-/vendor attributes — will silently pass javascript: payloads carried on xlink:href through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the safe_attrs_only=False toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.
Suggested fix
Extend link_attrs to include xlink:href. In HTML mode, lxml.html keeps prefixed attribute names verbatim — the parsed key is the literal string xlink:href, not a Clark-notation form — so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
+ 'xlink:href',
])
This single change closes the reported XSS for both SVG <a xlink:href> and MathML <a xlink:href>. lxml_html_clean is the canonical home of the Cleaner code (881 lines); lxml.html.clean is a 21-line backward-compat shim (from lxml_html_clean import *) that picks up the fix automatically once link_attrs is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in lxml_html_clean is preferred.
Alternative (in-package fix, no lxml coordination needed): add a namespaced-URL-attribute walk inside Cleaner.__call__ so the URL-scheme filter doesn't depend on link_attrs. Sketch:
# lxml_html_clean/clean.py — supplements rewrite_links() in __call__
_NS_URL_ATTRS = ('xlink:href',) # extend as needed
_BAD_SCHEME = re.compile(r'^\s*(javascript|vbscript|data):', re.I)
for el in doc.iter():
for attr in _NS_URL_ATTRS:
if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):
del el.attrib[attr]
This decouples the cleaner from the upstream link_attrs set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.
Defense in depth (optional, regardless of which fix path is taken):
- Also handle srcset: the value is a url 1x, url 2x, … descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.
- Also accept Clark-notation forms ({http://www.w3.org/1999/xlink}href) so XML-mode callers using lxml.etree get the same protection. HTML mode never produces this form, so not needed for the reported bug.
Severity
CVSS 3.1 base score: 8.2 / High — AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (→ 7.6).
Severity is CONDITIONAL on the caller passing safe_attrs_only=False. With the class default (True), attribute allow-listing strips xlink:href before scheme scrubbing runs, and the bug does not fire — verified at HEAD: default-config Cleaner()(<svg><a xlink:href="javascript:…">x</a></svg>) → <svg><a>x</a></svg>.
Prior art / novelty
- CVE-2021-28957 (lxml 4.6.3) — same root cause, different attribute (
formaction). Fix was a one-line extension oflink_attrs. Direct precedent. - CVE-2022-34473 (Mozilla Sanitizer API) —
xlink:hrefURL bypass primitive in a different sanitizer. - Bleach (Mozilla, Python) explicitly handles the
xlinknamespace;enshrined/svg-sanitize(PHP) shipscleanXlinkHrefs(); DOMPurify scrubsxlink:hrefviaALLOWED_URI_REGEXP. nh3(the alternative recommended inlxml_html_clean's own README for security-sensitive use) is not vulnerable to this primitive — verified 2026-05-10 onnh3==0.3.5: with<svg>/<math>/<a>andxlink:hrefexplicitly added totags/attributes, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g.<svg><a rel="noopener noreferrer">x</a></svg>).
Coordination
Filing as a private GHSA at fedora-python/lxml_html_clean — lxml_html_clean is the canonical maintainer of the Cleaner code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (https://github.com/lxml/lxml/security/advisories/new returns 404 — private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream defs.link_attrs patch path. You're welcome to coordinate with them directly if you'd prefer the upstream fix over the in-package alternative above.
Happy to provide a draft patch or PR on either path. No bounty expected.
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "lxml-html-clean",
"resource_purl": "pkg:pypi/lxml-html-clean@0.4.5",
"upstream_fixed_in": "0.4.5"
},
"package": {
"ecosystem": "Homebrew",
"name": "trafilatura",
"purl": "pkg:brew/trafilatura"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "2.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/lxml-html-clean@0.4.5",
"name": "lxml-html-clean",
"resource": "lxml-html-clean",
"strategy": "registry",
"subject_version": "0.4.5"
}
]
},
"details": "# `lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes (`xlink:href`)\n\n**Reporter:** Guillem Lefait \u003cguillem@datamq.com\u003e \u00b7 **Date:** 2026-05-10\n**Affected:** `lxml` \u2264 6.1.0 and `lxml_html_clean` \u2264 0.4.4 (latest stable)\n**Confirmed against:** lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 \u2014 bug is in pure-Python sanitizer logic, independent of the libxml2 backend)\n**Root-cause class:** same as CVE-2021-28957 (`formaction` missing from `link_attrs`)\n\n## Summary\n\n`Cleaner` filters URL schemes (`javascript:`, `vbscript:`, \u2026) by walking links via `rewrite_links()`, which delegates to `iterlinks()`, which only yields attributes named in `lxml.html.defs.link_attrs`. That allow-list contains no prefixed names (`xlink:href`) and no `srcset`. As a result, when `Cleaner` is configured with `safe_attrs_only=False` \u2014 a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing \u2014 `\u003ca xlink:href=\"javascript:\u2026\"\u003e` survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.\n\n**CWE:** CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.\n\n## Affected components\n\n| Package | Versions tested | File / line |\n|--------------------|------------------------|----------------------------------|\n| `lxml` | 4.9.x, 5.2.1, 6.1.0 | `src/lxml/html/defs.py:20` |\n| `lxml` | \" | `src/lxml/html/__init__.py:485-528` |\n| `lxml_html_clean` | 0.4.0 \u2013 0.4.4 | `lxml_html_clean/clean.py:348,576` |\n\nThe legacy `lxml.html.clean` module \u2014 bundled in `lxml \u003c 5.2.0` and still installable on newer versions via the `lxml[html_clean]` extra \u2014 shares the same bug.\n\n## Root cause\n\n`defs.link_attrs` is a flat string set; the literal `xlink:href` is absent:\n\n```python\n# lxml/html/defs.py\nlink_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n])\n```\n\n`HtmlMixin.iterlinks()` (`lxml/html/__init__.py:526-528`) only yields attributes whose key is in that set:\n\n```python\nfor attrib in link_attrs:\n if attrib in attribs:\n yield (el, attrib, attribs[attrib], 0)\n```\n\n`Cleaner.__call__` registers the URL-scheme filter via `rewrite_links` (`lxml_html_clean/clean.py:348`), which is a thin wrapper around `iterlinks()`. Because `xlink:href` is never yielded, `_remove_javascript_link` (`clean.py:576`) is never invoked for it.\n\n## Minimal reproducer\n\n```python\nfrom lxml import html\nfrom lxml_html_clean import Cleaner\n\nfor payload in (\n \u0027\u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e\u0027,\n \u0027\u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e\u0027,\n):\n tree = html.fromstring(payload)\n Cleaner(safe_attrs_only=False)(tree)\n print(html.tostring(tree).decode())\n print(\u0027 iterlinks:\u0027, list(html.fromstring(payload).iterlinks()))\n# \u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n# \u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n```\n\nBoth SVG and MathML scopes are vulnerable \u2014 same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (`JaVaScRiPt:`), HTML-entity (`java\u0026#x73;cript:`), embedded tab (`java\\tscript:`).\n\n## Impact\n\nA caller that uses `Cleaner` to neutralise untrusted HTML and chooses `safe_attrs_only=False` \u2014 typically because the application wants to allow custom data-/aria-/vendor attributes \u2014 will silently pass `javascript:` payloads carried on `xlink:href` through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the `safe_attrs_only=False` toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.\n\n## Suggested fix\n\n**Extend `link_attrs`** to include `xlink:href`. In HTML mode, `lxml.html` keeps prefixed attribute names verbatim \u2014 the parsed key is the literal string `xlink:href`, not a Clark-notation form \u2014 so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:\n\n```diff\n # lxml/html/defs.py\n link_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n+ \u0027xlink:href\u0027,\n ])\n```\n\nThis single change closes the reported XSS for both SVG `\u003ca xlink:href\u003e` and MathML `\u003ca xlink:href\u003e`. `lxml_html_clean` is the canonical home of the `Cleaner` code (881 lines); `lxml.html.clean` is a 21-line backward-compat shim (`from lxml_html_clean import *`) that picks up the fix automatically once `link_attrs` is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in `lxml_html_clean` is preferred.\n\n**Alternative (in-package fix, no lxml coordination needed):** add a namespaced-URL-attribute walk inside `Cleaner.__call__` so the URL-scheme filter doesn\u0027t depend on `link_attrs`. Sketch:\n\n```python\n# lxml_html_clean/clean.py \u2014 supplements rewrite_links() in __call__\n_NS_URL_ATTRS = (\u0027xlink:href\u0027,) # extend as needed\n_BAD_SCHEME = re.compile(r\u0027^\\s*(javascript|vbscript|data):\u0027, re.I)\n\nfor el in doc.iter():\n for attr in _NS_URL_ATTRS:\n if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):\n del el.attrib[attr]\n```\n\nThis decouples the cleaner from the upstream `link_attrs` set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.\n\n**Defense in depth (optional, regardless of which fix path is taken):**\n- Also handle `srcset`: the value is a `url 1x, url 2x, \u2026` descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.\n- Also accept Clark-notation forms (`{http://www.w3.org/1999/xlink}href`) so XML-mode callers using `lxml.etree` get the same protection. HTML mode never produces this form, so not needed for the reported bug.\n\n## Severity\n\nCVSS 3.1 base score: **8.2 / High** \u2014 `AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N` (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (\u2192 7.6).\n\nSeverity is **CONDITIONAL** on the caller passing `safe_attrs_only=False`. With the class default (`True`), attribute allow-listing strips `xlink:href` before scheme scrubbing runs, and the bug does not fire \u2014 verified at HEAD: default-config `Cleaner()(\u003csvg\u003e\u003ca xlink:href=\"javascript:\u2026\"\u003ex\u003c/a\u003e\u003c/svg\u003e)` \u2192 `\u003csvg\u003e\u003ca\u003ex\u003c/a\u003e\u003c/svg\u003e`.\n\n## Prior art / novelty\n\n- **CVE-2021-28957 (lxml 4.6.3)** \u2014 same root cause, different attribute (`formaction`). Fix was a one-line extension of `link_attrs`. Direct precedent.\n- **CVE-2022-34473** (Mozilla Sanitizer API) \u2014 `xlink:href` URL bypass primitive in a different sanitizer.\n- **Bleach (Mozilla, Python)** explicitly handles the `xlink` namespace; `enshrined/svg-sanitize` (PHP) ships `cleanXlinkHrefs()`; DOMPurify scrubs `xlink:href` via `ALLOWED_URI_REGEXP`.\n- **`nh3`** (the alternative recommended in `lxml_html_clean`\u0027s own README for security-sensitive use) is **not vulnerable** to this primitive \u2014 verified 2026-05-10 on `nh3==0.3.5`: with `\u003csvg\u003e`/`\u003cmath\u003e`/`\u003ca\u003e` and `xlink:href` explicitly added to `tags`/`attributes`, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g. `\u003csvg\u003e\u003ca rel=\"noopener noreferrer\"\u003ex\u003c/a\u003e\u003c/svg\u003e`).\n\n\n## Coordination\n\nFiling as a private GHSA at `fedora-python/lxml_html_clean` \u2014 `lxml_html_clean` is the canonical maintainer of the `Cleaner` code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (`https://github.com/lxml/lxml/security/advisories/new` returns 404 \u2014 private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream `defs.link_attrs` patch path. You\u0027re welcome to coordinate with them directly if you\u0027d prefer the upstream fix over the in-package alternative above.\n\nHappy to provide a draft patch or PR on either path. No bounty expected.",
"id": "BREW-trafilatura-CVE-2026-49825",
"modified": "2026-09-17T18:25:17Z",
"published": "2026-08-13T17:44:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"type": "PACKAGE",
"url": "https://github.com/fedora-python/lxml_html_clean"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "`lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes",
"upstream": [
"GHSA-4jhm-jv67-739f",
"CVE-2026-49825",
"PYSEC-2026-2614"
]
}
CERTFR-2026-AVI-1336
Vulnerability from certfr_avis - Published: 2026-10-16 - Updated: 2026-10-16
De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| IBM | Sterling Partner Engagement Manager Standard Edition | Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x antérieures à 6.2.4.6 | ||
| IBM | Db2 | Db2 Developer Extension versions antérieures à 1.2.1 | ||
| IBM | Security QRadar Log Management AQL | Security QRadar Log Management AQL Plugin versions antérieures à 1.1.10 | ||
| IBM | AIX | AIX versions 7.3.x sans le dernier correctif de sécurité | ||
| IBM | Sterling Control Center | Sterling Control Center version 6.3.1.0 antérieure à 6.3.1.0 iFix12 | ||
| IBM | Sterling | Sterling External Authentication Server versions 6.1.x antérieures à 6.1.1.5 | ||
| IBM | Db2 | Db2 on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data versions antérieures à v5.3.1 patch 15 | ||
| IBM | Sterling Control Center | Sterling Control Center version 6.4.2.0 antérieure à 6.4.2.0 iFix08 | ||
| IBM | QRadar SIEM | QRadar SIEM versions 7.5.x antérieures à 7.5.0 UP16 IF02 | ||
| IBM | WebSphere Application Server | WebSphere Application Server versions 9.x antérieures à 9.0.5.29 | ||
| IBM | WebSphere Application Server | WebSphere Application Server - Liberty versions 17.0.0.3 à 26.0.0.9 sans le dernier correctif de sécurité ou antérieures à 26.0.0.11 (disponibilité prévue pour le dernier trimestre 2026) | ||
| IBM | WebSphere Application Server | WebSphere Application Server versions 8.x antérieures à 8.5.5.31 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x antérieures à 6.2.4.6 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x antérieures à 6.3.0.4 | ||
| IBM | Sterling Connect:Direct | Sterling Connect:Direct for UNIX versions 6.3.x antérieures à 6.3.0.7.iFix033 | ||
| IBM | QRadar SIEM | QRadar SIEM versions 7.6.x antérieures à 7.6.0.5 | ||
| IBM | Db2 | Db2 intelligence center versions antérieures à 1.1.0 | ||
| IBM | Sterling Connect:Direct | Sterling Connect:Direct for UNIX versions 6.4.x antérieures à 6.4.0.6.iFix025 |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.6",
"product": {
"name": "Sterling Partner Engagement Manager Standard Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Developer Extension versions ant\u00e9rieures \u00e0 1.2.1",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Security QRadar Log Management AQL Plugin versions ant\u00e9rieures \u00e0 1.1.10",
"product": {
"name": "Security QRadar Log Management AQL",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "AIX versions 7.3.x sans le dernier correctif de s\u00e9curit\u00e9",
"product": {
"name": "AIX",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Control Center version 6.3.1.0 ant\u00e9rieure \u00e0 6.3.1.0 iFix12",
"product": {
"name": "Sterling Control Center",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling External Authentication Server versions 6.1.x ant\u00e9rieures \u00e0 6.1.1.5",
"product": {
"name": "Sterling",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.3.1 patch 15",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Control Center version 6.4.2.0 ant\u00e9rieure \u00e0 6.4.2.0 iFix08",
"product": {
"name": "Sterling Control Center",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar SIEM versions 7.5.x ant\u00e9rieures \u00e0 7.5.0 UP16 IF02",
"product": {
"name": "QRadar SIEM",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Application Server versions 9.x ant\u00e9rieures \u00e0 9.0.5.29",
"product": {
"name": "WebSphere Application Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Application Server - Liberty versions 17.0.0.3 \u00e0 26.0.0.9 sans le dernier correctif de s\u00e9curit\u00e9 ou ant\u00e9rieures \u00e0 26.0.0.11 (disponibilit\u00e9 pr\u00e9vue pour le dernier trimestre 2026)",
"product": {
"name": "WebSphere Application Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Application Server versions 8.x ant\u00e9rieures \u00e0 8.5.5.31",
"product": {
"name": "WebSphere Application Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.6",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x ant\u00e9rieures \u00e0 6.3.0.4",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Connect:Direct for UNIX versions 6.3.x ant\u00e9rieures \u00e0 6.3.0.7.iFix033",
"product": {
"name": "Sterling Connect:Direct",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar SIEM versions 7.6.x ant\u00e9rieures \u00e0 7.6.0.5",
"product": {
"name": "QRadar SIEM",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 intelligence center versions ant\u00e9rieures \u00e0 1.1.0",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Connect:Direct for UNIX versions 6.4.x ant\u00e9rieures \u00e0 6.4.0.6.iFix025",
"product": {
"name": "Sterling Connect:Direct",
"vendor": {
"name": "IBM",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-14671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14671"
},
{
"name": "CVE-2026-11548",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11548"
},
{
"name": "CVE-2022-22950",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22950"
},
{
"name": "CVE-2026-15955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15955"
},
{
"name": "CVE-2026-47886",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47886"
},
{
"name": "CVE-2026-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53091"
},
{
"name": "CVE-2026-28420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28420"
},
{
"name": "CVE-2026-93565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93565"
},
{
"name": "CVE-2026-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
},
{
"name": "CVE-2026-59651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59651"
},
{
"name": "CVE-2026-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68343"
},
{
"name": "CVE-2026-87795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87795"
},
{
"name": "CVE-2026-45819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45819"
},
{
"name": "CVE-2020-14621",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14621"
},
{
"name": "CVE-2026-100666",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-100666"
},
{
"name": "CVE-2026-82417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-82417"
},
{
"name": "CVE-2020-26939",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26939"
},
{
"name": "CVE-2026-87877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87877"
},
{
"name": "CVE-2026-93888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93888"
},
{
"name": "CVE-2026-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41254"
},
{
"name": "CVE-2026-101904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101904"
},
{
"name": "CVE-2026-16239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16239"
},
{
"name": "CVE-2026-47061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47061"
},
{
"name": "CVE-2026-32990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32990"
},
{
"name": "CVE-2026-93909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93909"
},
{
"name": "CVE-2026-11549",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11549"
},
{
"name": "CVE-2026-15742",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15742"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-59283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59283"
},
{
"name": "CVE-2026-63384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63384"
},
{
"name": "CVE-2026-100658",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-100658"
},
{
"name": "CVE-2026-6469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6469"
},
{
"name": "CVE-2026-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68763"
},
{
"name": "CVE-2026-63921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63921"
},
{
"name": "CVE-2021-22118",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22118"
},
{
"name": "CVE-2023-33201",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33201"
},
{
"name": "CVE-2026-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-10050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10050"
},
{
"name": "CVE-2025-62728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62728"
},
{
"name": "CVE-2026-59648",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59648"
},
{
"name": "CVE-2026-85014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-85014"
},
{
"name": "CVE-2026-84445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84445"
},
{
"name": "CVE-2026-13608",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13608"
},
{
"name": "CVE-2026-78675",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78675"
},
{
"name": "CVE-2026-59645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59645"
},
{
"name": "CVE-2026-77791",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77791"
},
{
"name": "CVE-2026-67314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67314"
},
{
"name": "CVE-2016-1000341",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000341"
},
{
"name": "CVE-2013-4002",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-4002"
},
{
"name": "CVE-2026-45190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45190"
},
{
"name": "CVE-2026-101902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101902"
},
{
"name": "CVE-2026-76183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76183"
},
{
"name": "CVE-2026-54514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54514"
},
{
"name": "CVE-2026-43339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
},
{
"name": "CVE-2026-16702",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16702"
},
{
"name": "CVE-2026-41853",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41853"
},
{
"name": "CVE-2015-5211",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-5211"
},
{
"name": "CVE-2026-16243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16243"
},
{
"name": "CVE-2026-12185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12185"
},
{
"name": "CVE-2026-47892",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47892"
},
{
"name": "CVE-2026-41854",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41854"
},
{
"name": "CVE-2026-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40974"
},
{
"name": "CVE-2026-47010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47010"
},
{
"name": "CVE-2026-17615",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-17615"
},
{
"name": "CVE-2021-26291",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26291"
},
{
"name": "CVE-2026-73072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73072"
},
{
"name": "CVE-2026-24308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24308"
},
{
"name": "CVE-2026-91776",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-91776"
},
{
"name": "CVE-2026-76172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76172"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"name": "CVE-2026-85008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-85008"
},
{
"name": "CVE-2026-88057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-88057"
},
{
"name": "CVE-2023-26464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26464"
},
{
"name": "CVE-2016-1000343",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000343"
},
{
"name": "CVE-2026-41839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41839"
},
{
"name": "CVE-2026-13505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13505"
},
{
"name": "CVE-2026-13221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13221"
},
{
"name": "CVE-2026-103499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-103499"
},
{
"name": "CVE-2026-93994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93994"
},
{
"name": "CVE-2026-47891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47891"
},
{
"name": "CVE-2026-105800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-105800"
},
{
"name": "CVE-2026-41602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41602"
},
{
"name": "CVE-2026-68569",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68569"
},
{
"name": "CVE-2026-59084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59084"
},
{
"name": "CVE-2026-65183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65183"
},
{
"name": "CVE-2023-20861",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-20861"
},
{
"name": "CVE-2026-2391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2391"
},
{
"name": "CVE-2026-77756",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77756"
},
{
"name": "CVE-2026-93573",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93573"
},
{
"name": "CVE-2026-84375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84375"
},
{
"name": "CVE-2016-5725",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-5725"
},
{
"name": "CVE-2026-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40977"
},
{
"name": "CVE-2026-47057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47057"
},
{
"name": "CVE-2026-41001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41001"
},
{
"name": "CVE-2026-68525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68525"
},
{
"name": "CVE-2026-87824",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87824"
},
{
"name": "CVE-2026-63801",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63801"
},
{
"name": "CVE-2026-67321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67321"
},
{
"name": "CVE-2026-78678",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78678"
},
{
"name": "CVE-2026-67313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67313"
},
{
"name": "CVE-2026-93905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93905"
},
{
"name": "CVE-2019-17571",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-17571"
},
{
"name": "CVE-2026-15396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15396"
},
{
"name": "CVE-2020-5398",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-5398"
},
{
"name": "CVE-2026-65637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65637"
},
{
"name": "CVE-2026-49825",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49825"
},
{
"name": "CVE-2026-67315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67315"
},
{
"name": "CVE-2026-54516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54516"
},
{
"name": "CVE-2016-1000346",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000346"
},
{
"name": "CVE-2026-67320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67320"
},
{
"name": "CVE-2026-41604",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41604"
},
{
"name": "CVE-2020-5421",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-5421"
},
{
"name": "CVE-2026-68536",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68536"
},
{
"name": "CVE-2026-2006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2006"
},
{
"name": "CVE-2026-54515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54515"
},
{
"name": "CVE-2026-18036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18036"
},
{
"name": "CVE-2026-16221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16221"
},
{
"name": "CVE-2024-22243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22243"
},
{
"name": "CVE-2026-6790",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6790"
},
{
"name": "CVE-2026-93895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93895"
},
{
"name": "CVE-2026-18401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18401"
},
{
"name": "CVE-2024-29857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
},
{
"name": "CVE-2023-33202",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33202"
},
{
"name": "CVE-2026-52942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
},
{
"name": "CVE-2026-14668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14668"
},
{
"name": "CVE-2025-41248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41248"
},
{
"name": "CVE-2026-68497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68497"
},
{
"name": "CVE-2026-72129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72129"
},
{
"name": "CVE-2026-76646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76646"
},
{
"name": "CVE-2026-104721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-104721"
},
{
"name": "CVE-2026-105453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-105453"
},
{
"name": "CVE-2025-35973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-35973"
},
{
"name": "CVE-2026-12860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12860"
},
{
"name": "CVE-2026-16241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16241"
},
{
"name": "CVE-2026-64563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64563"
},
{
"name": "CVE-2026-6473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6473"
},
{
"name": "CVE-2026-78679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78679"
},
{
"name": "CVE-2026-59652",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59652"
},
{
"name": "CVE-2021-4104",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4104"
},
{
"name": "CVE-2026-71497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71497"
},
{
"name": "CVE-2012-0881",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-0881"
},
{
"name": "CVE-2026-41992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41992"
},
{
"name": "CVE-2016-1000345",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000345"
},
{
"name": "CVE-2026-24051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24051"
},
{
"name": "CVE-2026-47885",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47885"
},
{
"name": "CVE-2026-15634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15634"
},
{
"name": "CVE-2026-55831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55831"
},
{
"name": "CVE-2026-80230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80230"
},
{
"name": "CVE-2026-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68363"
},
{
"name": "CVE-2026-19534",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19534"
},
{
"name": "CVE-2026-59277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59277"
},
{
"name": "CVE-2026-71227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71227"
},
{
"name": "CVE-2026-78677",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78677"
},
{
"name": "CVE-2025-22233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22233"
},
{
"name": "CVE-2016-1000338",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000338"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"name": "CVE-2026-31663",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31663"
},
{
"name": "CVE-2024-22262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22262"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2026-93442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93442"
},
{
"name": "CVE-2020-9493",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9493"
},
{
"name": "CVE-2026-42584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42584"
},
{
"name": "CVE-2024-38809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38809"
},
{
"name": "CVE-2026-44249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44249"
},
{
"name": "CVE-2026-41991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41991"
},
{
"name": "CVE-2026-59647",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59647"
},
{
"name": "CVE-2026-41844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41844"
},
{
"name": "CVE-2024-30172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
},
{
"name": "CVE-2026-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39883"
},
{
"name": "CVE-2026-45292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45292"
},
{
"name": "CVE-2026-88059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-88059"
},
{
"name": "CVE-2025-67030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67030"
},
{
"name": "CVE-2026-41845",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41845"
},
{
"name": "CVE-2026-58059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58059"
},
{
"name": "CVE-2026-50623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50623"
},
{
"name": "CVE-2026-17463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-17463"
},
{
"name": "CVE-2024-38820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38820"
},
{
"name": "CVE-2026-8763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8763"
},
{
"name": "CVE-2026-18408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18408"
},
{
"name": "CVE-2026-42504",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42504"
},
{
"name": "CVE-2026-69247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69247"
},
{
"name": "CVE-2026-40971",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40971"
},
{
"name": "CVE-2026-68426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68426"
},
{
"name": "CVE-2026-63917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63917"
},
{
"name": "CVE-2026-65182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65182"
},
{
"name": "CVE-2026-41842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41842"
},
{
"name": "CVE-2026-18446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18446"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2026-15928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15928"
},
{
"name": "CVE-2026-84292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84292"
},
{
"name": "CVE-2026-22740",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22740"
},
{
"name": "CVE-2026-47890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47890"
},
{
"name": "CVE-2026-19385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19385"
},
{
"name": "CVE-2026-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56746"
},
{
"name": "CVE-2026-50634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50634"
},
{
"name": "CVE-2020-9488",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9488"
},
{
"name": "CVE-2026-95696",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-95696"
},
{
"name": "CVE-2026-41849",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41849"
},
{
"name": "CVE-2026-95680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-95680"
},
{
"name": "CVE-2026-101908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101908"
},
{
"name": "CVE-2026-77185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77185"
},
{
"name": "CVE-2026-59276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59276"
},
{
"name": "CVE-2026-41603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41603"
},
{
"name": "CVE-2026-93558",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93558"
},
{
"name": "CVE-2026-15055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15055"
},
{
"name": "CVE-2026-90560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-90560"
},
{
"name": "CVE-2026-39820",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39820"
},
{
"name": "CVE-2026-86087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86087"
},
{
"name": "CVE-2026-14682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14682"
},
{
"name": "CVE-2026-84303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84303"
},
{
"name": "CVE-2026-101907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101907"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-73180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73180"
},
{
"name": "CVE-2026-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68315"
},
{
"name": "CVE-2026-15412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15412"
},
{
"name": "CVE-2026-14662",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14662"
},
{
"name": "CVE-2026-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58061"
},
{
"name": "CVE-2026-73076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73076"
},
{
"name": "CVE-2026-10841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10841"
},
{
"name": "CVE-2026-16118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16118"
},
{
"name": "CVE-2026-84394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84394"
},
{
"name": "CVE-2026-78676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78676"
},
{
"name": "CVE-2026-68376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68376"
},
{
"name": "CVE-2026-19203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19203"
},
{
"name": "CVE-2022-23305",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23305"
},
{
"name": "CVE-2026-71225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71225"
},
{
"name": "CVE-2026-40458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40458"
},
{
"name": "CVE-2022-35583",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35583"
},
{
"name": "CVE-2026-66053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66053"
},
{
"name": "CVE-2026-5795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5795"
},
{
"name": "CVE-2026-59857",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59857"
},
{
"name": "CVE-2026-40975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40975"
},
{
"name": "CVE-2026-6470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6470"
},
{
"name": "CVE-2026-89425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89425"
},
{
"name": "CVE-2026-14669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14669"
},
{
"name": "CVE-2026-43870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43870"
},
{
"name": "CVE-2016-1000342",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000342"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2026-100655",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-100655"
},
{
"name": "CVE-2026-105442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-105442"
},
{
"name": "CVE-2026-67317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67317"
},
{
"name": "CVE-2026-77762",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77762"
},
{
"name": "CVE-2026-93566",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93566"
},
{
"name": "CVE-2026-71226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71226"
},
{
"name": "CVE-2026-17508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-17508"
},
{
"name": "CVE-2026-78383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78383"
},
{
"name": "CVE-2016-1000339",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000339"
},
{
"name": "CVE-2009-2625",
"url": "https://www.cve.org/CVERecord?id=CVE-2009-2625"
},
{
"name": "CVE-2026-47027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47027"
},
{
"name": "CVE-2026-47058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47058"
},
{
"name": "CVE-2026-49875",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49875"
},
{
"name": "CVE-2026-18149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18149"
},
{
"name": "CVE-2026-101898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101898"
},
{
"name": "CVE-2022-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23307"
},
{
"name": "CVE-2026-16441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16441"
},
{
"name": "CVE-2026-14678",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14678"
},
{
"name": "CVE-2026-58060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58060"
},
{
"name": "CVE-2026-68143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68143"
},
{
"name": "CVE-2026-86350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86350"
},
{
"name": "CVE-2026-47045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47045"
},
{
"name": "CVE-2026-53182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53182"
},
{
"name": "CVE-2026-33811",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33811"
},
{
"name": "CVE-2026-41843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41843"
},
{
"name": "CVE-2026-22741",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22741"
},
{
"name": "CVE-2026-82596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-82596"
},
{
"name": "CVE-2021-22060",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22060"
},
{
"name": "CVE-2026-19931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19931"
},
{
"name": "CVE-2026-12802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12802"
},
{
"name": "CVE-2026-59281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59281"
},
{
"name": "CVE-2026-10649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10649"
},
{
"name": "CVE-2026-68117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68117"
},
{
"name": "CVE-2026-101294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101294"
},
{
"name": "CVE-2026-54512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54512"
},
{
"name": "CVE-2025-68745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68745"
},
{
"name": "CVE-2026-101909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101909"
},
{
"name": "CVE-2026-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58063"
},
{
"name": "CVE-2026-47167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47167"
},
{
"name": "CVE-2026-41850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41850"
},
{
"name": "CVE-2026-78254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78254"
},
{
"name": "CVE-2026-67319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67319"
},
{
"name": "CVE-2026-101901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101901"
},
{
"name": "CVE-2026-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-40992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40992"
},
{
"name": "CVE-2026-70907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-70907"
},
{
"name": "CVE-2026-59646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59646"
},
{
"name": "CVE-2026-18924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18924"
},
{
"name": "CVE-2026-93441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93441"
},
{
"name": "CVE-2026-82209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-82209"
},
{
"name": "CVE-2026-91777",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-91777"
},
{
"name": "CVE-2026-15741",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15741"
},
{
"name": "CVE-2026-63382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63382"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2026-14677",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14677"
},
{
"name": "CVE-2026-41586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41586"
},
{
"name": "CVE-2022-22968",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22968"
},
{
"name": "CVE-2026-95695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-95695"
},
{
"name": "CVE-2026-84304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84304"
},
{
"name": "CVE-2026-47063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47063"
},
{
"name": "CVE-2026-29062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29062"
},
{
"name": "CVE-2026-12816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12816"
},
{
"name": "CVE-2026-59083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59083"
},
{
"name": "CVE-2026-64117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64117"
},
{
"name": "CVE-2026-63383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63383"
},
{
"name": "CVE-2026-59888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59888"
},
{
"name": "CVE-2026-73078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73078"
},
{
"name": "CVE-2026-84939",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84939"
},
{
"name": "CVE-2026-84961",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84961"
},
{
"name": "CVE-2026-47021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47021"
},
{
"name": "CVE-2026-14680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14680"
},
{
"name": "CVE-2026-41852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41852"
},
{
"name": "CVE-2026-16440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16440"
},
{
"name": "CVE-2026-84933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84933"
},
{
"name": "CVE-2026-14666",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14666"
},
{
"name": "CVE-2026-64113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64113"
},
{
"name": "CVE-2026-66422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66422"
},
{
"name": "CVE-2026-33997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33997"
},
{
"name": "CVE-2025-8714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8714"
},
{
"name": "CVE-2026-78437",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-78437"
},
{
"name": "CVE-2023-20863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-20863"
},
{
"name": "CVE-2026-45205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45205"
},
{
"name": "CVE-2026-59314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59314"
},
{
"name": "CVE-2026-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-13506",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13506"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2026-35172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35172"
},
{
"name": "CVE-2026-75899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75899"
},
{
"name": "CVE-2026-14673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14673"
},
{
"name": "CVE-2026-49844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49844"
},
{
"name": "CVE-2026-42583",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42583"
},
{
"name": "CVE-2022-34169",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34169"
},
{
"name": "CVE-2026-41851",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41851"
},
{
"name": "CVE-2026-54370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54370"
},
{
"name": "CVE-2022-22970",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22970"
},
{
"name": "CVE-2026-46968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46968"
},
{
"name": "CVE-2026-43133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43133"
},
{
"name": "CVE-2026-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50010"
},
{
"name": "CVE-2014-0107",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-0107"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2026-39836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39836"
},
{
"name": "CVE-2026-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52920"
},
{
"name": "CVE-2026-14663",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14663"
},
{
"name": "CVE-2026-50219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50219"
},
{
"name": "CVE-2022-23437",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23437"
},
{
"name": "CVE-2026-63379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63379"
},
{
"name": "CVE-2026-82562",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-82562"
},
{
"name": "CVE-2026-45191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45191"
},
{
"name": "CVE-2026-76218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76218"
},
{
"name": "CVE-2026-41841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41841"
},
{
"name": "CVE-2026-18540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18540"
},
{
"name": "CVE-2026-41605",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41605"
},
{
"name": "CVE-2026-54517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54517"
},
{
"name": "CVE-2026-74761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74761"
},
{
"name": "CVE-2024-38808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38808"
},
{
"name": "CVE-2016-1000340",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000340"
},
{
"name": "CVE-2026-40973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40973"
},
{
"name": "CVE-2026-11722",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11722"
},
{
"name": "CVE-2026-63385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63385"
},
{
"name": "CVE-2026-74556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74556"
},
{
"name": "CVE-2026-63387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63387"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-100656",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-100656"
},
{
"name": "CVE-2026-63971",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63971"
},
{
"name": "CVE-2026-89044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89044"
},
{
"name": "CVE-2026-65905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65905"
},
{
"name": "CVE-2026-16439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16439"
},
{
"name": "CVE-2026-85024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-85024"
},
{
"name": "CVE-2026-42499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42499"
},
{
"name": "CVE-2026-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56745"
},
{
"name": "CVE-2025-69277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69277"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2026-63919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63919"
},
{
"name": "CVE-2026-93488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93488"
},
{
"name": "CVE-2021-44228",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44228"
},
{
"name": "CVE-2026-22735",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22735"
},
{
"name": "CVE-2026-59642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59642"
},
{
"name": "CVE-2020-15522",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-15522"
},
{
"name": "CVE-2026-80231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80231"
},
{
"name": "CVE-2026-61308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-61308"
},
{
"name": "CVE-2026-75931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75931"
},
{
"name": "CVE-2026-87958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87958"
},
{
"name": "CVE-2026-22745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22745"
},
{
"name": "CVE-2024-30171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
},
{
"name": "CVE-2026-42587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42587"
},
{
"name": "CVE-2016-1000352",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000352"
},
{
"name": "CVE-2026-54513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54513"
},
{
"name": "CVE-2026-72098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72098"
},
{
"name": "CVE-2026-46306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
},
{
"name": "CVE-2022-4245",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4245"
},
{
"name": "CVE-2026-65927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65927"
},
{
"name": "CVE-2026-87823",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87823"
},
{
"name": "CVE-2026-9563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9563"
},
{
"name": "CVE-2026-59280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59280"
},
{
"name": "CVE-2026-59638",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59638"
},
{
"name": "CVE-2026-87825",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87825"
},
{
"name": "CVE-2026-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54518"
},
{
"name": "CVE-2026-6464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6464"
},
{
"name": "CVE-2026-60589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60589"
},
{
"name": "CVE-2026-67312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67312"
},
{
"name": "CVE-2022-0235",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0235"
},
{
"name": "CVE-2022-23302",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23302"
},
{
"name": "CVE-2026-10051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10051"
},
{
"name": "CVE-2026-6322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6322"
},
{
"name": "CVE-2026-43869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43869"
},
{
"name": "CVE-2026-58062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58062"
},
{
"name": "CVE-2026-6471",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6471"
},
{
"name": "CVE-2025-41249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41249"
},
{
"name": "CVE-2026-12143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12143"
},
{
"name": "CVE-2026-43233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43233"
},
{
"name": "CVE-2026-89045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89045"
},
{
"name": "CVE-2022-4244",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4244"
},
{
"name": "CVE-2026-50633",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50633"
},
{
"name": "CVE-2026-68300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68300"
},
{
"name": "CVE-2026-67318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67318"
},
{
"name": "CVE-2026-109839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-109839"
},
{
"name": "CVE-2026-63381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63381"
},
{
"name": "CVE-2026-90852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-90852"
},
{
"name": "CVE-2024-22259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22259"
},
{
"name": "CVE-2026-47060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47060"
},
{
"name": "CVE-2026-75973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75973"
},
{
"name": "CVE-2020-5397",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-5397"
},
{
"name": "CVE-2026-14679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14679"
},
{
"name": "CVE-2026-12803",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12803"
},
{
"name": "CVE-2026-86472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86472"
},
{
"name": "CVE-2026-8384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8384"
},
{
"name": "CVE-2026-53075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53075"
},
{
"name": "CVE-2026-53246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
},
{
"name": "CVE-2026-52859",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52859"
},
{
"name": "CVE-2026-93907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-93907"
},
{
"name": "CVE-2026-59650",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59650"
},
{
"name": "CVE-2016-1000344",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000344"
},
{
"name": "CVE-2026-89407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89407"
},
{
"name": "CVE-2026-0636",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0636"
},
{
"name": "CVE-2026-14672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14672"
},
{
"name": "CVE-2026-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40976"
},
{
"name": "CVE-2026-64015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64015"
},
{
"name": "CVE-2020-15168",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-15168"
},
{
"name": "CVE-2026-84890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84890"
},
{
"name": "CVE-2020-14338",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14338"
},
{
"name": "CVE-2026-63388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63388"
},
{
"name": "CVE-2026-47883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47883"
},
{
"name": "CVE-2026-19032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19032"
},
{
"name": "CVE-2026-42579",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42579"
},
{
"name": "CVE-2026-56132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56132"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2026-76217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76217"
},
{
"name": "CVE-2026-55892",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55892"
},
{
"name": "CVE-2026-109838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-109838"
},
{
"name": "CVE-2026-55833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55833"
},
{
"name": "CVE-2026-13586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13586"
},
{
"name": "CVE-2021-22096",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22096"
},
{
"name": "CVE-2019-17359",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-17359"
},
{
"name": "CVE-2026-105443",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-105443"
},
{
"name": "CVE-2026-74480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74480"
},
{
"name": "CVE-2026-56819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56819"
},
{
"name": "CVE-2026-63889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63889"
},
{
"name": "CVE-2026-75975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75975"
},
{
"name": "CVE-2026-14664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14664"
},
{
"name": "CVE-2026-101900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-101900"
},
{
"name": "CVE-2026-59639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59639"
},
{
"name": "CVE-2026-41840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41840"
},
{
"name": "CVE-2026-86093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86093"
},
{
"name": "CVE-2018-1000180",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000180"
},
{
"name": "CVE-2026-68494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68494"
},
{
"name": "CVE-2026-89046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89046"
},
{
"name": "CVE-2026-14670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14670"
},
{
"name": "CVE-2026-46917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46917"
},
{
"name": "CVE-2026-60147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60147"
},
{
"name": "CVE-2026-47889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47889"
},
{
"name": "CVE-2026-64007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64007"
},
{
"name": "CVE-2026-79677",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-79677"
},
{
"name": "CVE-2025-31936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31936"
},
{
"name": "CVE-2026-41848",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41848"
},
{
"name": "CVE-2026-70906",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-70906"
},
{
"name": "CVE-2026-67316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67316"
},
{
"name": "CVE-2025-48431",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48431"
},
{
"name": "CVE-2026-73581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73581"
},
{
"name": "CVE-2026-34481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34481"
},
{
"name": "CVE-2026-47893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47893"
},
{
"name": "CVE-2026-64002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64002"
},
{
"name": "CVE-2026-24281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24281"
},
{
"name": "CVE-2026-81665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-81665"
},
{
"name": "CVE-2026-19880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19880"
},
{
"name": "CVE-2026-46680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46680"
},
{
"name": "CVE-2026-47059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47059"
},
{
"name": "CVE-2026-41293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41293"
},
{
"name": "CVE-2026-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
},
{
"name": "CVE-2026-18024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18024"
},
{
"name": "CVE-2026-83557",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-83557"
},
{
"name": "CVE-2026-77310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77310"
},
{
"name": "CVE-2026-84947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84947"
},
{
"name": "CVE-2026-87022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87022"
},
{
"name": "CVE-2026-63802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63802"
},
{
"name": "CVE-2026-59889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59889"
}
],
"initial_release_date": "2026-10-16T00:00:00",
"last_revision_date": "2026-10-16T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1336",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-10-16T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Injection de requ\u00eates ill\u00e9gitimes par rebond (CSRF)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Injection SQL (SQLi)"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits IBM. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits IBM",
"vendor_advisories": [
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292213",
"url": "https://www.ibm.com/support/pages/node/7292213"
},
{
"published_at": "2026-10-15",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292743",
"url": "https://www.ibm.com/support/pages/node/7292743"
},
{
"published_at": "2026-10-15",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292742",
"url": "https://www.ibm.com/support/pages/node/7292742"
},
{
"published_at": "2026-10-11",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292010",
"url": "https://www.ibm.com/support/pages/node/7292010"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292240",
"url": "https://www.ibm.com/support/pages/node/7292240"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7290903",
"url": "https://www.ibm.com/support/pages/node/7290903"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292244",
"url": "https://www.ibm.com/support/pages/node/7292244"
},
{
"published_at": "2026-10-12",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292117",
"url": "https://www.ibm.com/support/pages/node/7292117"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292236",
"url": "https://www.ibm.com/support/pages/node/7292236"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292232",
"url": "https://www.ibm.com/support/pages/node/7292232"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292221",
"url": "https://www.ibm.com/support/pages/node/7292221"
},
{
"published_at": "2026-10-12",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292175",
"url": "https://www.ibm.com/support/pages/node/7292175"
},
{
"published_at": "2026-10-12",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292127",
"url": "https://www.ibm.com/support/pages/node/7292127"
},
{
"published_at": "2026-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7291777",
"url": "https://www.ibm.com/support/pages/node/7291777"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292226",
"url": "https://www.ibm.com/support/pages/node/7292226"
},
{
"published_at": "2026-10-14",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292372",
"url": "https://www.ibm.com/support/pages/node/7292372"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292228",
"url": "https://www.ibm.com/support/pages/node/7292228"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292216",
"url": "https://www.ibm.com/support/pages/node/7292216"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292217",
"url": "https://www.ibm.com/support/pages/node/7292217"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292219",
"url": "https://www.ibm.com/support/pages/node/7292219"
},
{
"published_at": "2026-10-14",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292486",
"url": "https://www.ibm.com/support/pages/node/7292486"
},
{
"published_at": "2026-10-15",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292735",
"url": "https://www.ibm.com/support/pages/node/7292735"
},
{
"published_at": "2026-10-15",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292737",
"url": "https://www.ibm.com/support/pages/node/7292737"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292227",
"url": "https://www.ibm.com/support/pages/node/7292227"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292214",
"url": "https://www.ibm.com/support/pages/node/7292214"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7292235",
"url": "https://www.ibm.com/support/pages/node/7292235"
}
]
}
FKIE_CVE-2026-49825
Vulnerability from fkie_nvd - Published: 2026-08-20 15:17 - Updated: 2026-09-18 20:05| URL | Tags | ||
|---|---|---|---|
| security-advisories@github.com | https://github.com/fedora-python/lxml_html_clean/commit/322357ac61c6cf80fcbaba53b4e92e31f3ded9f2 | ||
| security-advisories@github.com | https://github.com/fedora-python/lxml_html_clean/releases/tag/0.4.5 | ||
| security-advisories@github.com | https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f | ||
| security-advisories@github.com | https://github.com/lxml/lxml/commit/5927a6d5e851845140975d99b65461e255caaab0 | ||
| security-advisories@github.com | https://github.com/lxml/lxml/releases/tag/lxml-6.1.1 | ||
| 134c704f-9b21-4f2e-91b3-4a467353bcc0 | https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f |
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"product": "lxml",
"vendor": "lxml",
"versions": [
{
"status": "affected",
"version": "\u003c 6.1.1"
}
]
},
{
"product": "lxml_html_clean",
"vendor": "fedora-python",
"versions": [
{
"status": "affected",
"version": "\u003c 0.4.5"
}
]
}
],
"source": "security-advisories@github.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.1, link attributes in ``lxml.html.defs.link_attrs`` were missing ``xlink:href``, which can be used for URL bypass attacks in embedded SVG/MathML/etc. content. This vulnerability was fixed in lxml 6.1.1 and lxml_html_clean 0.4.5."
}
],
"id": "CVE-2026-49825",
"lastModified": "2026-09-18T20:05:53.723",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 4.7,
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-49825",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-21T16:41:32.043801Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-08-20T15:17:30.707",
"references": [
{
"source": "security-advisories@github.com",
"url": "https://github.com/fedora-python/lxml_html_clean/commit/322357ac61c6cf80fcbaba53b4e92e31f3ded9f2"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/fedora-python/lxml_html_clean/releases/tag/0.4.5"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/lxml/lxml/commit/5927a6d5e851845140975d99b65461e255caaab0"
},
{
"source": "security-advisories@github.com",
"url": "https://github.com/lxml/lxml/releases/tag/lxml-6.1.1"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Awaiting Analysis",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-79"
},
{
"lang": "en",
"value": "CWE-184"
}
],
"source": "security-advisories@github.com",
"type": "Secondary"
}
]
}
GHSA-4JHM-JV67-739F
Vulnerability from github – Published: 2026-07-08 20:23 – Updated: 2026-07-08 20:23lxml_html_clean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href)
Reporter: Guillem Lefait guillem@datamq.com · Date: 2026-05-10
Affected: lxml ≤ 6.1.0 and lxml_html_clean ≤ 0.4.4 (latest stable)
Confirmed against: lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 — bug is in pure-Python sanitizer logic, independent of the libxml2 backend)
Root-cause class: same as CVE-2021-28957 (formaction missing from link_attrs)
Summary
Cleaner filters URL schemes (javascript:, vbscript:, …) by walking links via rewrite_links(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.link_attrs. That allow-list contains no prefixed names (xlink:href) and no srcset. As a result, when Cleaner is configured with safe_attrs_only=False — a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing — <a xlink:href="javascript:…"> survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.
CWE: CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.
Affected components
| Package | Versions tested | File / line |
|---|---|---|
lxml |
4.9.x, 5.2.1, 6.1.0 | src/lxml/html/defs.py:20 |
lxml |
" | src/lxml/html/__init__.py:485-528 |
lxml_html_clean |
0.4.0 – 0.4.4 | lxml_html_clean/clean.py:348,576 |
The legacy lxml.html.clean module — bundled in lxml < 5.2.0 and still installable on newer versions via the lxml[html_clean] extra — shares the same bug.
Root cause
defs.link_attrs is a flat string set; the literal xlink:href is absent:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
])
HtmlMixin.iterlinks() (lxml/html/__init__.py:526-528) only yields attributes whose key is in that set:
for attrib in link_attrs:
if attrib in attribs:
yield (el, attrib, attribs[attrib], 0)
Cleaner.__call__ registers the URL-scheme filter via rewrite_links (lxml_html_clean/clean.py:348), which is a thin wrapper around iterlinks(). Because xlink:href is never yielded, _remove_javascript_link (clean.py:576) is never invoked for it.
Minimal reproducer
from lxml import html
from lxml_html_clean import Cleaner
for payload in (
'<svg><a xlink:href="javascript:alert(1)">x</a></svg>',
'<math><a xlink:href="javascript:alert(2)">y</a></math>',
):
tree = html.fromstring(payload)
Cleaner(safe_attrs_only=False)(tree)
print(html.tostring(tree).decode())
print(' iterlinks:', list(html.fromstring(payload).iterlinks()))
# <svg><a xlink:href="javascript:alert(1)">x</a></svg> ← unchanged
# iterlinks: [] ← link rewriter blind
# <math><a xlink:href="javascript:alert(2)">y</a></math> ← unchanged
# iterlinks: [] ← link rewriter blind
Both SVG and MathML scopes are vulnerable — same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (JaVaScRiPt:), HTML-entity (javascript:), embedded tab (java\tscript:).
Impact
A caller that uses Cleaner to neutralise untrusted HTML and chooses safe_attrs_only=False — typically because the application wants to allow custom data-/aria-/vendor attributes — will silently pass javascript: payloads carried on xlink:href through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the safe_attrs_only=False toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.
Suggested fix
Extend link_attrs to include xlink:href. In HTML mode, lxml.html keeps prefixed attribute names verbatim — the parsed key is the literal string xlink:href, not a Clark-notation form — so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:
# lxml/html/defs.py
link_attrs = frozenset([
'action', 'archive', 'background', 'cite', 'classid',
'codebase', 'data', 'href', 'longdesc', 'profile', 'src',
'usemap', 'dynsrc', 'lowsrc', 'formaction',
+ 'xlink:href',
])
This single change closes the reported XSS for both SVG <a xlink:href> and MathML <a xlink:href>. lxml_html_clean is the canonical home of the Cleaner code (881 lines); lxml.html.clean is a 21-line backward-compat shim (from lxml_html_clean import *) that picks up the fix automatically once link_attrs is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in lxml_html_clean is preferred.
Alternative (in-package fix, no lxml coordination needed): add a namespaced-URL-attribute walk inside Cleaner.__call__ so the URL-scheme filter doesn't depend on link_attrs. Sketch:
# lxml_html_clean/clean.py — supplements rewrite_links() in __call__
_NS_URL_ATTRS = ('xlink:href',) # extend as needed
_BAD_SCHEME = re.compile(r'^\s*(javascript|vbscript|data):', re.I)
for el in doc.iter():
for attr in _NS_URL_ATTRS:
if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):
del el.attrib[attr]
This decouples the cleaner from the upstream link_attrs set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.
Defense in depth (optional, regardless of which fix path is taken):
- Also handle srcset: the value is a url 1x, url 2x, … descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.
- Also accept Clark-notation forms ({http://www.w3.org/1999/xlink}href) so XML-mode callers using lxml.etree get the same protection. HTML mode never produces this form, so not needed for the reported bug.
Severity
CVSS 3.1 base score: 8.2 / High — AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (→ 7.6).
Severity is CONDITIONAL on the caller passing safe_attrs_only=False. With the class default (True), attribute allow-listing strips xlink:href before scheme scrubbing runs, and the bug does not fire — verified at HEAD: default-config Cleaner()(<svg><a xlink:href="javascript:…">x</a></svg>) → <svg><a>x</a></svg>.
Prior art / novelty
- CVE-2021-28957 (lxml 4.6.3) — same root cause, different attribute (
formaction). Fix was a one-line extension oflink_attrs. Direct precedent. - CVE-2022-34473 (Mozilla Sanitizer API) —
xlink:hrefURL bypass primitive in a different sanitizer. - Bleach (Mozilla, Python) explicitly handles the
xlinknamespace;enshrined/svg-sanitize(PHP) shipscleanXlinkHrefs(); DOMPurify scrubsxlink:hrefviaALLOWED_URI_REGEXP. nh3(the alternative recommended inlxml_html_clean's own README for security-sensitive use) is not vulnerable to this primitive — verified 2026-05-10 onnh3==0.3.5: with<svg>/<math>/<a>andxlink:hrefexplicitly added totags/attributes, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g.<svg><a rel="noopener noreferrer">x</a></svg>).
Coordination
Filing as a private GHSA at fedora-python/lxml_html_clean — lxml_html_clean is the canonical maintainer of the Cleaner code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (https://github.com/lxml/lxml/security/advisories/new returns 404 — private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream defs.link_attrs patch path. You're welcome to coordinate with them directly if you'd prefer the upstream fix over the in-package alternative above.
Happy to provide a draft patch or PR on either path. No bounty expected.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lxml_html_clean"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49825"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-08T20:23:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# `lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes (`xlink:href`)\n\n**Reporter:** Guillem Lefait \u003cguillem@datamq.com\u003e \u00b7 **Date:** 2026-05-10\n**Affected:** `lxml` \u2264 6.1.0 and `lxml_html_clean` \u2264 0.4.4 (latest stable)\n**Confirmed against:** lxml 6.1.0 + lxml_html_clean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 \u2014 bug is in pure-Python sanitizer logic, independent of the libxml2 backend)\n**Root-cause class:** same as CVE-2021-28957 (`formaction` missing from `link_attrs`)\n\n## Summary\n\n`Cleaner` filters URL schemes (`javascript:`, `vbscript:`, \u2026) by walking links via `rewrite_links()`, which delegates to `iterlinks()`, which only yields attributes named in `lxml.html.defs.link_attrs`. That allow-list contains no prefixed names (`xlink:href`) and no `srcset`. As a result, when `Cleaner` is configured with `safe_attrs_only=False` \u2014 a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing \u2014 `\u003ca xlink:href=\"javascript:\u2026\"\u003e` survives sanitization untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.\n\n**CWE:** CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.\n\n## Affected components\n\n| Package | Versions tested | File / line |\n|--------------------|------------------------|----------------------------------|\n| `lxml` | 4.9.x, 5.2.1, 6.1.0 | `src/lxml/html/defs.py:20` |\n| `lxml` | \" | `src/lxml/html/__init__.py:485-528` |\n| `lxml_html_clean` | 0.4.0 \u2013 0.4.4 | `lxml_html_clean/clean.py:348,576` |\n\nThe legacy `lxml.html.clean` module \u2014 bundled in `lxml \u003c 5.2.0` and still installable on newer versions via the `lxml[html_clean]` extra \u2014 shares the same bug.\n\n## Root cause\n\n`defs.link_attrs` is a flat string set; the literal `xlink:href` is absent:\n\n```python\n# lxml/html/defs.py\nlink_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n])\n```\n\n`HtmlMixin.iterlinks()` (`lxml/html/__init__.py:526-528`) only yields attributes whose key is in that set:\n\n```python\nfor attrib in link_attrs:\n if attrib in attribs:\n yield (el, attrib, attribs[attrib], 0)\n```\n\n`Cleaner.__call__` registers the URL-scheme filter via `rewrite_links` (`lxml_html_clean/clean.py:348`), which is a thin wrapper around `iterlinks()`. Because `xlink:href` is never yielded, `_remove_javascript_link` (`clean.py:576`) is never invoked for it.\n\n## Minimal reproducer\n\n```python\nfrom lxml import html\nfrom lxml_html_clean import Cleaner\n\nfor payload in (\n \u0027\u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e\u0027,\n \u0027\u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e\u0027,\n):\n tree = html.fromstring(payload)\n Cleaner(safe_attrs_only=False)(tree)\n print(html.tostring(tree).decode())\n print(\u0027 iterlinks:\u0027, list(html.fromstring(payload).iterlinks()))\n# \u003csvg\u003e\u003ca xlink:href=\"javascript:alert(1)\"\u003ex\u003c/a\u003e\u003c/svg\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n# \u003cmath\u003e\u003ca xlink:href=\"javascript:alert(2)\"\u003ey\u003c/a\u003e\u003c/math\u003e \u2190 unchanged\n# iterlinks: [] \u2190 link rewriter blind\n```\n\nBoth SVG and MathML scopes are vulnerable \u2014 same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (`JaVaScRiPt:`), HTML-entity (`java\u0026#x73;cript:`), embedded tab (`java\\tscript:`).\n\n## Impact\n\nA caller that uses `Cleaner` to neutralise untrusted HTML and chooses `safe_attrs_only=False` \u2014 typically because the application wants to allow custom data-/aria-/vendor attributes \u2014 will silently pass `javascript:` payloads carried on `xlink:href` through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the `safe_attrs_only=False` toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.\n\n## Suggested fix\n\n**Extend `link_attrs`** to include `xlink:href`. In HTML mode, `lxml.html` keeps prefixed attribute names verbatim \u2014 the parsed key is the literal string `xlink:href`, not a Clark-notation form \u2014 so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:\n\n```diff\n # lxml/html/defs.py\n link_attrs = frozenset([\n \u0027action\u0027, \u0027archive\u0027, \u0027background\u0027, \u0027cite\u0027, \u0027classid\u0027,\n \u0027codebase\u0027, \u0027data\u0027, \u0027href\u0027, \u0027longdesc\u0027, \u0027profile\u0027, \u0027src\u0027,\n \u0027usemap\u0027, \u0027dynsrc\u0027, \u0027lowsrc\u0027, \u0027formaction\u0027,\n+ \u0027xlink:href\u0027,\n ])\n```\n\nThis single change closes the reported XSS for both SVG `\u003ca xlink:href\u003e` and MathML `\u003ca xlink:href\u003e`. `lxml_html_clean` is the canonical home of the `Cleaner` code (881 lines); `lxml.html.clean` is a 21-line backward-compat shim (`from lxml_html_clean import *`) that picks up the fix automatically once `link_attrs` is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in `lxml_html_clean` is preferred.\n\n**Alternative (in-package fix, no lxml coordination needed):** add a namespaced-URL-attribute walk inside `Cleaner.__call__` so the URL-scheme filter doesn\u0027t depend on `link_attrs`. Sketch:\n\n```python\n# lxml_html_clean/clean.py \u2014 supplements rewrite_links() in __call__\n_NS_URL_ATTRS = (\u0027xlink:href\u0027,) # extend as needed\n_BAD_SCHEME = re.compile(r\u0027^\\s*(javascript|vbscript|data):\u0027, re.I)\n\nfor el in doc.iter():\n for attr in _NS_URL_ATTRS:\n if attr in el.attrib and _BAD_SCHEME.match(el.attrib[attr]):\n del el.attrib[attr]\n```\n\nThis decouples the cleaner from the upstream `link_attrs` set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.\n\n**Defense in depth (optional, regardless of which fix path is taken):**\n- Also handle `srcset`: the value is a `url 1x, url 2x, \u2026` descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap.\n- Also accept Clark-notation forms (`{http://www.w3.org/1999/xlink}href`) so XML-mode callers using `lxml.etree` get the same protection. HTML mode never produces this form, so not needed for the reported bug.\n\n## Severity\n\nCVSS 3.1 base score: **8.2 / High** \u2014 `AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N` (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (\u2192 7.6).\n\nSeverity is **CONDITIONAL** on the caller passing `safe_attrs_only=False`. With the class default (`True`), attribute allow-listing strips `xlink:href` before scheme scrubbing runs, and the bug does not fire \u2014 verified at HEAD: default-config `Cleaner()(\u003csvg\u003e\u003ca xlink:href=\"javascript:\u2026\"\u003ex\u003c/a\u003e\u003c/svg\u003e)` \u2192 `\u003csvg\u003e\u003ca\u003ex\u003c/a\u003e\u003c/svg\u003e`.\n\n## Prior art / novelty\n\n- **CVE-2021-28957 (lxml 4.6.3)** \u2014 same root cause, different attribute (`formaction`). Fix was a one-line extension of `link_attrs`. Direct precedent.\n- **CVE-2022-34473** (Mozilla Sanitizer API) \u2014 `xlink:href` URL bypass primitive in a different sanitizer.\n- **Bleach (Mozilla, Python)** explicitly handles the `xlink` namespace; `enshrined/svg-sanitize` (PHP) ships `cleanXlinkHrefs()`; DOMPurify scrubs `xlink:href` via `ALLOWED_URI_REGEXP`.\n- **`nh3`** (the alternative recommended in `lxml_html_clean`\u0027s own README for security-sensitive use) is **not vulnerable** to this primitive \u2014 verified 2026-05-10 on `nh3==0.3.5`: with `\u003csvg\u003e`/`\u003cmath\u003e`/`\u003ca\u003e` and `xlink:href` explicitly added to `tags`/`attributes`, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g. `\u003csvg\u003e\u003ca rel=\"noopener noreferrer\"\u003ex\u003c/a\u003e\u003c/svg\u003e`).\n\n\n## Coordination\n\nFiling as a private GHSA at `fedora-python/lxml_html_clean` \u2014 `lxml_html_clean` is the canonical maintainer of the `Cleaner` code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (`https://github.com/lxml/lxml/security/advisories/new` returns 404 \u2014 private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream `defs.link_attrs` patch path. You\u0027re welcome to coordinate with them directly if you\u0027d prefer the upstream fix over the in-package alternative above.\n\nHappy to provide a draft patch or PR on either path. No bounty expected.",
"id": "GHSA-4jhm-jv67-739f",
"modified": "2026-07-08T20:23:22Z",
"published": "2026-07-08T20:23:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fedora-python/lxml_html_clean/security/advisories/GHSA-4jhm-jv67-739f"
},
{
"type": "PACKAGE",
"url": "https://github.com/fedora-python/lxml_html_clean"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "`lxml_html_clean.Cleaner` does not strip `javascript:` URLs from namespaced URL attributes"
}
OESA-2026-3217 (CVE-2026-49825)
Vulnerability from osv_openeuler – Published: 2026-08-01 11:12 – Updated: 2026-08-06 11:12 – Source website\
Security Fix(es):
lxml_html_clean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href). The vulnerability exists because Cleaner filters URL schemes by walking links via rewrite_links(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.link_attrs. That allow-list contains no prefixed names such as xlink:href. As a result, when Cleaner is configured with safe_attrs_only=False, an xlink:href attribute carrying a javascript: URL survives sanitization untouched, and any browser that follows the SVG or MathML anchor specification will execute the JavaScript when the rendered link is clicked, leading to Cross-Site Scripting (XSS) attacks.(CVE-2026-49825)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python-lxml-debuginfo-5.1.0-5.oe2403sp1.aarch64.rpm",
"python-lxml-debugsource-5.1.0-5.oe2403sp1.aarch64.rpm",
"python-lxml-help-5.1.0-5.oe2403sp1.aarch64.rpm",
"python3-lxml-5.1.0-5.oe2403sp1.aarch64.rpm"
],
"src": [
"python-lxml-5.1.0-5.oe2403sp1.src.rpm"
],
"x86_64": [
"python-lxml-debuginfo-5.1.0-5.oe2403sp1.x86_64.rpm",
"python-lxml-debugsource-5.1.0-5.oe2403sp1.x86_64.rpm",
"python-lxml-help-5.1.0-5.oe2403sp1.x86_64.rpm",
"python3-lxml-5.1.0-5.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "python-lxml",
"purl": "pkg:rpm/openEuler/python-lxml\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.1.0-5.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"python-lxml-debuginfo-5.1.0-5.oe2403sp3.aarch64.rpm",
"python-lxml-debugsource-5.1.0-5.oe2403sp3.aarch64.rpm",
"python-lxml-help-5.1.0-5.oe2403sp3.aarch64.rpm",
"python3-lxml-5.1.0-5.oe2403sp3.aarch64.rpm"
],
"src": [
"python-lxml-5.1.0-5.oe2403sp3.src.rpm"
],
"x86_64": [
"python-lxml-debuginfo-5.1.0-5.oe2403sp3.x86_64.rpm",
"python-lxml-debugsource-5.1.0-5.oe2403sp3.x86_64.rpm",
"python-lxml-help-5.1.0-5.oe2403sp3.x86_64.rpm",
"python3-lxml-5.1.0-5.oe2403sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP3",
"name": "python-lxml",
"purl": "pkg:rpm/openEuler/python-lxml\u0026distro=openEuler-24.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.1.0-5.oe2403sp3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"python-lxml-debuginfo-5.1.0-5.oe2403sp4.aarch64.rpm",
"python-lxml-debugsource-5.1.0-5.oe2403sp4.aarch64.rpm",
"python-lxml-help-5.1.0-5.oe2403sp4.aarch64.rpm",
"python3-lxml-5.1.0-5.oe2403sp4.aarch64.rpm"
],
"src": [
"python-lxml-5.1.0-5.oe2403sp4.src.rpm"
],
"x86_64": [
"python-lxml-debuginfo-5.1.0-5.oe2403sp4.x86_64.rpm",
"python-lxml-debugsource-5.1.0-5.oe2403sp4.x86_64.rpm",
"python-lxml-help-5.1.0-5.oe2403sp4.x86_64.rpm",
"python3-lxml-5.1.0-5.oe2403sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP4",
"name": "python-lxml",
"purl": "pkg:rpm/openEuler/python-lxml\u0026distro=openEuler-24.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.1.0-5.oe2403sp4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"python-lxml-debuginfo-4.5.2-11.oe2003sp4.aarch64.rpm",
"python-lxml-debugsource-4.5.2-11.oe2003sp4.aarch64.rpm",
"python2-lxml-4.5.2-11.oe2003sp4.aarch64.rpm",
"python3-lxml-4.5.2-11.oe2003sp4.aarch64.rpm"
],
"noarch": [
"python-lxml-help-4.5.2-11.oe2003sp4.noarch.rpm"
],
"src": [
"python-lxml-4.5.2-11.oe2003sp4.src.rpm"
],
"x86_64": [
"python-lxml-debuginfo-4.5.2-11.oe2003sp4.x86_64.rpm",
"python-lxml-debugsource-4.5.2-11.oe2003sp4.x86_64.rpm",
"python2-lxml-4.5.2-11.oe2003sp4.x86_64.rpm",
"python3-lxml-4.5.2-11.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "python-lxml",
"purl": "pkg:rpm/openEuler/python-lxml\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.2-11.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"ecosystem_specific": {
"aarch64": [
"python-lxml-debuginfo-4.7.1-10.oe2203sp4.aarch64.rpm",
"python-lxml-debugsource-4.7.1-10.oe2203sp4.aarch64.rpm",
"python3-lxml-4.7.1-10.oe2203sp4.aarch64.rpm"
],
"noarch": [
"python-lxml-help-4.7.1-10.oe2203sp4.noarch.rpm"
],
"src": [
"python-lxml-4.7.1-10.oe2203sp4.src.rpm"
],
"x86_64": [
"python-lxml-debuginfo-4.7.1-10.oe2203sp4.x86_64.rpm",
"python-lxml-debugsource-4.7.1-10.oe2203sp4.x86_64.rpm",
"python3-lxml-4.7.1-10.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "python-lxml",
"purl": "pkg:rpm/openEuler/python-lxml\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.7.1-10.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "\\\r\n\r\nSecurity Fix(es):\n\nlxml_html_clean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href). The vulnerability exists because Cleaner filters URL schemes by walking links via rewrite_links(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.link_attrs. That allow-list contains no prefixed names such as xlink:href. As a result, when Cleaner is configured with safe_attrs_only=False, an xlink:href attribute carrying a javascript: URL survives sanitization untouched, and any browser that follows the SVG or MathML anchor specification will execute the JavaScript when the rendered link is clicked, leading to Cross-Site Scripting (XSS) attacks.(CVE-2026-49825)",
"id": "OESA-2026-3217",
"modified": "2026-08-06T11:12:05Z",
"published": "2026-08-01T11:12:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3217"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49825"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "python-lxml security update",
"upstream": [
"CVE-2026-49825"
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.