Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessUpload crafted little-endian PFM image
-
DeliveryLoader mmaps misaligned pixel buffer
-
Exploitvips_avg_scan() dereferences unaligned float pointer
-
ExecutionProcess aborts on strict-alignment build
-
ImpactDenial of service
Vulnerability Assessment
| Weakness |
CWE
|
| Exploitation Conditions | Exploitation requires that an application or service decode an attacker-supplied little-endian PFM (Portable FloatMap) image using libvips 8.19.0, AND that the PFM text header length is not a multiple of four bytes, causing the mmap-backed pixel buffer to be misaligned for float access. The denial of service (process termination) manifests ONLY on strict-alignment architectures (e.g., certain ARM, SPARC, MIPS targets) or on UBSan-instrumented builds; on x86/x86_64 and alignment-tolerant builds the misaligned float dereference does not crash, so those deployments are effectively not affected. Limiting factors: the victim must actually process untrusted PFM input (PFM is an uncommon format, often disabled or unreached in typical upload pipelines), and the architecture/build condition is outside the attacker's control. |
| Impact | The input CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), framing this as a network-reachable, unauthenticated availability issue. However, multiple signals argue strongly against treating it as a top priority. EPSS is only 0.14% (3rd percentile), it is NOT in CISA KEV, and no public exploit code is referenced - the only reference is the upstream GitHub issue report. Most importantly, the description itself constrains impact: process termination occurs ONLY 'on strict-alignment architectures or UBSan-instrumented builds.' On the dominant x86/x86_64 and most ARMv7+/AArch64 production deployments, unaligned float dereferences are tolerated and will NOT crash, so the A:H/CVSS:L=L assumption is optimistic for an attacker. This is a classic high-CVSS-but-conditional-real-risk case: the CVSS AC:L does not reflect that the crash depends on the victim's architecture/build, a factor outside the attacker's control. Net assessment: a genuine but low-urgency DoS limited to a narrow set of strict-alignment or sanitizer builds, with no confidentiality or integrity impact and no evidence of exploitation. |
| Exploit ScenarioDerived | An attacker submits a crafted little-endian PFM image whose text header length is not a multiple of four bytes to a service or application that decodes images with libvips 8.19.0 (for example an image-upload/thumbnailing pipeline). When vips_avg_scan() dereferences the misaligned mmap buffer through a float pointer on a strict-alignment architecture or a UBSan build, the process aborts, denying service. No public exploit code is identified at time of analysis, and the crash does not reproduce on typical x86_64 builds. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 06, 2026
Denial of service in libvips 8.19.0 occurs when a service decodes an attacker-supplied little-endian PFM (Portable FloatMap) image whose text header length is not a multiple of four bytes, leaving the mmap-backed pixel buffer misaligned for float access; vips_avg_scan() then dereferences that buffer as a float pointer, producing undefined behavior that terminates the process on strict-alignment targets or UBSan-instrumented builds. The issue is remote and unauthenticated (CVSS:3.1/AV:N/AC:H/PR:N/UI:N), but real-world impact is narrow: the victim must actually route untrusted PFM input into libvips 8.19.0, and the misaligned float access is harmless on x86/x86_64 and other alignment-tolerant builds, so the assessed attack complexity is high and the practical consequence is availability-only. No public exploit code was identified at time of analysis, EPSS is low at 0.14% (3rd percentile), and there is no CISA KEV listing; the underlying issue is tracked upstream as libvips GitHub issue 5187.
RemediationAI
No vendor-released patch was identified at time of analysis, so remediation currently centers on tracking the upstream libvips issue at https://github.com/libvips/libvips/issues/5187 and upgrading to the first release that incorporates the fix once it is published; confirm the fix version from the upstream maintainers rather than assuming a version number. In the meantime, the most direct compensating control is to block untrusted PFM data from reaching libvips: reject or strip uploads whose header begins with the PF/Pf magic and remove PFM from the set of permitted image formats in applications that do not legitimately need Portable FloatMap input, accepting the trade-off that any real PFM workflow will break. Alternative mitigations include running PFM decode (or all image decoding from untrusted sources) in a sandboxed, resource-limited worker subprocess so that a SIGBUS/SIGSEGV or UBSan abort does not take down the primary service, at the cost of additional latency and memory overhead, and patching the loader locally to copy rather than mmap the header-adjacent pixel data so the float buffer is suitably aligned, at the cost of extra memory per decode. Note also that production builds instrumented with UndefinedBehaviorSanitizer convert this benign misalignment into a hard crash; evaluating such builds outside production reduces unintended downtime but does not resolve the underlying undefined behavior, and deployments on x86/x86_64 or other alignment-tolerant targets are not practically affected and can be deprioritized in triage.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
PFM is the Portable FloatMap format, a simple raster format for 32-bit floating-point pixel data whose file begins with a short ASCII header ('PF' or 'Pf' plus dimensions and scale) terminated by whitespace, followed by raw little- or big-endian float samples. libvips 8.19.0 can map such files with an mmap-based loader rather than copying the payload into a freshly allocated buffer, so the start of the pixel data is offset in memory by the exact header length. Because the header length is not required to be a multiple of four, a header of, say, 2 or 3 bytes leaves the first float sample at an address that is not aligned for float access; when vips_avg_scan() later walks the buffer through a float pointer, the CPU or instrumentation layer sees a misaligned load. On x86/x86_64 this is tolerated by hardware, but on strict-alignment architectures (certain ARM, SPARC and MIPS targets) it raises a hardware fault (SIGBUS/SIGSEGV), and on UBSan-instrumented builds it triggers a runtime error that aborts the process, making the outcome a reproducible crash rather than memory corruption. The advisory tags this as CWE-1339 (Insufficient Precision or Accuracy of a Real Number), although the described root cause is more precisely a memory-alignment defect in the header-offset handling of the mmap-backed loader chain feeding vips_avg_scan(); there is no CPE string in the supplied intelligence, and ENISA's EUVD entry (EUVD-2026-85910) lists affected versions as unavailable, so 8.19.0 from the CVE description is the only confirmed affected release.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Crash only on strict-alignment or UBSan builds - an architecture/build condition outside attacker control - so AC:H; network-reachable via image services (PR:N), availability-only impact (C:N/I:N/A:H).
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
3DescriptionCVE.org
libvips 8.19.0 contains a memory access vulnerability when processing little-endian PFM images. If the PFM text header length is not a multiple of four bytes, the mmap-based loader can expose pixel data at an address that is not properly aligned for float access. vips_avg_scan() subsequently dereferences the buffer through a float pointer, resulting in undefined behavior and process termination on strict-alignment architectures or UBSan-instrumented builds, leading to denial of service.
Executive ViewAI
A denial-of-service vulnerability in libvips 8.19.0, an image processing library, could allow an unauthenticated attacker to crash services that process specially crafted PFM images, primarily affecting non-x86 platforms. While exploitation requires specific conditions and no public exploit identified at time of analysis, the lack of a vendor patch poses a risk to the availability of applications that handle untrusted image uploads. Leadership should prioritize mitigation because successful attacks could disrupt critical image processing pipelines.
No vendor-released patch identified at time of analysis; interim mitigations include restricting PFM processing to trusted inputs, validating PFM header length alignment before decoding, disabling PFM support if not needed, and monitoring for process crashes.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
EUVD-2026-85910
GHSA-4f34-xv5x-8jfh
NVD
CVE.org
EPSS
Exploit-DB