CVE-2026-4367

What it actually does

This vulnerability is an out-of-bounds read in libXpm's xpmNextWord() parsing logic. When a specially crafted, truncated, or very small XPM image is processed, the parser may advance an internal pointer past the end of the input buffer because file boundaries are not validated correctly. The most likely result is a crash of the application or service using libXpm to parse XPM files, causing a local denial of service. The CVSS vector indicates local access is required, low attack complexity, low privileges are required, no user interaction is required from the attacker's perspective once they can cause the vulnerable component to process the file, and the impact is limited to availability.

Why it matters to the business

An authenticated local user can crash applications that rely on libXpm to process XPM image files. In desktop, rendering, file-preview, image-conversion, or automated processing workflows, this may interrupt user sessions, batch jobs, or services that handle image assets. The issue is not known to be exploited in the wild, is not in the CISA KEV catalog, and has a low EPSS score, so broad emergency response is not indicated; however, systems that process untrusted local files or multi-user workloads should prioritize patching to prevent avoidable outages.

How an attack unfolds

An attacker first needs low-privileged local access to a system or the ability to place or submit an XPM file that a local process will parse using libXpm. The attacker creates an XPM file with malformed boundaries, such as an extremely small or truncated structure that causes xpmNextWord() to continue reading past the valid file data. When a vulnerable application, previewer, converter, file manager, or image-processing workflow opens or processes that file, libXpm performs an out-of-bounds read. The invalid memory access can terminate the calling process, producing a denial-of-service condition for that application or workflow. There is no current indication from the provided data that this flaw enables code execution, privilege escalation, data modification, or data disclosure.

How to fix it

Upgrade libXpm to a vendor-provided fixed version as soon as one is available for the affected operating system or distribution. Because no exact affected products or fixed versions were provided, follow the relevant Linux distribution, Unix vendor, or package maintainer advisory for the corrected libXpm/libxpm package. After patching, restart applications and services that link against libXpm, and consider rebooting systems where long-running processes may keep the vulnerable library loaded. Where immediate patching is not possible, reduce exposure by preventing untrusted users from submitting or processing XPM files, disabling XPM preview/thumbnail generation where feasible, restricting local multi-user access, and isolating image-processing workloads that handle untrusted files.

How to confirm the fix worked

Confirm the installed libXpm package version matches the fixed version published by the operating system or package vendor. Use package-manager queries such as rpm/dnf/yum, dpkg/apt, pacman, zypper, or equivalent platform tooling to verify the libXpm/libxpm package has been updated. Check running processes that may have the old shared library mapped and restart them. Validate that file managers, thumbnailers, image converters, and applications that parse XPM files remain stable when processing malformed or truncated XPM test cases from trusted vendor or regression test sources. Do not use untrusted proof-of-concept files in production validation.

Typical attack path

1. Obtain low-privileged local access to a system or access to a workflow that processes locally available XPM files.
2. Create or stage a malformed, truncated, or very small XPM file designed to trigger the xpmNextWord() boundary-checking flaw.
3. Cause a vulnerable application or service linked against libXpm to parse the crafted XPM file.
4. Trigger an out-of-bounds read when libXpm advances past the end of the input buffer.
5. Crash the calling application or image-processing workflow, resulting in denial of service.

How to detect it

To determine whether exploitation has already occurred, focus on crash evidence for applications linked to libXpm shortly after processing XPM files. Review system logs, desktop session logs, service logs, application crash reports, core dumps, and endpoint telemetry for segmentation faults, bus errors, aborts, or repeated restarts involving image viewers, file managers, thumbnail generators, converters, or custom applications that parse XPM files. On Linux and Unix-like systems, inspect journal logs, syslog, apport, ABRT, coredumpctl, systemd service restart history, and audit logs for crashes correlated with access to .xpm files. Search file-access telemetry for recently created or opened XPM files that are unusually small, truncated, malformed, or located in user-writable directories before a crash. Because the vulnerability is an out-of-bounds read leading primarily to denial of service, reliable network indicators are not expected, and detection should emphasize local file activity and process-crash correlation.

• xpmNextWord
• libXpm
• libxpm
• *.xpm
• segfault
• Segmentation fault
• SIGSEGV
• core dumped
• coredump
• Out-of-Bounds Read
• X PixMap
• XPM
• /var/lib/systemd/coredump/
• /var/crash/
• /var/spool/abrt/

What your security team should do

• Inventory systems and applications that include or link against libXpm, especially desktop systems, shared Unix/Linux hosts, VDI environments, image-processing servers, and CI/CD or content pipelines that parse image files.
• Prioritize patching for multi-user systems and systems that process untrusted or user-supplied XPM files, even though exploitation likelihood is currently low.
• Apply vendor libXpm/libxpm updates and restart affected applications or reboot systems to ensure the patched library is loaded.
• Temporarily restrict XPM upload, preview, thumbnailing, or conversion for untrusted users where patching is delayed.
• Monitor for repeated crashes in applications that parse XPM files, as this is the most likely exploitation symptom.
• Treat this as an availability-focused vulnerability rather than a confirmed code-execution or data-theft issue unless later vendor advisories expand the impact.