REDHAT-BUG-2547476: High severity Expat libexpat vulnerability

Q: What application behavior is required for this issue to be reachable?

The application must call XML_ParseBuffer with a caller-supplied length while a parse buffer already exists. That buffer is normally created by an earlier XML_GetBuffer call, or may have been allocated internally by an earlier XML_Parse call.

Q: Are applications that only call XML_ParseBuffer without first obtaining or creating a buffer affected?

This path is not reached when no parse buffer is present: XML_ParseBuffer returns XML_ERROR_NO_BUFFER. Exposure depends on a prior call that leaves a parse buffer available.

Q: What can an attacker gain from a successful over-read?

The calling application can receive adjacent heap memory, including heap pointers, libc function pointers, and code pointers. This information can defeat ASLR and provide primitives for further exploitation.

Q: What should be reviewed if patching cannot happen immediately?

Review code paths that use XML_GetBuffer followed by XML_ParseBuffer, as well as paths where XML_Parse may allocate a buffer before XML_ParseBuffer is used. Avoid passing lengths to XML_ParseBuffer that exceed the allocated parse-buffer size.

Published Oct 7, 2026

Updated

libexpat before commit 13c5f63 contains a heap buffer over-read vulnerability in xmlparse.c. XMLParseBuffer advances the parse buffer end with parser->mbufferEnd += len using a caller-supplied length that is not validated against the allocated buffer size, so repeated XMLParseBuffer calls move mbufferEnd past the end of the heap allocation and subsequent parsing reads out of bounds. Reaching this path requires a parse buffer to already be present; otherwise XMLParseBuffer returns XMLERRORNOBUFFER. A buffer is present after a prior call to XMLGetBuffer, either directly (the common case) or indirectly through a prior XMLParse call that allocates the buffer internally. The over-read discloses adjacent heap memory to the calling application, recovering heap pointers, libc function pointers, and code pointers sufficient to defeat ASLR and build further exploitation primitives.

Affected Software

1 affected component

Expat libexpat<13c5f63

Event History

Oct 7, 2026

Data Sourced

via Red Hat·02:43 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

What application behavior is required for this issue to be reachable?

The application must call XML_ParseBuffer with a caller-supplied length while a parse buffer already exists. That buffer is normally created by an earlier XML_GetBuffer call, or may have been allocated internally by an earlier XML_Parse call.

Are applications that only call XML_ParseBuffer without first obtaining or creating a buffer affected?

This path is not reached when no parse buffer is present: XML_ParseBuffer returns XML_ERROR_NO_BUFFER. Exposure depends on a prior call that leaves a parse buffer available.

What can an attacker gain from a successful over-read?

The calling application can receive adjacent heap memory, including heap pointers, libc function pointers, and code pointers. This information can defeat ASLR and provide primitives for further exploitation.

What should be reviewed if patching cannot happen immediately?

Review code paths that use XML_GetBuffer followed by XML_ParseBuffer, as well as paths where XML_Parse may allocate a buffer before XML_ParseBuffer is used. Avoid passing lengths to XML_ParseBuffer that exceed the allocated parse-buffer size.

REDHAT-BUG-2547476: High severity Expat libexpat vulnerability

Affected Software

Event History

Frequently Asked Questions

What application behavior is required for this issue to be reachable?

Are applications that only call XML_ParseBuffer without first obtaining or creating a buffer affected?

What can an attacker gain from a successful over-read?

What should be reviewed if patching cannot happen immediately?

Company

Resources

Contact

Frequently Asked Questions

What application behavior is required for this issue to be reachable?

Are applications that only call XML_ParseBuffer without first obtaining or creating a buffer affected?

What can an attacker gain from a successful over-read?

What should be reviewed if patching cannot happen immediately?