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.

An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.

An issue was discovered in libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.

DISPUTED libxml2 through 2.11.5 has a use-after-free that can only occur after a certain memory allocation fails. This occurs in xmlUnlinkNode in tree.c. NOTE: the vendor's position is "I don't think these issues are critical enough to warrant a CVE ID ... because an attacker typically can't control when memory allocations fail."

Xmlsoft Libxml2 v2.11.0 was discovered to contain a global buffer overflow via the xmlSAX2StartElement() function at /libxml2/SAX2.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via supplying a crafted XML file.

https://gitlab.gnome.org/GNOME/libxml2/-/issues/535

DISPUTED Xmlsoft Libxml2 v2.11.0 was discovered to contain an out-of-bounds read via the xmlSAX2StartElement() function at /libxml2/SAX2.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via supplying a crafted XML file. NOTE: the vendor's position is that the product does not support the legacy SAX1 interface with custom callbacks; there is a crash even without crafted input.

In libxml2 before 2.10.4, parsing of certain invalid XSD schemas can lead to a NULL pointer dereference and subsequently a segfault. This occurs in xmlSchemaFixupComplexType in xmlschemas.c.

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

A flaw was found in libxml2. Parsing a XML document with the XMLPARSEHUGE option enabled can result in an integer overflow because safety checks were missing in some functions. Also, the xmlParseEntityValue function didn't have any length limitation.