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

A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.

A flaw was found in libxml2 with Python bindings enabled. A remote attacker could exploit this vulnerability by providing a specially crafted XML document containing a Document Type Definition (DTD) with enumerated attribute values. This triggers a double-free error in the SAX attributeDecl callback handler, where a string is freed twice. This flaw can lead to a denial of service (DoS) due to a reproducible crash in Python applications using the libxml2 SAX bindings.

Last updated 25 February 2025

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

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.

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.

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.

libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. 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.

A Heap Use After Free (UAF) vulnerability was discovered in the Schematron in the libxml2. The issue arises in the xmlSchematronGetNode function when processing XPath expressions in Schematron schema elements <sch:name path="..."/>, where a pointer to freed memory is returned and then accessed, leading to undefined behavior and potential crashes.

A null pointer dereference vulnerability was discovered in the libxml2. The issue occurs in the xmlSchematronFormatReport function when processing incorrect XPath expressions in Schematron schema reports, leading to undefined behavior and potential crashes.

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.

SUMMARY A double-free / use-after-free exists in the SAX attributeDecl callback handler (pythonAttributeDecl in python/libxml.c). When parsing XML containing a DTD <!ATTLIST> declaration with enumerated attribute values, each value string is freed twice: PyListSetItem() steals the reference, and an explicit PyDECREF() then drops the refcount to zero and frees the object, leaving a dangling pointer in the list.

AFFECTED COMPONENT

libxml2 with Python bindings enabled (python3-libxml2 / libxml2-python)

The defect is long-standing; the affected code in pythonAttributeDecl has been unchanged for many years.

Reproduced on upstream commit 4b35628e97472eaf23d8a841d2f711f7c2f96255 (2026-02-24).

IMPACT

Denial of service: 100% reproducible crash (SIGSEGV) in any Python application that uses the libxml2 SAX bindings (libxml2.createPushParser), registers an attributeDecl handler, and parses untrusted XML with a DTD <!ATTLIST> containing enumerated values. Verified 10/10 in isolated processes.

The use-after-free is also potentially exploitable for code execution: I was able to demonstrate hijacking the freed object's tpdealloc function pointer in-process. Full remote code execution would require additional heap grooming and is not demonstrated. I'd defer to your team on final severity scoring; I'd characterize the reliably demonstrated impact as DoS, with code execution as a credible but conditional escalation.

ROOT CAUSE (python/libxml.c, pythonAttributeDecl)

for (node = tree; node != NULL; node = node->next) { newName = PYIMPORTSTRING((char ) node->name); PyListSetItem(nameList, count, newName); / steals reference / PyDECREF(newName); / double-free / count++; }

PyListSetItem() does not increment the refcount, so the subsequent PyDECREF() over-decrements. Because of CPython pymalloc free-list reuse, list entries can end up pointing at the same freed address; cleanup after the SAX callback then decrefs dangling pointers and corrupts allocator state.

PROOF OF CONCEPT (minimal DoS)

import libxml2 class Handler: def attributeDecl(self, args): pass def startElement(self, a): pass def endElement(self, a): pass def characters(self, a): pass xml = b'''<?xml version="1.0"?> <!DOCTYPE r [ <!ELEMENT r EMPTY> <!ATTLIST r a (xx|yy|zz|ww|qq) "xx"> ]> <r a="xx"/>''' h = Handler() c = libxml2.createPushParser(h, "", 0, "t") c.parseChunk(xml, len(xml), 1) # SIGSEGV

UPSTREAM FIX (already merged and closed)

Fix: remove the erroneous PyDECREF(newName) since PyListSetItem already takes ownership.

Merge request: https://gitlab.gnome.org/GNOME/libxml2/-/mergerequests/397 ("python: Do not decref string after adding to the list")

Fix commit: 046931e6

Issue report: https://gitlab.gnome.org/GNOME/libxml2/-/workitems/1076

Upstream maintainer Nick Wellnhofer confirmed it appears to be a security issue and asked that a CVE be requested; the maintainer who merged the fix indicated CVE assignment is not handled by the project itself.

SUGGESTED CLASSIFICATION

CWE-415 (Double Free), leading to CWE-416 (Use After Free)

ENVIRONMENT

OS: Ubuntu 22.04 x8664; Python 3.10.12; GCC 11.4.0; libxml2 built from source with -fsanitize=address.

I'm happy to provide the full ASan trace or the code-execution PoC on request. Please let me know if you need anything else to proceed.

Thank you, Adnan Jakati!https://mailtrack.io/trace/mail/773e02eeb348f92b41f2a5d93b4c46af0007ab1f.png?u=12519192!

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 flaw was found in libxml2. A local user or an attacker providing a specially crafted XML catalog can trigger a NULL pointer dereference during XML catalog parsing. This occurs when a nextCatalog element lacks its mandatory catalog attribute, leading to the application crashing and causing a Denial of Service (DoS).

A vulnerability in libxml2 when parsing specially crafted XML document if XZ support is enabled causing DoS of application was found.

CVE request (including reproducer):

http://seclists.org/oss-sec/2015/q4/206

Integer Overflow (Wraparound) vulnerability in the xmlBuildQName() function in libxml2. The flaw arises due to unsafe arithmetic when concatenating XML name components using the lengths of prefix and local name. These lengths, originally sizet, are cast to int, leading to incorrect calculations when values are large. If exploited, the function can perform a memcpy with an extremely large size, causing a stack buffer overflow. This vulnerability is remotely exploitable if the attacker can influence XML content passed to affected applications, potentially resulting in denial of service.

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.

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.

xmlStringLenDecodeEntities in parser.c in libxml2 2.9.10 has an infinite loop in a certain end-of-file situation.

Reference and upstream commit: https://gitlab.gnome.org/GNOME/libxml2/commit/0e1a49c89076

xmlSchemaPreRun in xmlschemas.c in libxml2 2.9.10 allows an xmlSchemaValidateStream memory leak.

Reference and upstream commit: https://gitlab.gnome.org/GNOME/libxml2/mergerequests/68

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.

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

Stack-based buffer overflow vulnerability in the interactive shell of the xmllint tool in libxml2. The issue is caused by an unsafe use of strcpy() when processing user-supplied command-line input. When an attacker passes an overly long argument to any shell command (e.g., exit, cat, etc.), the input exceeds the fixed-size stack buffer, resulting in a crash or potentially arbitrary code execution on systems lacking stack protections. This vulnerability affects only the interactive shell and requires that an attacker can influence or control the command input to xmllint, which is uncommon in typical deployments.

Severity: Medium

Affected versions:

- upstream versions - 2.9.11 to 2.11.0

Description:

Credit:

Geoffrey Humphreys (reporter)

References: https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/2141260 https://gitlab.gnome.org/GNOME/libxml2/-/workitems/1058

The linked launchpad issue has PoC and reproduction instructions if needed.

Timeline: 2026-02-09 : reported to Canonical's Ubuntu Security Team 2026-02-17 : reported to upstream 2026-06-08 : PoC and details send to distros list 2026-06-22 : public disclosure

Hi,

On Fri, Sep 04, 2026 at 06:35:56PM +0100, Sam James wrote: From libxml2-2.15.4:

+v2.15.4: Sep 01 2026 + +### Security + +- xmlregexp: Prevent out-of-bounds read in NXT macro +- fix: add missing overflow checks in dict.c, uri.c, and valid.c +- xmlregexp: Calc string length after null checking +- xpointer: Check overflow in xmlXPtrEvalXPtrPart +- xmlIO: Check for int overflow before calling writecallback +- fix(xinclude): propagate parseFlags in xmlXIncludeProcess and xmlXIncludeProcessTree + + [...]

I possess no further details. FTR, some CVEs got assigned for issues fixed in 2.15.4:

https://www.cve.org/CVERecord?id=CVE-2026-86137: | 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.

https://www.cve.org/CVERecord?id=CVE-2026-86138 | In libxml2 before 2.15.4, xmlDictAddQString in dict.c has an integer | overflow and resultant heap-based buffer overflow.

https://www.cve.org/CVERecord?id=CVE-2026-86139 | In libxml2 before 2.15.4, xmlURIEscapeStr in uri.c has an integer | overflow.

https://www.cve.org/CVERecord?id=CVE-2026-86140 | In libxml2 before 2.15.4, xmlSnprintfElements in valid.c has a strcat | stack-based buffer overflow.

https://www.cve.org/CVERecord?id=CVE-2026-86141 | 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.

https://www.cve.org/CVERecord?id=CVE-2026-86142 | In libxml2 before 2.15.4, there is a heap-based buffer overflow in | xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation.

https://www.cve.org/CVERecord?id=CVE-2026-86143 | 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.

https://www.cve.org/CVERecord?id=CVE-2026-86144 | 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).

Regards, Salvatore