CVE-2026-86141

What it actually does

xmlregexp in libxml2 before 2.15.4 contains a NULL pointer dereference in xmlRegNewParserCtxt. After strdup fails, the function does not treat the NULL result as a failed allocation and instead computes a string length on that pointer, causing the calling process to crash. Impact is availability-only (process abort); confidentiality and integrity are not affected. The vector is local with high attack complexity because a strdup failure must occur on the regexp pattern without otherwise terminating the process first.

Why it matters to the business

Applications that compile XML regular expressions through libxml2 may abort under rare allocation-failure conditions, producing a short outage or a restart of the affected process. There is no data theft, privilege gain, or ransomware exposure. The flaw is not in CISA KEV, has exploit maturity None, and remains low urgency more than a month after publication. Red Hat libxml2-main users should still apply the vendor advisory as routine maintenance because libxml2 is a widely embedded XML dependency.

How an attack unfolds

An attacker who already has local presence would need to drive a vulnerable libxml2 consumer into xmlRegNewParserCtxt while strdup of the pattern string fails, typically under extreme memory pressure. The unchecked NULL is then used as a string, the process faults, and service is interrupted. Reliable triggering is difficult: allocation failures are uncommon, timing is fragile, and success yields only a crash—not code execution or data access. No named threat actors, campaigns, or KEV-listed ransomware use are associated with this issue.

How to fix it

Upgrade libxml2 to 2.15.4 or later. On Red Hat systems shipping libxml2-main, install 2.15.4-0.1.hum1 as delivered in RHSA-2026:64463. Restart long-lived daemons and rebuild any statically linked binaries so they load the patched library. There is no reliable configuration-only workaround other than avoiding XML regexp compilation in memory-constrained or untrusted contexts until the library is updated.

How to confirm the fix worked

Confirm the installed libxml2 is 2.15.4 or newer, and on Red Hat that the package is 2.15.4-0.1.hum1 or later and that RHSA-2026:64463 is applied. Query the package manager and inspect shared-library soname mappings of running processes to find instances still loaded from a pre-2.15.4 libxml2; restart those processes. Optionally regression-test XML regexp compilation after the upgrade to verify the process no longer aborts on allocation failure.

Typical attack path

1. Obtain local access to a host running software linked against libxml2 before 2.15.4
2. Identify an application path that creates an XML regexp parser context (xmlRegNewParserCtxt)
3. Create conditions under which strdup of the pattern fails, such as severe memory pressure
4. Cause the application to compile or parse the XML regular expression so the NULL pointer is dereferenced
5. The target process crashes, resulting in a limited denial of service

How to detect it

Exploitation leaves crash evidence rather than persistence. Search syslog, journald, ABRT, coredumpctl, and application logs around and after 2026-09-05 for segmentation faults or aborts in processes linked to libxml2 whose stack traces name xmlRegNewParserCtxt or xmlregexp. Correlate those faults with memory-pressure or OOM events. Kernel logs showing SIGSEGV or SIGABRT from XML-processing services are consistent with accidental or attempted triggering. Given exploit maturity None and no KEV or named-actor activity, absence of such crashes is the expected finding.

• xmlRegNewParserCtxt
• xmlregexp
• SIGSEGV
• libxml2.so

What your security team should do

• Apply libxml2 2.15.4 (Red Hat libxml2-main 2.15.4-0.1.hum1 / RHSA-2026:64463) in the next maintenance window; this is not an emergency KEV-driven patch
• Inventory runtimes and packages that link libxml2, especially those that compile XML regular expressions
• Restart long-lived services after the library update so they unload the vulnerable .so
• Treat residual xmlRegNewParserCtxt crash signatures as an exposure signal, not as evidence of a broader compromise
• Do not stand up incident response solely for this CVE given CVSS 2.9, local/high-complexity profile, and exploit maturity None