CVE-2026-91186
8.4HighPublished 20 Oct 2026 · NVD status: Received · AI triage by gemini-3.8-flash
- Attack vector
- Local
- Complexity
- Low
- Privileges needed
- None
- User interaction
- Active
- Impact
- Full C/I/A compromise
- Weakness
- CWE-125, CWE-787
Impact
Attackers can achieve arbitrary code execution or crash the application by getting a user or process to decode a maliciously crafted PNG file. The exploit triggers an out-of-bounds write during PNG row unfiltering.
Root cause
The PNG decoder permits a duplicate IHDR chunk after IDAT, modifying dimensions after buffer allocation and causing out-of-bounds memory writes during filtering passes.
Affected systems
Eclipse ThreadX GUIX (exact vulnerable and patched versions not listed in the provided data — check GHSA-gx8f-4rpc-4fjw).
CVSS v4.0 · CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Fix & remediation
Check the vendor advisory (GHSA-gx8f-4rpc-4fjw) for the patched release and recompile your firmware; if unable to patch immediately, disable the PNG decoder or reject PNG files containing duplicate IHDR chunks before passing them to GUIX.
AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
The PNG chunk reader has no notion of chunk ordering. It records whether an IDAT has been seen and whether a tRNS has already supplied transparency, but nothing prevents an IHDR being read a second time. A PNG carries exactly one IHDR and it is the first chunk. A file that places a second one after IDAT rewrites the image width, height, bit depth and pixel depth *after* the decoded-data buffer has already been allocated and filled from the original values. The pass that reverses the PNG row filters then derives its own extent from the new dimensions and walks the old allocation, moving image bytes past the end of it. The buffer is allocated by GUIX rather than supplied by the caller, so the application has no way to size it defensively. The decoder is compiled in by default.