CVE-2026-41254

What it actually does

Little CMS (lcms2) through 2.18 contains an integer overflow in the CubeSize calculation in cmslut.c. The code performs a multiplication before validating whether the result overflows, which can cause an incorrectly small allocation or incorrect bounds calculation when parsing or processing a maliciously crafted color transform/profile structure. Depending on the consuming application and build protections, this may lead to memory corruption, process crash, or limited information disclosure. The CVSS vector indicates local attack complexity is high, no privileges are required, and the expected direct impact is low confidentiality loss and low availability loss rather than reliable remote code execution.

Why it matters to the business

Applications, document converters, image pipelines, print workflows, desktop software, and server-side services that rely on Little CMS to process untrusted ICC profiles or image/document content may be exposed to crashes or limited data exposure if they process malicious files. Current public exploitation risk appears low: EPSS is very low and flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no known mature exploit. However, because Little CMS is commonly embedded in downstream software, exposure may exist indirectly through operating system packages or third-party applications even where the library is not managed directly.

How an attack unfolds

An attacker first identifies software that uses lcms2 to parse color profiles, images, PDFs, print jobs, or other files containing ICC/color-management data. They then craft input that drives the CubeSize multiplication in cmslut.c beyond the representable integer range. Because the overflow check occurs after the multiplication, the computed value may wrap and be treated as valid. When the vulnerable library later uses the wrapped size during allocation, indexing, or LUT processing, memory access can become inconsistent with the true data size. In a realistic attack, the adversary must get a vulnerable local application or service to process the malicious content. Successful exploitation is expected to be unreliable and environment-dependent, most likely causing a crash or limited memory disclosure rather than a broad compromise.

How to fix it

Upgrade Little CMS/lcms2 to a vendor-fixed release once available. No upstream fixed version was provided in the input, so track the Little CMS project and operating system/package vendor advisories for the first version that corrects the CubeSize overflow check. For Linux and appliance environments, apply distribution security updates even if the visible lcms2 version appears unchanged, because vendors may backport the fix. Where immediate patching is not possible, reduce exposure by preventing untrusted users from submitting ICC profiles, images, PDFs, print jobs, or other files that trigger color-management parsing; disable or sandbox image/document conversion features that process untrusted content; run converters with least privilege; and apply process isolation, seccomp/AppArmor/SELinux, memory-safe sandboxing, and crash monitoring around workloads that use lcms2.

How to confirm the fix worked

Inventory systems and applications for lcms2/Little CMS through version 2.18, including statically bundled copies inside desktop applications, document converters, image processing tools, print software, containers, and language package wheels or native extensions. Validate remediation by confirming that the installed package is updated to a vendor release containing the fix, or that the relevant source patch changes cmslut.c so overflow is checked before multiplication. On Linux, use package manager metadata and vendor changelogs rather than version strings alone when backports are used. For source-built software, inspect linked libraries with tools such as ldd, otool, rpm/dpkg queries, SBOM data, container image scans, and build manifests. Confirm mitigations by testing that untrusted file-processing paths are sandboxed and that applications no longer crash when subjected to malformed ICC/profile fuzz cases.

Typical attack path

1. Identify an application, service, image-processing pipeline, print workflow, or document converter that links against lcms2 through 2.18.
2. Create a malicious ICC profile or file format containing color-management data that triggers an oversized CubeSize calculation.
3. Deliver the crafted file or profile to the target workflow, such as opening it locally, importing it into an application, submitting it to a conversion service, or sending it to a print/image-processing pipeline.
4. The vulnerable lcms2 code multiplies values before validating overflow, causing the computed size to wrap or become inconsistent.
5. The consuming process may allocate an incorrect buffer size or process LUT data using invalid assumptions.
6. The attacker obtains the resulting impact, typically process crash/denial of service or limited memory exposure, depending on the application and platform protections.

How to detect it

There are no highly specific public exploitation indicators for this vulnerability. Detection should focus on evidence that applications using lcms2 processed malformed ICC profiles or color-managed files shortly before crashes, memory faults, or abnormal terminations. Review application logs, crash reporters, system journals, EDR telemetry, core dumps, container restart events, and file-ingestion logs for segmentation faults, aborts, sanitizer findings, or repeated failures in image/document/print-processing components. Correlate crashes with recently uploaded or imported files containing ICC profiles or LUT/color-transform data. In forensic review, preserve suspect input files, core dumps, and process memory diagnostics; look for call stacks referencing lcms2 functions, cmslut.c, LUT/cube processing, or Little CMS profile parsing. Threat actor or campaign-specific detection is not available from the provided data, and no KEV/ransomware exploitation is known.

• lcms2
• Little CMS
• cmslut.c
• CubeSize
• cmsPipeline
• cmslut
• cmsStageAllocCLut
• cmsReadTag
• cmsOpenProfileFromMem
• cmsOpenProfileFromFile
• Segmentation fault
• SIGSEGV
• SIGABRT
• AddressSanitizer
• integer overflow
• heap-buffer-overflow
• buffer overflow
• core dumped

What your security team should do

• Identify all direct and transitive use of Little CMS/lcms2, prioritizing services that process untrusted images, PDFs, uploads, print jobs, thumbnails, or document conversions.
• Monitor vendor advisories for a fixed lcms2 release or distribution backport, and patch when available; treat downstream embedded copies separately from system packages.
• Prioritize externally reachable or multi-user file-processing services even though the CVSS attack vector is local, because server-side processing of attacker-supplied files can turn this into a remotely triggerable service crash.
• Add sandboxing and least-privilege controls around image/document conversion and print-processing components that link to lcms2.
• Temporarily restrict acceptance of untrusted ICC profiles or sanitize/strip embedded color profiles from files where business workflows allow.
• Enable crash telemetry and alerting for repeated failures in applications using Little CMS, especially following processing of newly submitted files.
• Because EPSS is low, flat, not KEV-listed, and no mature exploit is known, schedule remediation according to normal memory-corruption library patch SLAs unless the library is exposed to untrusted content at scale.