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

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 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 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, xmlURIEscapeStr in uri.c has an integer overflow.

In libxml2 before 2.15.4, xmlSnprintfElements in valid.c has a strcat stack-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.

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 identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.

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 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.

Use-After-Free vulnerability in libxslt caused by unsafe manipulation of the atype field in attribute nodes. The flaw occurs when xsltSetSourceNodeFlags() sets extra flag bits on xmlAttrPtr->atype, a field later used by libxml2 to check whether an attribute is an XML ID. This corruption can cause libxml2 to skip cleanup steps like xmlRemoveID() during memory deallocation. As a result, ID table entries may point to freed memory, and later calls to xmlFreeID() will dereference these dangling pointers, triggering a use-after-free. This vulnerability is exploitable through crafted XSLT using the key() function and result tree fragments, and may result in denial-of-service or memory corruption.

Last updated 25 February 2025

xmlXIncludeAddNode in xinclude.c in libxml2 before 2.11.0 has a use-after-free.

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.

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.

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.

El vie, 14 feb 2025, 07:14, Nick Wellnhofer <wellnhofer () aevum de> escribió: On Feb 13, 2025, at 23:28, Daniel Gutson <danielgutson () gmail com> wrote: Curious: is there any info about how this was discovered? The bug was discovered with basic fuzz testing. As libxml2 maintainer, I found more and more issues in various iconv implementations by accident which is a strong indicator that all this code isn't tested enough. The iconv API is also trivial to fuzz, so it seemed like a nice weekend project. Thanks, AFL?

My work is related to static checkers and linters (we will contribute an important patch to weggli soon), so I was wondering if you used something that used symbolic execution.

Nice job! Nick

It was found that Red Hat JBoss Core Services incorrectly included CVE-2016-3705 as resolved in Apache HTTP 2.4.23 (erratum RHSA-2016:2957). The release did not include the fix to libxml2, leaving it vulnerable to a Denial of Service attack due to a Stack Overflow. This is a regression CVE for CVE-2016-3705.

It was found that Red Hat JBoss Core Services incorrectly fixed CVE-2016-3627 in Apache HTTP 2.4.23 (erratum RHSA-2016:2957), leaving libxml2 vulnerable to a Denial of Service attack via stack consumption.

xmlsec is vulnerable to XML External Entity Expansion via libxml2 (see CVE-2016-9318). A workaround is in progress on the upstream bug report.

Upstream bug:

https://github.com/lsh123/xmlsec/issues/43

A denial of service flaw was found in the way libxml2, a library providing support to read, modify and write XML and HTML files, performed string substitutions when entity values for entity references replacement (--noent option) was requested / enabled during the XML file parsing. A remote attacker could provide a specially-crafted XML file that, when processed would lead to excessive CPU consumption (denial of service).