CVE-2025-6170
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-06-16

Last updated on: 2026-04-19

Assigner: Red Hat, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-16
Last Modified
2026-04-19
Generated
2026-05-07
AI Q&A
2025-06-16
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
redhat enterprise_linux 8.0
redhat jboss_core_services *
redhat openshift_container_platform 4.0
redhat enterprise_linux 6.0
redhat enterprise_linux 7.0
redhat enterprise_linux 9.0
redhat enterprise_linux 10.0
xmlsoft libxml2 *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-121 A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a stack-based buffer overflow in the interactive shell of the xmllint tool, caused by improper handling of overly long user input commands. Specifically, the unsafe use of strcpy() allows an attacker to overflow a fixed-size stack buffer when providing excessively long arguments to shell commands within xmllint's interactive shell. This can cause the program to crash or, on systems lacking proper protections, potentially allow arbitrary code execution. [1]


How can this vulnerability impact me? :

The vulnerability can cause the xmllint interactive shell to crash when processing overly long commands. In rare cases, on systems without modern stack protections, it could allow an attacker to execute arbitrary code. However, exploitation requires the attacker to control the input to the xmllint interactive shell, which is uncommon in typical deployments. Overall, the impact is considered low severity. [1]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by checking if the system has a vulnerable version of the libxml2 library that includes the xmllint tool with the interactive shell mode. Since the flaw occurs when an overly long command is input into the xmllint interactive shell, detection involves verifying the version of libxml2 and testing the interactive shell with long inputs to see if it crashes. A practical command to check the installed version is: `xmllint --version`. To test for the vulnerability, one could attempt to run the xmllint interactive shell and input an excessively long command string to observe if it crashes, but this should be done cautiously in a controlled environment. There are no specific network detection commands since the vulnerability is local and requires interactive shell access. [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include avoiding the use of the xmllint interactive shell mode with untrusted input, especially avoiding inputting overly long commands. Updating the libxml2 package to a version where this vulnerability is fixed is recommended once a patch is available. Additionally, ensuring that modern stack protection mechanisms (such as stack canaries and address space layout randomization) are enabled on the system can reduce the risk of arbitrary code execution. Restricting access to the xmllint interactive shell to trusted users only is also advised. [1]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart