In xinclude in libxml2 before 2.15.4, xmlXIncludeProcess and xmlXIncludeProcessTree do not propagate parseFlags. This has security relevance for, for example, the XMLPARSENONET flag, if (without it) a custom resource loader accesses the internet and triggers XML external entity injection, SSRF, or a denial of service (e.g., for an attacker-controlled internet resource that is intentionally slow).

In xmlIO in libxml2 before 2.15.4, an inconsistency in xmlOutputWriteCallback and xmlBufUse causes negative lengths to reach write callbacks, aka a lack of a check for integer overflow before calling writecallback. This has security relevance for many types of uses of that length value within a callback.

In libxml2 before 2.15.4, there is a heap-based buffer overflow in xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation.

xmlregexp in libxml2 before 2.15.4 has a NULL pointer dereference in xmlRegNewParserCtxt after a strdup failure, i.e., it does not calculate a string length after NULL checking.

In libxml2 before 2.15.4, xmlSnprintfElements in valid.c has a strcat stack-based buffer overflow.

In libxml2 before 2.15.4, xmlURIEscapeStr in uri.c has an integer overflow.

In libxml2 before 2.15.4, xmlDictAddQString in dict.c has an integer overflow and resultant heap-based buffer overflow.

In libxml2 before 2.15.4, xmlFAParsePosCharGroup has an out-of-bounds read, aka an out-of-bounds read in the NXT macro in xmlregexp.

libxml2 is vulnerable to multiple stack-based buffer overflows in the xmlcatalog utility when running in --shell mode. The usershell() function processes user input using fixed-size stack buffers without proper bounds checking. By supplying an overly long input line, an attacker can overflow internal buffers (command, arg, and argv) during input parsing. This results in memory corruption within the stack frame. Successful exploitation may cause a crash or potentially allow arbitrary code execution in the context of the xmlcatalog process.

This issue has been fixed in the commit c2e233fc.

NOTE: The maintainers of this project did not agree that this issue is a vulnerability and considered it a bug.

Use After Free in libxml2's xmlParseInternalSubset from GNOME libxml2 version 2.9.11 to 2.11.0 allows a remote attacker to cause a denial-of-service via maliciously crafted XML input with improper entity resolution handling.

A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.

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. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.

A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.

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. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.

A critical stack overflow vulnerability was discovered in the libxslt library when handling the dyn:map() function from the EXSLT extension. The vulnerability allows an attacker to cause a denial of service (DoS) via a specially crafted XSLT document containing the recursive dyn:map(., .) call.

The main reason of the vulnerability is that the exsltDynMapFunction function in libexslt/dynamic.c doesn’t contain a recursion depth check. When handling dyn:map(., .) where the second parameter contains a recursive call to the same function, infinite recursion occurs until the program stack is exhausted.

A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."

A flaw was found in the libxslt library. The same memory field, psvi, is used for both stylesheet and input data, which can lead to type confusion during XML transformations. This vulnerability allows an attacker to crash the application or corrupt memory. In some cases, it may lead to denial of service or unexpected behavior.

A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.

A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.

libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047.

Accessibility. A logging issue was addressed with improved data redaction.

Last updated 25 February 2025

Accessibility. A logging issue was addressed with improved data redaction.

Accessibility. An authentication issue was addressed with improved state management.

Accessibility. An authentication issue was addressed with improved state management.

Last updated 25 February 2025

After I sent the previous message, I realized that there may be more to what component these CVEs are against.

CVE-2012-0037 was against "Redland Raptor (aka libraptor) before 2.0.7, as used by OpenOffice 3.3 and 3.4 Beta, LibreOffice before 3.4.6 and 3.5.x before 3.5.1, and other products, allows user-assisted remote attackers to read arbitrary files via a crafted XML external entity (XXE) declaration and reference in an RDF document."

... and this very description explains why it scored lower - it was for specific common uses of the Raptor library. Specifying that user interaction is required was reasonable in context of needing to load a file into a desktop application.

Now that the issue was instead addressed in libxml2, the CVSS vector may be different because that library is used in many more places and ways. A relevant question (to those more familiar with this than I am) would be whether affected uses other than by Raptor likely exist (and are likely addressed by the same change in libxml2) and where/what they are. Ditto about uses of Raptor other than by those desktop office projects.

On Wed, Dec 25, 2024 at 06:04:22PM -0500, Demi Marie Obenour wrote: On Wed, Dec 25, 2024 at 07:13:21PM +0100, Solar Designer wrote: On Wed, Dec 25, 2024 at 11:52:06AM +0200, Yair Mizrahi wrote: libxml2, CVE-2024-40896, was published recently and given a "Critical" (9.1) severity by CISA. Interestingly - This vulnerability is a regression of an issue that was identified over a decade ago - CVE-2012-0037, which was given a "Medium" (6.5) severity.

Is the massive increase in CVSS over the exact same issue justified? We believe that it's inflated. I think both CVSS vectors are "buggy", and CVSS is quite poor at scoring library code vulnerabilities.

CVE-2012-0037 NIST NVD CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N CVE-2024-40896 CISA-ADP CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

The differences are whether user interaction is required or not (can't know that for library code, so have to assume either best or worst case) and what impact there is (again can't know it for library code, but these two test vectors somehow assume different impacts). Given how poor CVSS base score is for scoring library code in general, I'm afraid this issue would more "reasonably" (per CVSS spec) be scored 10.0 as AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, because such exposed usage of the library is realistic, SSRF would be a change of scope (right?), and the worst impacts of all 3 kinds are quite possible. If SSRF is a scope change, shouldn't that mean that RCE is also a scope change? It's usable for SSRF after all. That's a good point. I am no CVSS expert, but I guess the answer is no. I am also unsure whether SSRF is a scope change - maybe a CVSS "lawyer" will comment on that.

Apparently, CVSS distinguishes direct vs. secondary impact. Relevantly, looking at the examples https://www.first.org/cvss/v3.1/examples I see that while high impact on integrity usually goes along with high impact on availability, this is not always the case. In one example of I:H/A:N, the comment says "Any availability impact is secondary." It may be similar for RCE not implying scope change (secondary ability to perform SSRF) even if SSRF does (direct).

There isn't an example for SSRF on the v3.1 page above, but there is on the v4.0 page, which also includes a v3.1 vector for reference:

https://www.first.org/cvss/v4.0/examples#Server-Side-Request-Forgery-SSRF-CVE-2024-1233

In there, the v3.1 vector has scope unchanged, without explanation. In v4.0, there's no such component, but instead it's separate impact triples for vulnerable and subsequent system. In all of these cases, the impacts range from None to Low, never High. The v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L giving a score of 7.3. But that's for SSRF that isn't a result of XXE, so maybe a reasonable vector for CVE-2024-40896 would be CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L giving a score of 8.6, or maybe lower if only some relevant uses of libxml2 would be considered.

So yeah, maybe the older vector for CVE-2012-0037 leading to a score of 6.5 is valid usage of CVSS after all. But I am not sure it's reusable when we're talking libxml2 rather than Raptor as in "office" projects.

Meanwhile, Red Hat's vector+score for CVE-2024-40896 is the same as CISA's, and Red Hat's own threat impact score for it is Critical (separate from CVSS severity name, just happens to be named the same). But none of Red Hat's products are reported affected, which suggests that a more specific analysis (than CISA's) probably was not performed. In other cases, Red Hat's scores are often lower.

Alexander

In libxml2 2.11 before 2.11.9, 2.12 before 2.12.9, and 2.13 before 2.13.3, the SAX parser can produce events for external entities even if custom SAX handlers try to override entity content (by setting "checked"). This makes classic XXE attacks possible.