9
CVEs
0
Critical
3
High
0
KEV
0
PoC
0
Unpatched C/H
77.8%
Patch Rate
0.1%
Avg EPSS
Severity Breakdown
CRITICAL
0
HIGH
3
MEDIUM
2
LOW
4
Monthly CVE Trend
Affected Products (30)
Libxml2
87
Debian Linux
52
Ubuntu Linux
40
Iphone Os
30
Tvos
26
Watchos
25
Mac Os X
25
Enterprise Linux Server
22
Libxslt
22
Enterprise Linux Workstation
21
Enterprise Linux Desktop
21
Fedora
17
Active Iq Unified Manager
14
Clustered Data Ontap
13
Icewall Federation Agent
13
Opensuse
12
Enterprise Linux
12
Icewall File Manager
11
Enterprise Linux Server Aus
11
Manageability Software Development Kit
11
Jboss Core Services
11
Clustered Data Ontap Antivirus Connector
11
Web Gateway
10
Enterprise Linux Server Tus
10
Ontap Select Deploy Administration Utility
10
H410s Firmware
9
H300s Firmware
9
Enterprise Linux Server Eus
9
H500s Firmware
9
Chrome
9
Top Risky CVEs
| CVE | Summary | Severity | CVSS | EPSS | Priority | Signals |
|---|---|---|---|---|---|---|
| CVE-2026-86140 | Let me construct the JSON. Key facts: libxml2 before 2.15.4, xmlSnprintfElements in valid.c, strcat stack buffer overflow, CWE-121. CVSS 7.8, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS 0.14% (3rd percentile). Patch available from vendor; commit d1686f91. Fix versions: 2.15.4. Red Hat RHSA-2026:64463. No KEV, no POC mentioned. Note the vector AV:L PR:L — local, low privileges. That's interesting because libxml2 is used in parsing. Local vector means the attacker needs to run code that triggers xmlSnprintfElements. Actually the CVSS provided says AV:L/PR:L. Hmm, that seems odd for a library parsing untrusted XML, but I should respect the input. Wait — actually, the input CVSS vector says AV:L/AC:L/PR:L. But note: the "CRITICAL FIELD" instructions say I should not infer auth from description. The vector is provided so I can say PR:L → "authenticated"/local low-privileged. Interesting tension: the vulnerable function is a validation error-message builder. xmlSnprintfElements builds the error message listing expected elements. It's triggered when validation fails on a deeply-nested/large content model — likely reachable via parsing untrusted XML with validation enabled (xmlValidateDocument / well-formedness? Actually valid.c is used for DTD validation). So remote attacks via parsing malicious XML with validation enabled could be possible; the AV:L in the provided vector may be conservative or wrong. I should flag that in risk_assessment — note conflicting signal. I'll write assessed_cvss_vector myself. Should I keep AV:L? The instruction: "Choose PR honestly: if exploitation requires control over configuration files, admin access, or authentication, use PR:H or PR:L — never PR:N for operator/config-dependent flaws. Use AV:L when the vector is local/config-only." Hmm. The vulnerability is in a library parsing XML documents. If an application validates untrusted XML with DTD validation, the buffer overflow could be triggered remotely (AV:N, PR:N, UI:N) in the context | HIGH | 7.8 | 0.1% | 39 |
|
| CVE-2026-86142 | Let me produce the JSON. Key facts: libxml2 heap buffer overflow in xmlXPtrEvalXPtrPart due to xmlXPtrEval xpointer length saturation. CVSS 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. CWE-122. EPSS 0.13% (3rd percentile). Patch available, fixed in 2.15.4. No KEV, no POC mentioned. Note: CVSS is local vector, PR:L — so authenticated/local access needed. XPointer evaluation requires parsing untrusted XML/XPointer input. Actually the CVSS says AV:L PR:L which suggests local attacker with low privileges — but libxml2 is typically parsed remotely via XML input. There's a tension: the vector says local. I should note that in risk_assessment — conflicting signal. Product name: "libxml2" (2 words? it's one word). Fine. Prevalence: high — libxml2 is widely deployed (core library in many systems). Could argue "ubiquitous". libxml2 is in nearly every Linux distro, used by many apps. I'd say "high" or "ubiquitous". Given anchors: OpenSSL/nginx/Linux kernel = ubiquitous. libxml2 is comparably widespread as a library dependency. I'll say "ubiquitous"? Hmm. It's a core XML parsing library used by GNOME, PHP, Python lxml, many. I'd say "high" to be safe... Actually libxml2 is extremely pervasive. But prevalence is deployment footprint in production. I'll go with "high" with basis "ubiquitous XML parser library across Linux distributions and apps". Hmm, "ubiquitous" anchor is OpenSSL/nginx/kernel. libxml2 is arguably in that class. I'll choose "high" — widely deployed but often not directly network-exposed. Let me pick "high". Actually let me reconsider: libxml2 is bundled in virtually every Linux distro, used by PHP, Python, Ruby, GNOME, etc. That's arguably closer to ubiquitous. But the anchor "high" = widely-deployed enterprise software. I'll go with "high" and basis "core XML parser in most Linux distributions and many apps". Hmm, either is defensible. I'll say "high". assessed_cvss_vector: The vulnerability requires evaluating an XPointer with hostile input. Root cause: len | HIGH | 7.8 | 0.1% | 39 |
|
| CVE-2026-86138 | Heap-based buffer overflow in libxml2 before 2.15.4, reachable through the internal dictionary routine xmlDictAddQString() in dict.c, which miscalculates the size of an exponentially growing string pool and can be driven past the integer range before allocating. Per the vendor-assigned CVSS vector the attack is local with low privileges (AV:L/PR:L), so it primarily affects applications, daemons, or sandboxed services that parse attacker-influenced XML under a constrained account. A vendor patch (2.15.4, commit a4cba4b5) and a Red Hat errata exist, but there is no CISA KEV listing and no confirmed public exploit — EPSS is only 0.12% (2nd percentile), so this is a patch-hygiene item rather than a fire drill. | HIGH | 7.8 | 0.1% | 39 |
|
| CVE-2026-86137 | Out-of-bounds read in libxml2's XML regular expression parser exposes all versions before 2.15.4 to a limited availability impact when processing malformed character group patterns. The NXT(index) macro in xmlregexp.c performed a direct array dereference without verifying the index stays within the parsed string's length, allowing a specially crafted regexp pattern to read one byte past the allocated buffer. The vendor-released fix in v2.15.4 adds a bounds guard returning 0 for out-of-bounds accesses; no public exploit is identified at time of analysis. | MEDIUM | 6.1 | 0.1% | 31 |
|
| CVE-2026-0990 | libxml2's xmlCatalogXMLResolveURI function is vulnerable to uncontrolled recursion when processing self-referencing delegate URI entries in XML catalogs, allowing remote attackers to trigger stack exhaustion and crash applications. This configuration-dependent denial of service requires specially crafted XML input but no authentication, affecting any application using the vulnerable library to parse untrusted catalogs. No patch is currently available. | MEDIUM | 5.9 | 0.1% | 30 |
|
| CVE-2026-0989 | A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested <include> directives. [CVSS 3.7 LOW] | LOW | 3.7 | 0.0% | 19 |
No patch
|
| CVE-2026-86141 | NULL pointer dereference in libxml2's xmlRegNewParserCtxt() function crashes any application invoking the XML regular-expression engine under memory-pressure conditions. Versions before 2.15.4 call strlen() on the return value of xmlStrdup() without first verifying the pointer is non-NULL; when strdup() fails due to memory exhaustion, the subsequent strlen(NULL) causes a process crash. No confidentiality or integrity impact is possible - the vulnerability is limited to a local, high-complexity denial-of-service. No public exploit or CISA KEV listing exists; the fix shipped in libxml2 2.15.4. | LOW | 3.3 | 0.1% | 17 |
|
| CVE-2026-0992 | A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated <nextCatalog> elements pointing to the same downstream catalog. [CVSS 2.9 LOW] | LOW | 2.9 | 0.0% | 15 |
No patch
|
| CVE-2026-11979 | Stack-based buffer overflows in libxml2's xmlcatalog utility enable memory corruption and potential arbitrary code execution when the tool is invoked in its interactive --shell mode. The usershell() function writes user-supplied input into fixed-size stack buffers (command, arg, argv) without any length validation, allowing overflow of adjacent stack memory including return addresses. Real-world risk is very low: exploitation requires local access, deliberate user invocation of a non-default shell mode, and an attack precondition - reflected in the CVSS 4.0 score of 1.8 - with no public exploit or active exploitation identified. Notably, libxml2 maintainers disputed the security classification, treating this as a bug rather than a vulnerability. | LOW | 1.8 | 0.2% | 9 |
|